בסילברלייט ניתן לתקשר עם הדפדפן ולקרוא למתודות ג'אואסקריפט לדוגמה :
HtmlPage.Window.Invoke("method")
בצורת תקשורת זו מקבלים חזרה אובייקטים מסוג ScriptObject שבכדי לתשאל אותם צריך לבצע משהו בסגנון :
myScriptObjct.getMember("memberName")
כמובן שתשאול ישיר היה יכול להיות יותר נוח וקריא
myScriptObjct.memberName
בעזרת dynamic ו DynamicObject ב C# 4 ניתן לבצע תחבולה שכזו וליישם אוביקט פרוקסי דינאמי שמקל על הקידוד
ונתחיל בחלק הכיפי , מורידים את הגרסה האחרונה מהאתר (קובץ zip) ופורסים . מכיוון שרייבן (עדיין לא החלטתי אם לעברת אותו ל"עורב ד.ב.") לא מצריך התקנה וניתן להריץ במקביל גרסאות שונות שלו החלטתי לפתוח תיקיה ראשית כאשר כל גרסה נשמרת בתיקיה נפרדת .
התקנת גרסאות שונות של רייבן במקביל
התקנה של רייבן כוללת מספר תיקיות ,השמות של כל תיקיה די מסבירים את עצמם וכרגע נתרכז בשתיים רלוונטיות :
Server – בצורה הכי פשטנית שרת הרייבן הוא תוכנת דוט נט שמקבלת ומוסרת הודעות בפרוטוקול HTTP ומכאסנת מידע על הדיסק המקומי. ניתן להריץ את התוכנה בשני אופנים
1. שרת שרץ בתור שירות מערכת , דרך שורת הפקודה (CMD) או מאוכסן באתר asp.net
2. מוטמע בתוך אפליקציה (embedded)
כמובן שבצורה השנייה ניתן לגשת ישירות למסד הנתונים ללא צור ב HTTP
Client – ספריות השירות שבתיקיית client עוטפות את התקשורת בין השרת לאפליקציה ב API פשוט יותר שאינו מצריך להתמודד עם קריאות HTTP ופענוח המידע החוזר.
מבנה תיקיות
כדי להתחיל לשחק עם השרת מפעילים את הקובץ RavenDB.exe עם הרשאות אדמיניסטרטור
כפתור ימני -> הפעל כאדמיניסטרטור
ולהיכנס דרך הדפדפן לכתובות http://localhost:8080 (במקרה הצורך ניתן לשנות את מספר הפורט בקובץ RavenDB.exe.config ולהפעיל מחדש את השרת)
הממשק כמו ספרית ה client שהזכרתי קודם הוא גם עוד מעטפת ל HTTP API של רייבן
עמוד הפתיחה לממשק ניהול רייבן
אגב, הקוד המלא של רייבן זמין ב git hub
משהו קטן שתמיד מעצבן אותי בווינדוס 7 זה פתיחת חלון סייר חדש דרך האיקון בסרגל.
תמיד זה פותח את ה libraries , יכול להיות שלמשתמשים ביתיים זה עדיף אבל אני מעדיף לקבל את הכוננים (computer) ולהמשיך משם
לא צריך הרבה כדי לגרום לזה לעבוד , לחיצה על הספריות בחירה ב properties ושינוי ה target ל :
%windir%\explorer.exe ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
כבר תקופה ארוכה אני סקרן לגבי מסדי נתונים לא רלציוניים (עברית בבקשה מישהו ?) , אבל אף פעם לא מוצא את הזמן או להתחיל. ההשקה לאחרונה של RavenDB דירבנה אותי להתחיל לחפור בענין.
כמובן כמו כל אחד התחלתי מהסוף , הורדתי ,התקנתי ,הרצתי שיחקתי קצת והחלטתי שזהו - הפעם זה זה. הפרויקט האישי הבא שלי מתחיל.
התחלתי סולושן חדש הוספתי פרויקט MVC ומשם דברים התדרדרו … כל שורת קוד שכתבתי העלתה שתי שאלות וכל תשובה שמצאתי העלו עוד שלוש. אז כדי לעשות לי סדר ולהעביר לך (קורא יקר) את הזמן החלטתי לתעד את המסע הזה מהתחלה.
XpostCS
אחד האתגרים שנתקלתי בהם במעבר לבלוג פרטי היה להמשיך לעדכן את הבלוג הראשון שלי במערכת הבלוגים של מיקרוסופט (מה שנקרא בלעז crossposting) . כשעברתי בחרתי את וורדפרס בתור מערכת הבלוג שלי עקב תמיכתה הרבה בתוספים (שלרוב מקלים לי על תהליך הכתיבה והניהול). אחרי חיפוש ושיטוט ברשת וקצת קריאה על איך בלוגים עובדים מצאתי תוסף שמבצע את המטלה אבל בין שני בלוגים של וורדפרס. התוסף משתמש בסטנדרט MetaWeblogAPI שכמעט חופף בין וורדפרס ל CS (הפלטפורמה שמפעילה את הבלוגים של מיקרוסופט) , עם קצת מזל קצת זמן וקצת קפה הכנתי גרסה מתאימה שניתן להוריד ולהתקין ידנית. אם מישהו רוצה להרים את הכפפה ולהכניס את הפלאגין לאתר וורדפרס מוזמן בכיף.
בכל מקרה ראיתי שיש כמה בלוגרים בקהילה שבחרו לעבור לבלוגים חיצוניים ועדיין לעדכן את הבלוג המקורי שלהם , יש מצב שהתוסף יתאים גם לכם.
עד עכשיו התעסקתי בהעברת המידע ללקוח בלי להתחשב בעומסי השרת אך מה קורה שכמות המידע מתחילה להיות ממש גדולה וכבר עוברת את גבולות המכונה ? איך מצליחים למצוא את המידע המתאים מהמכונה המתאימה בזמן סביר ?
Sharding (בתרגום מילולי שבירה לרסיסים) היא שיטה של חלוקת אופקית במאגר מידע או מנוע חיפוש.
מחיצה אופקית היא עיקרון תכנון מסד נתונים לפיו שורות של טבלה מוחזקות בנפרד, ולא על ידי פיצול עמודות (כמו נורמליזציה).כל חלק (שבר) עשוי להיות ממוקם בשרת נפרד או מיקום פיזי אחר. היתרון במחיצות אופקיות הוא הפחתת מספר השורות בכל טבלה (מהלך שמקטין גודל האינדקס, ובכך משפר את ביצועי החיפוש). אם מחיצה מבוססת על חלוקה תבניתית (לדוגמה, לקוחות אמריקאים ולקוחות אירופאים), אז ייתכן שניתן להסיק איזה מחיצה רלוונטית לחיפושינו באופן אוטומטי.
מבנה נתונים לא מנורמל - באופן מסורתי אנחנו מנרמלים את הנתונים. הנתונים פרושים בצורה טבלאית מנורמלת ובשעת צורך אנו מחברים אותם יחדיו על ידי שאילתה. בשברים המידע אינו מנורמל, מידע ממספר טבלאות עם תוכן קשור (לדוגמה טבלת לקוחות וטבלת היסטורית קניה) נשמר באותו מקום.
בעקבות המחקר והעבודה של סונדרס וצוותו הוציאו יאהו כלי בדיקות בשם YSLOW כתוסף דפדפן של פיירפוקס. מאז סונדרס עבר לגוגל וגם הם הוציאו כלי דומה בשם PAGE SPEED במהלך שמזכיר קצת את מיקרוסופט (ולא החלקים הטובים שלה)
בהתאם לממצאים של סונדרס וצוותו גובשו הכללים הבאים:
1. צמצום כמות קריאות HTTP ,זאת על ידי שימוש בטכניקות כמו CSS SPRITES ואיחוד קבצי CSS ו JS .
2. הפצת תוכן סטאטי על ידי שימוש ב CDN,המעבר להפצת תוכן סטטי בעזרת CDN קל יותר ומשפיע יותר משינוי ארכיטקטוני לפיצול המידע הדינאמי (את הטכניקה לפיצול מידע דינמי סקרתי בפוסטים קודמים)
3. שימוש נכון בתאריך תפוגה (expiration header) לכל משאב (לא רק לתמונות), במחקר שערכו גילו כי באתרים שונים הרבה משאבים קבועים (עד כ 70%) יכולים להיות עם תאריך תפוגה ארוך יותר. מעבר לתאריכי תפוגה ארוכים מחייב התייחסות ארכיטקטונית לעדכון גרסת משאב מסוים. לדוגמה – תיקון בקוד האתר דורש שינוי קוד ג'אוה סקריפט, מכיוון שאנו השתמשנו בתאריכי תפוגה ארוכים התיקון אף פעם (או עוד הרבה מאוד זמן) יגיע ללקוחות ותיקים הפתרון הוא חתימת גרסאות בשם הקובץ או כתובתו (URL)
4. שימוש ב GZIP (נכתב כחלק מפרוטוקול HTTP) נתמך ברוב הדפדפנים וחוסך כ 70% מהתעבורה אם משתמשים בו על כל המשאבים הטקסטואליים. בחלק גדול מהמקרים GZIP מופעל רק על קבצי HTML ומזניח שלא לצורך משאבי טקסט אחרים כגון CSS ו JS.
5. להעביר את הקישורים לקבציי CSS לראש העמוד. באקספלורר הדף לא מוצג עד שכל קבצי ה CSS נטענו ותוכנם נותח. בפירפוקס התצוגה תתרענן עם פענוח של CSS חדש.
6. להעביר את הקישורים לקבציי JS לתחתית העמוד, טעינת קובץ ג'אוה סקריפט חוסמת כל הורדה אחרת (בכל מצב אחר הדפדפן מבצע הורדות מקביליות) וחוסמת את רענון תצוגת המסך.
7. להימנע מביטויי CSS (ממשק שנתמך רק באקספלורר (גרסה 5 ומעלה) ומאפשר הפעלת ג'אוה סקריפט מתוך CSS) ביטויי ה CSS מחושבים בצורה מחזורית בכמויות מאוד גדולות ומאטים את פעילות הדפדפן.
8. שימוש בסקריפטים חיצוניים (שימוש בתגי SCRIPT ו LINK לטעינת משאבים חיצוניים) ובכך אחזור משאבים והאצת הטעינה על ידי שימוש במטמון הדפדפן.
9. צמצום חיפושי DNS, נעשה על ידי קריאה למשאבים מכמה שפחות מתחמים (דומיינים), על כל כתובת מתחם חדשה שהדפדפן טוען נעשית קריאה לחיפוש DNS. מצד אחד פיצול משאבים על שמות מתחם שונים גורם לדפדפן לטעינה מקבילית מרובה , מצד שני כל שם מתחם צריך לעבור אימות מול שרתי DNS (פעולה שלוקחת זמן) ההמלצה היא להשתמש בין שניים לארבעה שמות מתחם לתכנים בעמוד.
10. שימוש בכלי ניקוי קוד (minification) להורדת הערות רווחים וקיצור קוד.
11. הימנעות מ REDIRECT אם בקריאות שרת כגון 301 ו 302 או שימוש בקוד HTML META או על ידי ג'אוה סקירפט ככל מקרה תהיה טעינה כפולה הראשונה של הדף המפנה ורק לאחר מכן כתובת היעד.
12. מחיקת סקריפטים כפולים, לפעמים קורה שישנה קריאה לאותם קבצי סקריפט כמה פעמים בעמוד. דבר הנובע בדרך כלל מחוסר תיאום בין צוותי פיתוח שונים באתר.
13. הגדרות ETAGS , תגיות יישות (ETags) הן מנגנון אשר שרתי אינטרנט ודפדפנים משתמשים כדי לקבוע אם רכיב בזיכרון המטמון של הדפדפן תואם אחד בשרת המקור (ישות יכולה להיות תמונות, סקריפטים, CSS, וכו ') .התגיות נוספו לספק מנגנון אימות גמיש יותר מאשר תאריך התפוגה.
14. הכנסת AJAX לזיכרון המטמון, בהרבה מקרים הקריאות הינם פרסונליות והאינסטינקט הראשוני הוא לא לשמור את המידע במטמון. אך למרות שהמידע אישי לא תמיד הוא משתנה לעתים קרובות. מומלץ להשתמש באותה טכניקה שמתוארת בסעיף 3.
סטיב סונדרס, אשר בזמן עבודתו ביאהו היה אחרי לשיפור ביצועי האתרים, הוביל שינוי משמעותי בניתוח והבנה של זמן תגובת אתרים. במהלך עבודתו כתב סונדרס את הספר אתרי אינטרנט בעלי ביצועים גובהים ואת הכלי YSLOW שמנתח זמני טעינת תוכן בצד הלקוח ועצות לשיפור זמן הטעינה.
כחלק מתהליך בנית הקווים המנחים לשיפור הביצועים עשו סטיב וצוותו מספר מחקרים בתחום אשר שפכו קצת אור בתחום ביצועי אתרים.
משך טעינת עמוד
הממצא המשמעותי בעבודתו של סונדרס הוא שהזמן שהעמוד נבנה בצד השרת (כולל הבקשה והחזרה של ה HTML) הוא כ 10% עד 20%. שיפורי ביצועים בשרת הנם הכרחיים לשיפור יחס כמות משתמשים לחומרה, וצריכת חשמל, אך משנים במעט את זמני התגובה של אתר ממוצע. רוב זמן הטעינה עובר על טעינה וניתוח של סקריפטים (CSS \ JS) וטעינה של תמונות ומשאבים אחרים מהרשת.
גישה לזיכרון המטמון
50% מהמשתמשים מגיעים לאתר ללא זיכרון מטמון וכ 20% מכלל הצפיות נעשה עם מנגנון ריק (המחקר נעשה על אתרי YAHOO) , חווית הטעינה הראשונית הנה הרבה יותר נפוצה מהמקובל לחשוב, וצריך לתכנן את האתר בהתאם.
ניתן ללמוד על מחקרים אלו ועוד בהרצאתו.
להלן נקודות למחשבה כשמפתחים שירותים בעומס גבוה:
במידה ואפשר עדיף לעבוד עם מנגנוני מטמון שמקצרים זמני תגובה ומפחיתים עומסי חישוב, כמו הרבה בעיות בתכנון מערכות מדובר ביחס ישיר בין יכולות זיכרון ויכולות עיבוד. שמירת דפיHTML או מידע טקסטואלי (כגון XML JSON) בצורה סטאטית גם משתמש ביכולות מובנות של שרתי ה WEB ותומכים במנגנוני מדרג גדולים מאוד וגם חוסך זמן עיבוד יקר. על פי מקורות שונים ברשת מדובר בגדילה ממאות לאלפי קריאות בשנייה.
לכן אפשר לנצל כוח עיבוד עודף שנמצא במחשב הלקוח. טעינת ממידע בצורה גולמית (שעבר עיבוד מינימלי בשרת) וחישוב התוצאה בצד הלקוח מאפשרת הורדת עומס חישובי. גם אפשרויות של טעינה עצלה של תוכן (על פי דרישה) יכולה להקל על עבודת השרת.
עדיף לצמצם בכמות הקריאות לשרת ולהשתמש במנגנונים לצמצום כמות המידע שעובר ברשת, אם על ידי מנגנוני דחיסה ואם על ידי מנגנוני איחוד. דחיסת תוכן נעשית על ידי הפעלת מנגנוני דחיסה ברמת שרת ה WEB כגון GZIP (אשר נתמך על ידי פרוטוקול HTTP) ואם על ידי מנגנוני תוכנה שמבצעים אופטימיזציות על קוד קיים כגון jsmin או YUI Compressor או טכניקות פיתוח (שכיום דורשות יותר עבודה) כגון CSS Sprites
ההנחה כי ניתן להבטיח שניים מתוך שלושת העקרונות עקביות, זמינות וסובלנות חלוקה היא אמתית וניתן לראות עדות לכך באתרים המצליחים ביותר.
