ארכוויז מס’ 4 – מה הקונפיגורציה האופטימאלית ל-WCF?
WCF היא טכנולוגיה המאפשרת הפעלת רכיבים מרחוק ויש לה מספר מקומות הניתנים לאופטימיזציה:
- Proxy. יצירת Proxy היא פעולה לא קלה ולכן ניתן להפתות לבצע Caching ל-Proxy כדי לחסוך זמן הקמת Proxy מחדש. מצד שני Cached Proxy יכול ליצור מצב שבו הערוץ תקוע או תפוס ולא ניתן לבצע עוד פניות – משהו שחוסם יכולת Scalability.
- אבטחת מידע. חלק מ-Bindings מפעילים Windows Integrated Authentication כברירת מחדל (wsHttpBinding) וחלק לא מפעילים אבטחת מידע בכלל (basicHttpBinding). זוהי הסיבה שישנו הבדל בין זמני תגובה בקונפיגורציה ברירת מחדל עובר שני ה-Bindings.
- Serialization. ככל שהמסרים גדולים יותר יותר זמן מתבזבז על Serialization. למזלנו WCF מציע מנגנון חזק של הגדרה מה מסתרלז ומה לא ע”י [Datamember], הבעיה מתעוררת כאשר רוצים לשלוח ל-WCF מבנה נתונים מסוג DataSets – קשה אם לא אפשרי להתחיל להגדיר בתוך DataSet מסתרלז ומה לא – לא רוב לא מתעסקים עם זה ואז כל ה-DataSet מסתרלז, פעולה כבדה למדי.
- עוד אבטחת מידע. ברגע שמסר עבר Serialization הוא עובר הגנה ע”י הצפנה וחתימה עבור Bindings שתומכים בזה – כמו wsHttpBinding. ככל שהמסר גדול יותר הפעולה ארוכה יותר. לא ניתן לבטל חתימה והצפנה של מסרים ע”י קונפיגורציה אלא בקוד בלבד
- Throttling. ברמת ה-Service ניתן להגדיר מספר פרמטרים שחוסמים מספר פניות בו זמניות הניתנות לביצוע. ניתן לשחרר אותם עד אין סוף אבל אז נתקלים בחסם של Threads זמינים וכתוצאה פוגעים קיבולת של השרת. בשורות טובות – הגדורת אלה קצת יותר משוחררות ב-Net Fx 4.0
שורה תחתונה… אני אוהב אך שניק אלן, אחד האנשים הבכירים בקבוצת WCF, מגדיר:
מה השיקולים שלך לאופטימיזציה של WCF?
חומר רלוונטי
שמי אליק לוין ואני מתרכז ב- Architecture, Security, and Performance באפליקציות Net.
בזמני הפנוי אני מפתח את עצמי בתחומים רבים אחרים.
This template is made with PracticeThis.com plugin for Windows Live Writer