להאיץ את מה חדש

אנונימי

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

מה הסיבה? האם אני יכול לפתור אותה (הבעיה אצלינו?), או שמא הבעיה היא במערכת?
אנא עיזרו לנו להתחבר מהר יותר לעולם טוב יותר!!!

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

עוד אפשרות זה לסמן את הסתר את הסמלים של סוגי השינויים. כל אחד מהסמלים הוא קובץ גראפי שנטען בנפרד למחשב.

למה לא להעלות את הדף בחלקים? יהיה יחסית קל לממש את זה באקספלורר (ומשתמשי נטסקייפ בכל מקרה רגילים לזמני תגובה בלתי הגיוניים...

)

כמה שרונים יש? כל פעם צץ "שרון" חדש . . .

-- "משפחה ברוכת 'שרונים'" . . .

שי, על איזה חלקים מדובר? פעם העלנו את ה-XSL-ים בנפרד, אבל אז הם לא עלו אצל חלק מהמשתמשים.

לפי מה שאני מבין, החיבור בין ה-XML וה-XSL נעשה פעם אחת עבור כל הנתונים ב-init.
חשבתי על כמה אפשרויות:

להעלות את ה-XML בחלקים (לפי ימים לדוגמא) ולהציגם בטבלאות נפרדות.

במידה וזמן הפענוח וההצגה מעקב את עליית הדף:

לפענח את ה-XML בשרת או להשתמש ב-XMLDOM ו-JavaScript במקום ב-transform
להשתמש ב-DOM להוספת התוכן ל-results (בדרך כלל יותר מהיר מלעדכן את innerHTML).

שמתי לב גם שעבור כל תמונה הוא ניגש לשרת (אולי רק במחשב שלי). אפשר לפתור את זה בעזרת javascript או ברמת ה-web server (להצמיד לקבצים בספרייה תאריך פקיעה (content expiration) ל-2010 לדוגמא ואז הדפדפן לא ייטרח לגשת לשרת).

החיבור בין ה-XML וה-XSL מתבצע מחדש בכל פעם שהמשתמש משנה את האפשרויות. האפשרויות מוכנסות לתוך Node מיוחד ב-XML, ואז ה-XSL משתמש ב-Node הזה בשביל להחליט מה לסנן החוצה ומה להשאיר, ובאיזה סדר. אחר כך התוצאה מפורמטת על ידי XSL נוסף (אחר), ומוכנסת כמקשה אחת לתוך ה-innerHTML של results.

ה-XML ושני ה-XSL נטענים ביחד עם הדף בתור Data Islands. נראה לי שלטעון אותם לשיעורין (בסגנון של מה שהראת לי בעבר) זה די מסובך, לא? כרגע זה פשוט דף אחד שמורכב בשרת וזהו.

האם מהנסיון שלך להשתמש ב-JavaScript תוך גישה ל-XMLDOM זה מהיר יותר מ-transform? נשמע לי שזה צריך להיות הפוך.

עשיתי נסיון להוסיף את התוכן ל-results לשיעורין, אבל יש עם זה בעיה: התוכן המוסף צריך להיות "נקי" מבחינת HTML, כלומר, אי אפשר להכניס חלקי טבלאות וכו', כי הדפדפן מייד משלים את החלקים החסרים (אפשר אולי לסמן את המקום הבא שבו אמור להיות מוכנס משהו ואז להמשיך משם? נראה קצת מורכב).

לגבי התמונות -- אני אבדוק את זה.

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

נראה לי שאם תפרק את ה-XML לפי ימים וכל יום יהיה בטבלה נפרדת, תוכל לזרוק אותם אחד אחרי השני, לדוגמא:

הדף המקורי יכיל 3 data islands ו-3 טבלאות ריקות (עבור 3 ימים)
כל data island יעלה מהשרת את ה-XML המתאים, יפענח אותו (XMLDOM/transfom) וימלא את הטבלה המתאימה.

אין לי מושג אם XMLDOM יותר מהיר מ-transform (אני אבדוק את זה), הסיבה שציינתי את האפשרות הזאת היא בגלל השליטה שיש לך בפענוח (בניית הטבלה ב-DOM, הדפסה של ה-HTML המפוענח בשלבים וכו).

