DCSIMG
עמוד הבית| חבילות השירות שלנו| חומר חופשי| צור קשר
ארכיטקטורה, ביצועים ומה שביניהם - בלוג היועצים של מיקרוסופט ישראל

בלוג היועצים של מיקרוסופט ישראל

ארכיטקטורה, ביצועים ומה שביניהם

התלבטתי במה להתחיל...והחלטתי להתחיל במספר דוגמאות בהם החלטות ארכיטקטונית/עיצוביות יכולות להשפיע על ביצועים, ולהיפך.

1. סוג רכיבי המידע איתם אעבוד באפליקציה
קיימים סוגים שונים של רכיבי מידע (Xml, Dataset, POCO....) - מה היתרונות/חסרונות בהיבטי ביצועים?

XML

מתי?
· כאשר קיים צורך בצימוד נמוך וה caller צריך לקבל/לדעת רק את ה value וה schema
· כאשר קיים צורך לתמוך גם בצרכנים שאינם כתובים ב- dotnet.
· כאשר יש צורך בתמיכה built in ל serialization

בעיות?
· בדרך כלל צורך CPU מכיוון ששליפת נתונים ועדכון מבצעים חיפוש ב – DOM.
· מבנים גדולים צורכים זכרון וכל עיבוד איטי משמעותית.
· דורש casting

Dataset/Typed Dataset

מתי?
· כאשר קיים צורך בתמיכה של מבנה ישויות מורכב
· כאשר קיים צורך בתמיכה של relations מורכבים
· כאשר יש צורך במעקב אחר שינויים על המידע (self-tracking)
· כאשר קיים צורך בתמיכה built in ל serialization

בעיות?
· חתימה גדולה בזכרון.
· נפח גדול בתעבורה ברשת.
· מאפשר לי להעביר רק שינויים – יתרון

POCO

מתי?
· כאשר קיים צורך בתמיכה של מבנה ישויות מורכב
· כאשר שני הצדדים (caller, callee) מכירים את מבנה הישויות
· כאשר יש צורך ב binary serialization עבור ביצועים

2. תקשורת בין שכבות
כאשר אני מפתח מערכת C\S וה – client שלי הוא win application, בדרך כלל, רכיב השרת שלי יכיל שכבת שירותים שתחשוף WCF Services.
אך מה כאשר המערכת שלי היא מערכת אינטרנט ובא שכבת ה – UI שלי וגם רכיבי השרת שלי נמצאים על אותו שרת? האם גם אז התקשורת בין שכבת ה- UI לשכבת השירותים תהיה מבוססת WCF?

יתרונות של תקשורת מבוססת WCF:
- במקרה שנרצה להפריד את השכבה העסקית לשרת נפרד, לא יהיה צורך בשינוי קוד.
חסרונות:
- ביצועים. Reference ישיר מאפשר לי תקשורת ישירה בין רכיבים (in-proc).
[אני בעד הפשטה (אבסטרקציה) שתאפשר לי לבצע מעבר בין 2 האפשרויות, בשינוי קוד מינימלי].

3. Caching
נושא ה- caching נתפס כמשהו שבמהותו הוא משפר ביצועים. אך לא תמיד כך הוא הדבר. תכנון לא נכון של cache יכול לפגוע בביצועים באופן ניכר.
למה להשתמש ב – cache?
- להקטין את מספר הפניות למקור מידע.
- להקטין כמות עיבודים (ע"י כך שנחזיק ב – cache רכיבים "מעובדים").

מה הסיכונים ב- cache?
- ניצול יתר של הזכרון.
- עבודה עם מידע לא מעודכן (במקרה שהמידע במקור המידע השתנה).

אני לא אכנס כאן לדיון מעמיק על מתי נתון נכנס/יוצא מ- cahce, סוגי cache וכו', רק אציין 2 שיקולים מרכזיים המשפיעים על אלו נתונים יוחזקו ב- cache:
- תדירות שינוי הנתונים (נתונים המשתנים בתדירות גבוהה, אולי לא כדאי להחזיק ב- cache).
- תדירות צריכת הנתונים (אעדיף להחזיק ב- cache נתונים שנצרכים יותר).

אלו 3 דוגמאות מאוד בסיסיות על החלטות ארכיטקטוניות/עיצוביות שמאוד משפיעות על ביצועים.

בפוסט הבא, אציג תפיסה שגובשה במיקרוסופט (P&P) הממפה עבור "איזורים" שונים בארכיטקטורה ובעיצוב מערכת את הנקודות שיש להן השלכות בהיבט של ביצועים.

עד אז, בהצלחה.

טל

תוכן התגובה

אליק כתב/ה:

אחלה פוסט - תמציתי ומנחה.

אפרופו, POCO - תמיד :)

# May 12, 2010 12:28 AM

Yossi Elkayam כתב/ה:

הי טל , יופי של פוסט.

נושא נוסף שיש לקחת בחשבון בנושא ה Cache זה לא רק שינוי הנתונים אלא אבטחת מידע.

אם ה Cache מחזיק את ה ROLE של המשתמש והמידע ההרשאתי משתנה אזי Cache יכול להוות בעיה אמיתית.

וכמובן שיש עוד הרבה נושאים לשוחח עליהם...

# May 12, 2010 9:46 AM
שלח תגובה

(שדה חובה)  

(שדה חובה)  

(אופציונלי)

(שדה חובה) 

Please add 7 and 3 and type the answer here:


Enter the numbers above: