ניהול קאש למאות קריאות במקביל

nigun

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

בצד שרת אני קורא ממערך שנמצא בזיכרון וממיר אותו לJSON.
אבל כדי למנוע קריאה וכתיבה מקבילים למערך אני במבצע נעילה לפני כל קריאה.
(מדובר בRLOCK אז הוא נועל רק קריאה וכתיבה במקביל, ולא שתי קריאות מקבילות)

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

השאלה שלי היא האם זה ללא הגבלה?
האם אני כדאי לשמור הכל בזכרון או שהשרתים המודרנים מנהלים קאש לבד?
האם כדאי לשים את זה בשרת נפרד? מכונה נפרדת?

aaron

@nigun אמר בניהול קאש למאות קריאות במקביל:

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

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

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

API מקבל עדכונים
העדכונים מועברים לתור (RabbitMQ למשל, לבדוק עם קריטי FIFO..)
תהליך בודד מבצע לוגיקה ומעדכן את רדיס (חסכת נעילות)
קריאות ישירות מרדיס, 0 לוגיקה.

nigun

@aaron
האפליקציה כתובה בGO
כך שהרבה יותר קל לנהל את זה בזיכרון.

@aaron אמר בניהול קאש למאות קריאות במקביל:

ואת כל הניהול של הכתיבה, תכניס לתוך Q שיידע לבצע את זה בתיאום עם הנעילות.
ארכיטקטורה הגיונית לדעתי זה:

API מקבל עדכונים
העדכונים מועברים לתור (RabbitMQ למשל, לבדוק עם קריטי FIFO..)
תהליך בודד מבצע לוגיקה ומעדכן את רדיס (חסכת נעילות)
קריאות ישירות מרדיס, 0 לוגיקה.

לא מכיר כל כך את רדיס.
יש לו נעילות בכתיבות מקבילות?

dovid

@nigun
2000 צופים == 2000 קריאות בשניה?? מה הם מבקשים כל הזמן? שניית צפיה?
עכ"פ 2000 זה בשניה זה כלום גם עם נעילה.
"אני קורא ממערך" מתי? כל קריאה?

nigun

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

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

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

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

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

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

nigun

במחשבה שניה
לכאורה כל in-memory key/value store משתמש בנעילה כל שהיא
(אני שיש כאלו שכותבים במפורש שמשמשתים במערך)

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

עריכה: אני רואה שגם go-memdb מבצע נעילה בכתיבה
אבל משום מה הוא לא נועל בקריאה אפילו כשהוא קורא ממערך .

עריכה2:
זה נראה שהוא יוצר משתנה חדש שמצביע למערך המקורי
וכך הוא קורא רק מהמשתנה החדש, ללא הגבלה.

dovid

@nigun אמר בניהול קאש למאות קריאות במקביל:

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

למה זה קשור?

nigun

@dovid אמר בניהול קאש למאות קריאות במקביל:

@nigun אמר בניהול קאש למאות קריאות במקביל:

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

למה זה קשור?

מה הדרכים לעדכן את הלקוח שיש שינוי?

dovid

@nigun אתה אמרת, וובסוקט...

nigun

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

dovid

@nigun
הבעיה שיש עומס הרבה הרבה יותר גדול.
כל שניה יש 2000 בקשות http חדשות לחלוטין,
הרבה לפני שאתה חושב על המערך שלך תחשוב על הרשת, על קצב העלאה הורדה, על יכולת שרת הhttp וכולי. המערך זה הכי הכי זניח פה. נראה לי שבשניה מחשב מסוגל להרבה הרבה מעבר לזה.

clickone

@nigun אמר בניהול קאש למאות קריאות במקביל:

אז אני חושב לשמור את כל הJSON כל שניה בדף סטטי (כולם קוראים את אותם נתונים)

אני מתחבר לזה (במקרה שלך....)
עם קאש מנוהל -לדוגמא מאחורי קלאודפלר

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

nigun

@clickone @dovid
עשיתי עכשיו הדמיה
וכל בקשה שוקלת 75 KB ואורכת 300- 450 ms (השרת בחו"ל)
אם אני עושה בדיקת עומסים (עם הכלים המיועדים לכך) משרת ישראלי (של 8 ליבות)
זה באמת יצליח לדמות את זה?

nigun

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

עריכה: במקרה הזה יכול להריץ לולאה ידנית
השאלה היא מה דרך הנכונה באופן כללי?

חוקר

@nigun
מה שאני עשיתי בNODEJS הוא כך.
יוצר משתנה (מעל הבלוק של השרת, דהייני משתנה שנמצא בסקופ הראשי והוא יהיה זמין לכל בקשות הHTTP ולא נוצר לכל בקשה מחדש).
וכאשר אני מקבל בקשה אני בודק, באם המשתנה עדיין לא מוגדר, או שהוא מוגדר אך ה lestTime שלו הוא מעל שניה אחורה, אני מגדיר מחדש את המשתנה עם פרומייז ובתוכו מבוצעות פעולות החישוב, המחזירות בסיומם את הערך העדכני כולל עדכון ה lestTime לתאריך ושעה הנוכחים.
באם הוא מוגדר והוא עודכן לפני פחות משניה הוא מחזיר את הערך העדכני.
מה שאני מרוויח: הפעולה מבוצעת לכל היותר פעם אחת בשניה לכל הבקשות יחד, וברגע שעברה שניה מהעדכון ויש בקשות חדשות, הן ממתינות את הכמה מאות מילי שניות לביצוע החישוב, וכל בקשה נוספת מצטרפת להמתנה, וברגע שהחישוב הסתיים כולם מקבלים יחד את התשובה, והבקשות הבאות באותה שניה כבר מקבלים תשובה מוכנה ללא המתנה.
אני לא יודע איך לתרגם אותו לשפה שלך, אך זה הכיון.

let myData = {};
    'GatStatistics' : function(DinerId, QuestionId){
        if (!myData.Statistics[DinerId]){
            myData.Statistics[DinerId] = {};
        }
        if (!myData.Statistics[DinerId][QuestionId] || moment().diff(myData.Statistics[DinerId][QuestionId]['lestTime']) > 1000 ){
            myData.Statistics[DinerId][QuestionId] = database.selectSQL('SELECT COUNT(`id`)...', [QuestionId, DinerId]).then(row => {
                let StatisticsData = {
                    'General' :  {'true' : 0, 'false' : 0},
                };
...// פעולות חישוב שונות..
                return myData.Statistics[DinerId][QuestionId] = {'lestTime' : moment(), 'StatisticsData' : StatisticsData, 'PercentStatisticsData' : PercentStatisticsData, 'PercentStatisticsDataHe' : PercentStatisticsDataHe};
            }).catch(error => {
                console.error(error);
                return {'status' : 'error'};
            });
        }else {
            return new Promise((resolve, reject) => {
                resolve(myData.Statistics[DinerId][QuestionId]);
            })
        }
        return myData.Statistics[DinerId][QuestionId];
}

//הגדרות השרת שמטפל בבקשה
            if (Action === 'GetStatistics'){
                return myData.GetStatistics(DinerId, myData.Users[DinerId].QuestionId).then(res1 => {
                    res.send(res1);
                }).catch(error => {
                    res.send({'status' : 'error'});
                    console.error(error);
                });

בהצלחה

nigun

@חוקר
מה אתה עושה אם עברה שניה, ועכשיו מגיעים 100 בקשות חדשות
ולוקח 200 מילי שניות לבצע את החישוב, איך אני יודע שהבקשה השניה והלאה אמורה להמתין בתור ולא להפעיל חישוב חדש?

dovid

@nigun בנוד מתבצע בכל רגע נתון רק פקודה אחת, כך שגם אם יש מיליון בקשות ביחד, הם עוברות את הקוד בזו אחר זו (סדרתי) ולא יחד (מקבילי - parallel). ברגע שהראשונה עברה את השורה שיוצרת את הפרומייס, כל המיליון שאחריה מחכים יחד לסיומו של הפרומייס.
כדי להגיע לתוצאה דומה בסביבות שמאפשרים ריצה מקבילה של קוד כמו go נדרשת פה נעילה: קטע קוד שרק תהליך אחד יכול להיכנס בזמן נתון. ניהול מלא ידני של כל הסיפור הזה הוא קצת בגדר המצאת הגלגל.
אבל שוב, 2000 קריאות בשניה זה עומס כבד עוד לפני שזה בכלל מגיע לטיפול ביישום גו/נוד. אם אפשר לחסוך בזה זה מבורך. שנית, המצב הזה של עדכון במערכת אחת וחיווי במערכת אחרת הוא בדיעבד. הכי טוב שהמערכת שמדווחת היא זו שגם מעודכנת ומעדכנת את נתוני האמת.

nigun

@dovid אמר בניהול קאש למאות קריאות במקביל:

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

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

nigun

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

אבל בכל אופן אלו התוצאות
אני משתמש בכלי הזה
עם הפקודה:
hey -n=20000 -c 1000 https://foo.com/123
השרת ביעד בגרמניה עם 4 ליבות
השרת מקור בישראל עם 8 ליבות.

וזה שיצא לי (משרת בודד , ניסתי מ8 שרתים במקביל באותו חווה והצלחתי קצת יותר)
אם הנפח של הדף מזערי (שתי בתים)

Summary:
  Total:        3.8496 secs
  Slowest:      1.1881 secs
  Fastest:      0.0436 secs
  Average:      0.1771 secs
  Requests/sec: 5195.3434
  
  Total data:   40000 bytes
  Size/request: 2 bytes

Status code distribution:
  [200] 20000 responses

אם אני פונה לדף שמעבד את הJSON המלא

Summary:
  Total:        69.1280 secs
  Slowest:      20.0005 secs
  Fastest:      0.0571 secs
  Average:      2.9715 secs
  Requests/sec: 289.3182
  
  Total data:   3017224704 bytes
  Size/request: 151103 bytes

Latency distribution:
  10% in 0.3257 secs
  25% in 0.5548 secs
  50% in 1.6305 secs
  75% in 4.6217 secs
  90% in 7.5400 secs
  95% in 9.4389 secs
  99% in 13.8774 secs

Status code distribution:
  [200] 19968 responses

אבל אם אני מוריד קובץ JSON עם אותם נתונים

Summary:
  Total:        16.7998 secs
  Slowest:      9.6546 secs
  Fastest:      0.1323 secs
  Average:      0.5592 secs
  Requests/sec: 1190.4893
  
  Total data:   3022060000 bytes
  Size/request: 151103 bytes


Latency distribution:
  10% in 0.2492 secs
  25% in 0.3162 secs
  50% in 0.4198 secs
  75% in 0.6441 secs
  90% in 0.9791 secs
  95% in 1.2955 secs
  99% in 2.3361 secs

Status code distribution:
  [200] 20000 responses

חוקר

@nigun אמר בניהול קאש למאות קריאות במקביל:

[200] 19968 responses

רק שים לב, 32 מתוך 20000 בקשות נכשלו..

תחומים - פורום חרדי מקצועי

ניהול קאש למאות קריאות במקביל