אני אשמח להכנס לקוד ברגע שיהיה לי זמן (יש לי קצת בעיה עם העובדה שהמערכת אמורה לתמוך גם במשתמשי netscape...)

אוקיי, מבדיקה קצרה שעשיתי, transform יותר מהיר משימוש ב-XMLDOM לפענוח.
לגבי שימוש ב-DOM לבניית הטבלה במקום שימוש ב-innerHTML הדעות חלוקות. קרן טוענת ש-innerHTML יותר מהיר, ואני ששימוש ב-DOM (למרות שניסוי שעשיתי מראה שהיא צודקת...). לאחר מאבק ארוך סיכמנו ש-innerHTML מהיר יותר אבל שימוש ב-DOM הוא יותר נכון (רק כדי שאני לא אצא לוזר...)

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

כמה כתבות מעניינות:
http://msdn.microsoft.com/library/defau ... 100499.asp
http://msdn.microsoft.com/library/en-us ... frame=true
http://msdn.microsoft.com/library/defau ... rftips.asp

בינתיים קראתי את המאמר הראשון (אקרא את האחרים בהמשך). מאד מעניין. על פי מה שכתוב שם יכול להיות שיש סיבה טובה לשנות את שיטת העבודה של מה חדש. כיום אני מייצא קוד HTML גדול באמצעות ה-transform, ואז דוחף אותו לעמוד באמצעות innerHTML. אני הערכתי שהפעולה הזו כוללת בעצם Reparsing של העמוד, אבל נראה לי שעדיף שהיא תקרה בבת-אחת ולא טיפין טיפין כשכל שורה נוספת. לפי מה שהמאמר הראשון אומר עשוי להיות עדיף להוסיף את השורות אחת אחת (אם כי הוא מדבר על בניה של השורות כאלמנטי HTML ולא כטקסט כמו שאני עושה).

כמו כן כדאי אולי להוסיף defer לכל תגי ה-script. אתה יודע במקרה אם defer עובד גם על XML? הרי תגי script יכולים להכיל XML גם כן. לדוגמא: <script language=xml>. אז אולי אפשר לעשות <script language=xml defer> וזה ימנע parsing של ה-XML עד לגמר הטעינה?

אגב, נתקלתי בתופעה מוזרה -- לפעמים כשאני מנסה לגשת ל-XML Data Island דרך ה-DOM, אני מקבל אובייקט XML, ולפעמים לא. לדוגמא, אם יש לי <XML ID=BLA> איפשהו, אז ב-javascript אני מנסה לבצע עימו פעולות: {{alert (BLA.xml)}}. לפעמים זה עובד, ולפעמים BLA לא מתנהג כמו XML node ואז אני מקבל string ריק. במקרה הזה אני צריך ליצור אובייקט XML חדש, ולטעון לתוכו את התוכן של BLA, לדוגמא:
{{JavaScript
var flag = false;
try {
xmlData = document.all("BLA");
if (xmlData.xml

"" || xmlData.xml

null) flag = true;
} catch(e) {
flag = true;
} if (flag) {
xmlData = new ActiveXObject("Microsoft.XMLDOM");
xmlData.async = false;
xmlData.loadXML(document.all("BLA").innerHTML);
};
}}

אני חייב את כל הבדיקות המוזרות הללו כי אי אפשר לדעת מה בדיוק יכול להשתבש. עד כמה שאני הבחנתי ה-IE לא מתנהג בצורה עקבית בעניין הזה. בכל מקרה, נראה לי שהטעינה החוזרת הזו של ה-XML גורמת ל-parsing מחודש, שלוקח מן הסתם לא מעט זמן. יש לך רעיון כלשהו בקשר לזה?

אסור לכתוב בסינית באתר

אני בדרך כלל משתמש ב-ondatasetcomplete כדי לדעת מתי ה-XML זמין, יכול להיות ש-onload ברמת הדף לא מחכה עד שאובייקטי XML מוכנים וזו הסיבה שאתה מקבל מחרוזת ריקה? (בדקת מה parseError מכיל כשאתה מקבל XML ריק?)

לגבי הכתבה הראשונה, לא כל כך ברור לי אם השיטה הקיימת ב"מה חדש" פחות מהירה. מניסוי שעשיתי עם טבלה המכילה 1000 רשומות, כתיבה למחרוזת ושימוש ב-innerHTML היה מהיר בהרבה מבנייה של הטבלה בעזרת DOM.

