יש הרבה הרבה חומר על –ASP.net 4, וחלקו הרבה יותר מוצלח מכל מה שאכתוב עליו. פה אני אסקור דברים ש"תפסו אותי" ונראים לי מעניינים.
לא מדובר בחקירה מעמיקה של התחום אלא סתם באוסף נקודות, אבל בסדר :-)
OutputCache
כמו שכולנו יודעים, אחת היכולות המסייעות במיוחד לבנות מערכות שעמידות בעומסים כבדים, היא OutputCache.
בהרצאה שהעברתי לפני שנים מספר הדגמתי כיצד ניתן להשתמש בכלי החזק הזה, וכיצד גם להציג תוכן דינאמי ופרסונלי תוך שימוש ב-OutputCache בשרת ואפילו תוך שימוש ב-Reverse Proxy או CDN.
הרעיון הבסיסי הוא היכולת להרחיב ולכתוב מנגנון Caching חדש, שלא המנגנון המובנה ששומר את הדפים בזיכרון. אפשר למשל לשמור את המידע הזה ב-memcached הפופולארי בעולם או AppFarbic Caching שהיה מכונה עד לא מזמן Velocity.
<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>
אני דווקא חושב שיהיה חכם לפעמים לשמור את המידע הזה דווקא במערכת הקבצים, ועדיף על דיסק קשיח ייעודי.
Prearm
בנוסף, היכולת של IIS לבצע Prearm (לא ספציפית ASP.net 4), מאפשרת "הכנת" ה-Cache עוד לפני קבלת הבקשה הראשונה. כך למשל בסביבת חוות שרתים ניתן למלא את ה-Cache בצורה מסודרת כדי למנוע איטיות בפעולת האתר עד שכל רכיביו יאוחסנו ב-Cache.
httpRuntime
הפינה הזו ב-Web.Config מקבלת כמה אפשרויות נוספות.
maxRequestPathLength – אורך התיקיות ושם הקובץ
http://www.site/Folder/SubFolder/FileName.aspx?query=1235&56g
אני מנחש שיש לדבר קשר לשימושים השונים של Routing ו-MVC.
maxQueryStringLength – אורך ה-QueryString
המגבלה המקורית (2048) מבוססת על המגבלה של IE ביגרסאות קודמות. אם יש לכם צורך, ניתן להגדיל (או – עדיף! להקטין) את המגבלה הזו.
requestPathInvalidChars – תווים לא חוקיים בשדות טופס. ניתן לשנות ולהוסיף תווים נוספים. לשים לב ש-IIS (מדוייק יותר, http.sys) דוחה בכל מקרה בקשות עם תווים מסויימים שאינחם חוקיים לפי RFC 2396.
RequestValidatorType
לראשונה ניתנת האפשרות להחליף את בודק ה-XSS המקורי, ולבנות אחד חדש במקומו שיסנן דברים אחרים או יסנן קצת פחות.
רק לחשוב קצת, יש לזה הרבה שימושים מדליקים.
jQuery נכלל בתבניות הבסיסיות של אתרים ב-Visual Studio
אפשרות לדרוס את מימוש הדפדפנים המקורי של ASP.net, במימוש משלך (קריטי לפעמים בשימוש ב-CDN).
<%: Item%>
מבצע קידוד אוטומאטי (HttpUtility.HtmlEncode(Item, והופך את הקוד לקצת יותר יפה.
יש עוד הרבה דברים חדשים שם, אבל בחרתי להתמקד בעיקר במה שרלוונטי לדברים שאני עוסק בהם.
מדי פעם אני נתקל באתרים שזוחלים לאט. לעיתים הפיתוי מושך אותי לפתוח את כלי הפיתוח שלי ולהבין מה קרה שם.
אחד מהאתרים האלה השתמש ב-UpdatePanel וטעינת רכיבי AJAX ארכה דקות ארוכות. בהמשך מישהו מצוות האתר הזה התחיל לעבוד עם WebService שמחזיר JSON.
פה כבר מדובר בשיפור מדהים בביצועים, אבל עדיין רחוק ממה שניתן היה להשיג. אילו וכאשר.
נוחות הפיתוח והבדיקה של WebServiceים למינהם ובהמשך WCF הפכה אותם לשימושיים גם בתוך הדפדפן, כמקור למידע אותו משלימים ב-AJAX.
מדובר בכלי יעיל, אלא שגם לו יש חסרונות מרכזיים. הראשי שבהם הוא השימוש ב-POST במקום ב-GET, ה-Overhead הלא קטן של Serilization על אובייקטים, במיוחד כשהם גדולים אבל האמת היא שכרגיל המפתח נמצא בצד הלקוח
Yahoo כבר לימדו אותנו מזמן ש-GET יעיל יותר מ-POST. בגלל שמדובר בחיסכון של Packet שעובר ברשת, אבל אני חושב שיש פה עוד כמה דברים שמתפספסים בצורה הזו.
האתר שלנו גדל, ואנחנו מקבלים כל יום אלפי חיפושים במערכת שנבנתה. מן הסתם נרצה לשים CDN או Proxy פשוט לפני האתר שלנו כדי להוריד עומסים.
Proxy כזה יכול לאחסן אצלו תוצאות של GET, אבל לא תוצאות של POST.
וזה נוסף על כך ש-Serilization של מידע עולה במשאבים גם כשמדובר בשדה טקסט אחד שנשלח והוא עולה גם על המידע הנשלח ב-XML אם JSON. במקרה כזה- GET יהיה פשוט ומהיר עוד יותר ויחסוך עוד נקודה של עומס כשבונים רכיב כמו השלמה אוטומאטית.
מתי כן נשתמש ב-POST? כשיש צורך אמיתי להעביר כמות גדולה של מידע או כשצריך לשמור מידע או לבצע שינויים בשרת, ורוצים למנוע מתקפות בסגנון CSRF.
או בקצרה
GET – בקשת מידע
POST (ו-REST למינהם) – שמירת מידע
עוד בנושא:
מדוע ASP.net AJAX חוסם כברירת מחדל בקשות GET מאת Scott Guthrie