הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
על מערכת ה־Cache של CppCMS.
אחד המרכיבים המשפיעים על ביצועים של תשתית לפיתוח אתרים היא מערכת ה־Cache. המערכת שיושמה ב־CppCMS כוללת מגוון אופציות ניהול מתקדמות, שלא זמינות בחלק מתשתיות פיתוח אתרים נפוצות כמו Django:
- מערכת טריגרים לרענון ה־Cache.
- ניהול תלויות (כמעט) אוטומטי שמקל על ניהול מידע קונסיסטנטי.
לקריאה נוספת: מערכת Cache: מבנה פנימי (אנגלית)
תגובות
איזה נ.ב. קטן: ב-django הגישה לדברים היא מודולרית, וניתן לדוגמא, כאשר צרכי ה-cache יותר מהרגילים לקחת את ה-cache של satchmo לדוגמא (שלהבדיל משאר החלקים בפרוייקט די עצמאית) אשר מוסיף יכולות רבות, ובתור צ'ופר לקבל גם יכולות ניהול שלו באפליקציה בעזרת ה-views שהוא מספק, כולל יכולות איפוס של cache ספציפי, סטטיסטיקה על יחס ה-hit/miss, קיבוץ ועוד.
נכון, פשוט הייתי מצפה שדברים כאלה יהיו חלק מ־Framework ולא משהו חיצוני.
אני חושב ש־Cache שהוא לא רק מבוסס על "הזדקנות" זה משהו יחסית בסיסי. למשל, WP-Cache, תוסף מאוד פשוט, דואג לרענן עמודים במידת הצורך. זה בהחלט משהו "בסיסי".
אגב, גם פה ה-cache זה משהו יחסית מודולרי וניתן להרחיב אותו עם תשתיות חדשות וגם להוסיף אפשרויות.
למען האמת, זה דיון שנמשך כבר מזה זמן מה בקרב המפתחים והמשתמשים של django, ולא תמיד קל להחליט: איך מחליטים מה צריך להיות בתוך התשתית ומה בדברים חיצוניים (דוגמא נוספת תחת דיון: יכולות אינדוקס וחיפוש). מאחר וקל מאוד להוסיף יישומים חיצוניים לעסק, כמו ב-django-pluggables ,pinax, והמון פרוייקטים בגוגל קוד): http://djangoplugables.com/
לדעתי זו לא שאלה קלה להכרעה באף פרוייקט.
פשוט מערכת Cache זה משהו מאוד נפוץ: כפי שהסתכלתי ב־RoR יש להם משהו בסגנון טריגרים. למעשה, המודל שלי, לקחתי (חלקית) מחשיבה של Asp.Net בה הטריגרים הם מופעלים עם עדכון טבלאות בבסיס נתונים. רק במקום לקשר את זה ישירות לבסיס נתונים נתתי אחראיות למשתמש "ללחוץ על טריגר".
למעשה, cache עם טריגרים זה בהחלט משהו מאוווד נדרש.
המחשבה שלי, שב־Django נגררו אחרי memcached. כי הוא תומך רק ב־timeout ולא ניתן לקשר טריגר מסוים להרבה ערכים תלויים. לכן, מודל אחר מעבר ל־timeout אומר שלא ניתן להשתמש ב־memcached --- ובין השאר אולי צריך לבנות שרת דמוי memcached שיעשה את העבודה ולצאת ממסגרת Python הטהורה.
המודל הנוכחי של Django הוא מאוד קל למימוש, הצעד הזה קדימה מסבך אותו בצורה משמעותית.
זה קל מאוד להגרר אחרי פתרונות קיימים... אבל, לפעמים צריך לצאת מהמסגרת
;-)דווקא למקרים שה-cache ב-django תוכנן לטפל, כמו slashdotting מאסיבי, עדיף cache פשוט שלא מתעדכן עם כל כתיבה או שינוי.
ליישם את השני זה פשוט מאוד, שמים timeout ארוך וסיגנל קטן שמטפל בזה. ואז נשאלת השאלה, אם זה מאוד פשוט למה לסרבל את התשתית ? (מצד שני.. וחוזר חלילה לדיון על מה צריך להיות ב-core ו-contrib).
אתה באמת חושב שזה פשוט? תחשוב על מערכת מבוזרת ב־5 שרתים, על פורום שיש בו מאות דיונים שמורים בזכרון וכל דיון תלוי בעשרות הדעות וחתימות של משתמשים הנמצאים ב־cache ועוד כל מיני פרמטרים? איך בדיוק תקשר את הסיגנלים? איזה timeout תחבר?
בואו נגיד ככה, זה לא ממש פשוט... לפחות למיטב הבנתי.
אגב, בבלוג הפשוט הזה, אני בכלל לא משתמש ב־timeout --- הכל עובד על טריגרים. אם היה לי רוחב פס מספיק טוב, אני לא חושב שהייתה לי בעיה כלשהי לעמוד ב־slashdot.
נ.ב.: שתבין, אין לי שום דבר נגד Djnago, יכול להיות שעבורו זה מספיק. אבל עבור Framework שאני בונה שאמור לעמוד בצורה יפה בעומסים ענקיים, cache מתוחכם הוא בגדר חובה
מספיק שיש מונה שסופר כניסות לכל פוסט ואתה מציג את מספר הצפיות בעמוד - הוא יופעל עם כל פניה ב-slashdotting. במקרה כזה גם טריגר לא יעזור לך, להפך, רק תקבל עוד overhead. במקרים של slashdotting שכאלה, עדיף לעדכן את המונה בבסיס הנתונים, אך לא לעדכן את ה-view שיוצג כמות שהוא ב-cache.
הנה יישום פשוט של העסק, מאוד קל להתבסס עליו ולהרחיב אותו לצורות מתוחכמות יותר תוך שמירה על גמישות מירבית: http://www.djangosnippets.org/snippets/629/
אני מאוד מקווה שמישהו שבונה מערכת על בסיס CppCMS שמוכנה ל־slashdotting לא תשים שטות כזו בצורה שקופה.
המפתח בוחר איזה טריגרים לשים ואיזה לא. אם הוא לא ישים טריגר על מונה, אז לא תהיה לו בעיה.
שוב, אתה לא חייב להשתמש בטריגרים, אבל אתה יכול
בוודאי, ללא ספק. אך אז המידע המוצג אינו מדוייק (וחזרנו לפשטות של time based), וחזרנו לנקודת ההתחלה, משם הסיבוכיות רק גדל: יש פורום, כמות הצפיות בנושא, כמות הפוסטים של משתמש, האם הוא מחובר כרגע, כמה צופים בפוסט מסויים, כמה מחוברים לפורום, מחוברים רואים עמוד אחר מלא מחוברים (לפעמים פר משתמש מחובר) אתה יכול להגיע בקלות למצב שה-miss עולה ה-hits.
מהר מאוד מאבדים את השליטה על כך, כי המורכבות של לנהל את זה רק עולה עם הפונקציונליות.
שלא תבין, זה היה נחמד אם היה ב-Django לדוגמא, אך מאחר וקל ליישם משהו שמתאים (או לקחת כזה), ו-time based עונה על מגוון רחב של נושאים, זה לא חסר.
טוב, אולי, אני לא מומחה גדול בתחום אינטרנט. כל הפרויקט הזה הוא ניסוי אחד גדול.
נראה
הוסף תגובה:
חובה לאפשר JavaScript כדי להגיב.