אף פעם לא השתמשתי ב-defer אבל ממה שראיתי ב-MSDN רק ל-script יש property כזה.

מישהו רגיש במיוחד - מה לעשות שהאתר כתוב באמצעות הסינית הזאת.

אוי כמה נהנתי לקרוא את הדף הזה.
רועי, מה הפלא שאתה משורר?
שירה צרופה, פיוט עם נגיעה לפרוזה.

חוץ מזה עלתה בי טרוניה מסוימת כשחשבתי על מה חדש:

למה לדחוף למה? מה בוער? מה זה פה? חדשות?

מעולם לא כתבתי משהו מהסוג הזה, אז בטח יש כאן כמה רעיונות לא ממש מוצלחים. אבל בכל זאת...

איך אתם יוצרים את קובץ מה חדש על השרת?

האם ציק צק בודק את תאריכי השינוים של הקבצים בכל בקשה למה חדש?
או שהוא מחזיק בזיכרון hash table שמתעדכן בכל פעם שדף עובר עריכה כלשהיא?

נניח שבכל פעם שדף עובר עריכה, נוצרת שורה חדשה בטבלה שם דף: רשימת 4-5 שינויים אחרונים, תאריך שינוי אחרון
ובנוסף מתעדכנת רשימה של שינויים בפורמט: זמן, דף שתשמש לשליפת נתונים מתוך הטבלה בהמשך. הרשימה ממוינת כמובן, מאחר והיא נבנית באופן כרונולוגי.

כשאתה מקבל בקשה לנתונים למה חדש, אתה שולף מהרשימה את כל השינוים שמתאימים למספר הימים, ושולף מהטבלה את האינפורמציה לכל שינוי. בגלל שהכל נשמר בזיכרון, ושליפת נתונם מרשימה ממוינת היא מהירה ביותר, לא שונה בהרבה ממערך ב-C ? ושליפת נתונים מטבלת מהזיכרון היא מהירה מאד ולא תלויה בגודל הטבלה, זה צריך לקחת מעט מאד זמן.רק צריך לפרמט כ-xml ולשלוח.

עכשיו רק נשאר לכתוב את זה כתוכנת שרת נפרדת, "שרת מה חדש", שירוץ על מחשב אחר משרת הדפים או באותו מחשב כתהליך נפרד, ויש לך פתרון מהיר לאספקת דפי מה חדש, בלי קשר לשרת הדפים. שרת מה חדש לעולם לא ניגש לדיסק של השרת. בעצם לעולם אין צורך בגישה לדיסק כדי לבדוק איזה קבצים השתנו, כי כל שינוי מתועד על ידי שרת השינויים. קצת דומה למערכת קבצים עם Jornaling, שכל שינוי מתועד.

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

כמובן שצריך לפתור את הבעייה של התקשורת בין שני השרתים. שרת הדפים צריך להודיע לשרת מה חדש בכל פעם שמשתנה דף, כדי לעדכן את הטבלה והרשימה בזכרון. השינוי צריך להיות מאד מהיר, כי מדובר בהעברה מעט מאוד מידע, שליפת שורה בטבלה ועדכון של רשימת כותבים, בכל פעם שמשתנה עמוד.

האם רצים כמה תהליכים של ציק צק באותו זמן על השרת? האם שרת מה חדש גם יצטרך לרוץ בצורה כזאת על מנת שהשרת יוכל לטפל בו זמנית בכמה בקשות, או שבעצם אין טעם לטפל ביחד בכמה בקשות ועדיף שיחכו בתור לטיפול על ידי תהליך אחד?

הי ניר,
את מה חדש מדדנו עוד על השרת הישן והאיטי, וגילינו שזמן החישוב על השרת הוא זניח. מה שלוקח זמן זה בעיקר התקשורת, וקצת חישובים על הלקוח (למי שיש מחשב איטי). לכן המדיניות שלנו בנושא היא לצמצם כמה שיותר את כמות המידע שנשלח, ולא להתאמץ לייעל את החישוב על השרת.

הבנתי. אבל בכל זאת מענין איך אתם מיצרים את הנתונים למה חדש על השרת?

וחוץ מזה, נראה שמה חדש מכיל פחות אינפורמציה מהרבה עמודים אחרים, אבל בכל זאת עולה יותר לאט.

אם הייתם שולחים קובץ HTML סטטי, הוא הייה יכול לעלות בחלקים, נניח כל יום בטבלה נפרדת, או בטבלאות לכל 10 שורות, והיה מגיב הרבה יותר מהר. נכון שאז מעבדים את הדינמיות של התוכן, אבל זה יאיץ בהרבה את עליית העמוד. כל העמוד יעלה אולי יותר לאט מאשר העמוד הדינמי, אבל המסך הראשון יופיע כמעט מייד. עד שגומרים לעיין בשינוים שמופיעים במסך הראשון, כבר יעלה כל העמוד, או לפחות המסך השני.

זה אומר להכין על השרת את הדף - החישוב זניח כמו שאת אומרת, אז רק צריך לתפור את הדף מכותרת ותחתית קבועים, ואת התוכן אפשר להחזיק בזיכרון ולעדכן בכל פעם שעמוד נשמר. אפשר להחזיק את התוכן מפורמט? נניח כתאים של טבלה? זה יחסוך את הפירמוט כשצריך לשלוח.
הדבר היחיד שהשרת יצטרך לעשות הוא לתפור את הדף לפי כמות הימים שהלקוח מזמין, מחלקי דף שכבר מפורמטים. יקח יותר זיכרון, אבל יחסוך הרבה חישוב על השרת, ואת כל החישוב אצל הלקוח.

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

התייחסתי כבר ב-שינויים בצ'יק צ'ק לשאלה למה בחרנו למקם את תהליך החישוב של מה חדש על הלקוח ולא על השרת, ולכן רק אציין נקודות מפתח בהחלטה הזו:

רוב המשתמשים עובדים עם הסתר שינויים שכבר ראיתי מופעל, מה שאומר שצריך לחשב את הדף עבור כל משתמש בנפרד גם אם המשתמשים לא מנצלים את התכונות הדינמיות של מה חדש.
חישוב על השרת מגביל את ה-scalability של המערכת. עבור מעט משתמשים זה לא יורגש, אבל עבור אלפי משתמשים זה כבר יתחיל להיות מעיק. מעבר לכך, הנחנו שצ'יק צ'ק יותקן בכל מיני מקומות שלא יכולים להרשות לעצמם שרת נפרד, ולכן חולקים את השרת עם עוד אתרים שגם להם יש צרכי CPU. בפועל אנו יודעים שגם עם רמת החישוביות הנמוכה יחסית של צ'יק צ'ק אנו עדיין מקבלים מדי פעם תלונות מהחברה שמפעילה את השרת עליו רץ אתר באופן טבעי לגבי רמת הצריכה של ה-CPU.
כפי שכבר אמרתי, הקבוצה שכן משתמשת באפשרויות הדינמיות של מה חדש מעניינת אותי במיוחד, ואני מעדיף לתכנן את המערכת כך שתתן להם מענה טוב. אם היינו מחשבים את הדף על השרת אז כל שינוי באפשרויות היה דורש קריאה מחודשת של הדף. לא נעים.

בכל מקרה, הנתונים על השרת מוחזקים בלוג כרונולוגי של שינויים, אשר מתוכו נבחר הקטע הנדרש על ידי המשתמש ומתורגם ל-XML לפני העברה אל הלקוח.

שתי הבהרות:

אכן היו תלונות על צריכת ה-CPU שלנו בשרת, אבל מדידה הראתה שזה לא באשמת צ'יק צ'ק אלא באשמת Perl עצמה -- השרת מטעין אותה בכל פניה לסקריפט מחדש, וזה צורך יותר משאבים מאשר הרצת הסקריפט עצמו. לכן אמרתי לבעלבית שיתקין mod perl או יקנה מחשב מהיר יותר. הוא בחר באפשרות השניה.

הנתונים של מה חדש נקראים מתוך לוג חלקי, ששומר רק את אלף השינויים האחרונים, ומסודר בסדר כרונולוגי יורד. (כדי שלא יהיה צריך לקרוא את כל הקובץ בשביל לבדוק מה השינויים בשעה האחרונה.)

מה זה שינויים שכבר ראיתי?

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

שמתי לב שהרבה אחרי ש-מה חדש כבר נטען, הוא ממשיך להוריד לי את קבצי התמונה של ה bullets אחד אחד, וזה לוקח לו הרבה זמן, וגם מבזבז לי את משאבי הרשת. כשאני בבית, בחיבור מודם רגיל, אני לוחץ על קישורים מתוך מה חדש עוד לפני שהוא גומר להטען, אבל הדפים שנפתחים לא מראים לי כלום עד שכל ה bullets ירדו (וה IE מראה לי כמה עוד נשארו להוריד).

אני חושב שזה קשור להגדרות הדפדפן שלי. מסומן לי (לצרכי עבודתי) ב check for newer versions of stored page האופציה every visit to the page.
כשאני משנה את זה ל automatically זה מסתדר.

אולי אפשר לעשות אופציה לוותר על ה bullets?

זו נראית לי פינה ספציפית מדי. אבל אתה תמיד יכול ללחוץ על כפתור העצירה.

צודק.
יחד עם זאת, כשאני רואה את הבולטים עולים אחד אחד, הם למעשה מכסים בולט אחר שכבר ישנו שם, אבל הוא טיפה יותר קטן. האם כל זה נחוץ?

עודד, לפי דעתי כבר קיימת בדיוק האפשרות שאתה מחפש - "הסתר את הסמלים של סוגי השינויים"
(גם אצלי זה "every visit to the page" מסיבות עבודה ושמחתי לגלות את האופציה)

הם למעשה מכסים בולט אחר שכבר ישנו שם, אבל הוא טיפה יותר קטן. האם כל זה נחוץ? -- זה חלק מהעיצוב של האתר. האם זה הכרחי זה עניין של טעם וריח.

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

האם זה הכרחי זה עניין של טעם וריח. לא התכוונתי אם הבולטס הכרחיים, רק אם זה שיש בעצם שניים אחד על השני הכרחי. זו שאלה טכנית, לא עיצובית.

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

בכל מקרה אתה יכול לקבוע לעצמך CSS שמציג תבליטים לפי רצונך דרך אפשרויות האינטרנט של הדפדפן (General

Accessibility). לדעתי זה לא כל כך נוח (כי זה משפיע על כל האתרים) אבל ייתכן שזה טוב עבורך.

ומי שיצליח להסביר לי פעם איך יכול השרת לגרום לדפדפן לא לטעון כל תמונה בנפרד, גם אם התמונה הזו חוזרת מאתיים פעמים בתוך הדף, יזכה בהערכתי (כמה שהיא שווה).

מה עם ליצור אוביקט ב JS ולהשתמש בו
משהו כמו ...

{{
SCRIPT LANGUAGE = "javascript">
<!--

if (document.images) { // Active Images
img1on = new Image();
img1on.src = "button1 on.jpg";

img1off = new Image();
img1off.src = "button1 off.jpg";

או
http://www.handson.nu/CODING/javascript.shtml

אבישלום, הקוד הזה בסיסי. האם מניסיונך זה גורם לכל התמונות בדף (שמאותו הקובץ הגראפי) להטען רק פעם אחת? לא נראה לי שזה שונה מסתם לכתוב:
{{HTML
<IMG src="bla.gif">
<IMG src="bla.gif">
<IMG src="bla.gif">
<IMG src="bla.gif">
<IMG src="bla.gif">
<IMG src="bla.gif">
}}
אבל עובדה שזה נטען תמונה אחרי תמונה.

רועי , לא ניסיתי לשחק עם זה , אבל כשיהיה לי זמן אז ...
אני בטוח שיש דרך לאחר שיצרת new אובייקט , להשתמש בו שוב ושוב. אני לא מכיר הפניות byref ב js .
(זה מופיע בהקשר של button rollover כדי שלא יקח זמן לתמונות לעלות לכן אני מאמין שזה לא כמו בקוד שכתבת)

אני לא מצליחה להכנס למה חדש, או לכל דף אחר באתר, רק לדפים שעולים במקרה באינטרנט, מישהו?

אוי, את כבר השלישית

לא הצלחתי לגלות מה גורם לזה, אז בינתיים אפשר פשוט להשתמש בדפדפן אחר: http://www.mozilla.org/firefox