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

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

💡 רוצה לזכור קריאת שמע בזמן? לחץ כאן!
  1. דף הבית
  2. תכנות
  3. ניהול קאש למאות קריאות במקביל

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

מתוזמן נעוץ נעול הועבר תכנות
31 פוסטים 6 כותבים 621 צפיות 6 עוקבים
  • מהישן לחדש
  • מהחדש לישן
  • הכי הרבה הצבעות
תגובה
  • תגובה כנושא
התחברו כדי לפרסם תגובה
נושא זה נמחק. רק משתמשים עם הרשאות מתאימות יוכלו לצפות בו.
  • nigunN nigun

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

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

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

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

    A מנותק
    A מנותק
    aaron
    כתב ב נערך לאחרונה על ידי
    #2

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

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

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

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

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

    aaron.tchumim@gmail.com
    Hetzner - שרתים וירטואליים ופיזיים במחירים מעולים (קישור שותפים)

    ווצאפ API - תיעוד שירות API לא רשמי.

    nigunN תגובה 1 תגובה אחרונה
    2
    • A aaron

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

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

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

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

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

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

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

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

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

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

      מייל: nigun@duck.com

      dovidD תגובה 1 תגובה אחרונה
      0
      • nigunN nigun

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

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

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

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

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

        dovidD מחובר
        dovidD מחובר
        dovid
        ניהול
        כתב ב נערך לאחרונה על ידי
        #4

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

        • מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
        • בכל נושא אפשר ליצור קשר dovid@tchumim.com
        nigunN תגובה 1 תגובה אחרונה
        0
        • dovidD dovid

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

          nigunN מנותק
          nigunN מנותק
          nigun
          כתב ב נערך לאחרונה על ידי nigun
          #5

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

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

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

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

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

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

          מייל: nigun@duck.com

          dovidD תגובה 1 תגובה אחרונה
          0
          • nigunN מנותק
            nigunN מנותק
            nigun
            כתב ב נערך לאחרונה על ידי nigun
            #6

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

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

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

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

            מייל: nigun@duck.com

            תגובה 1 תגובה אחרונה
            0
            • nigunN nigun

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

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

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

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

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

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

              dovidD מחובר
              dovidD מחובר
              dovid
              ניהול
              כתב ב נערך לאחרונה על ידי
              #7

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

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

              למה זה קשור?

              • מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
              • בכל נושא אפשר ליצור קשר dovid@tchumim.com
              nigunN תגובה 1 תגובה אחרונה
              0
              • dovidD dovid

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

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

                למה זה קשור?

                nigunN מנותק
                nigunN מנותק
                nigun
                כתב ב נערך לאחרונה על ידי
                #8

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

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

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

                למה זה קשור?

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

                מייל: nigun@duck.com

                dovidD תגובה 1 תגובה אחרונה
                0
                • nigunN nigun

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

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

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

                  למה זה קשור?

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

                  dovidD מחובר
                  dovidD מחובר
                  dovid
                  ניהול
                  כתב ב נערך לאחרונה על ידי
                  #9

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

                  • מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
                  • בכל נושא אפשר ליצור קשר dovid@tchumim.com
                  nigunN תגובה 1 תגובה אחרונה
                  0
                  • dovidD dovid

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

                    nigunN מנותק
                    nigunN מנותק
                    nigun
                    כתב ב נערך לאחרונה על ידי nigun
                    #10

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

                    מייל: nigun@duck.com

                    dovidD תגובה 1 תגובה אחרונה
                    0
                    • nigunN nigun

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

                      dovidD מחובר
                      dovidD מחובר
                      dovid
                      ניהול
                      כתב ב נערך לאחרונה על ידי dovid
                      #11

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

                      • מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
                      • בכל נושא אפשר ליצור קשר dovid@tchumim.com
                      תגובה 1 תגובה אחרונה
                      2
                      • nigunN nigun

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

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

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

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

                        clickoneC מנותק
                        clickoneC מנותק
                        clickone
                        כתב ב נערך לאחרונה על ידי
                        #12

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

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

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

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

                        אין טסט כמו פרודקשן.

                        המייל שלי urivpn@gmail.com

                        nigunN תגובה 1 תגובה אחרונה
                        1
                        • clickoneC clickone

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

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

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

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

                          nigunN מנותק
                          nigunN מנותק
                          nigun
                          כתב ב נערך לאחרונה על ידי
                          #13

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

                          מייל: nigun@duck.com

                          תגובה 1 תגובה אחרונה
                          0
                          • nigunN מנותק
                            nigunN מנותק
                            nigun
                            כתב ב נערך לאחרונה על ידי nigun
                            #14

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

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

                            מייל: nigun@duck.com

                            ח תגובה 1 תגובה אחרונה
                            0
                            • nigunN nigun

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

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

                              ח מנותק
                              ח מנותק
                              חוקר
                              כתב ב נערך לאחרונה על ידי חוקר
                              #15

                              @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);
                                              });
                              

                              בהצלחה

                              nigunN תגובה 1 תגובה אחרונה
                              5
                              • ח חוקר

                                @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);
                                                });
                                

                                בהצלחה

                                nigunN מנותק
                                nigunN מנותק
                                nigun
                                כתב ב נערך לאחרונה על ידי
                                #16

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

                                מייל: nigun@duck.com

                                dovidD תגובה 1 תגובה אחרונה
                                0
                                • nigunN nigun

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

                                  dovidD מחובר
                                  dovidD מחובר
                                  dovid
                                  ניהול
                                  כתב ב נערך לאחרונה על ידי dovid
                                  #17

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

                                  • מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
                                  • בכל נושא אפשר ליצור קשר dovid@tchumim.com
                                  nigunN תגובה 1 תגובה אחרונה
                                  5
                                  • dovidD dovid

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

                                    nigunN מנותק
                                    nigunN מנותק
                                    nigun
                                    כתב ב נערך לאחרונה על ידי
                                    #18

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

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

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

                                    מייל: nigun@duck.com

                                    תגובה 1 תגובה אחרונה
                                    0
                                    • nigunN מנותק
                                      nigunN מנותק
                                      nigun
                                      כתב ב נערך לאחרונה על ידי nigun
                                      #19

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

                                      אבל בכל אופן אלו התוצאות
                                      אני משתמש בכלי הזה
                                      עם הפקודה:
                                      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@duck.com

                                      ח תגובה 1 תגובה אחרונה
                                      2
                                      • nigunN 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
                                        
                                        ח מנותק
                                        ח מנותק
                                        חוקר
                                        כתב ב נערך לאחרונה על ידי
                                        #20

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

                                        [200] 19968 responses

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

                                        nigunN תגובה 1 תגובה אחרונה
                                        1
                                        • ח חוקר

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

                                          [200] 19968 responses

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

                                          nigunN מנותק
                                          nigunN מנותק
                                          nigun
                                          כתב ב נערך לאחרונה על ידי
                                          #21

                                          @חוקר
                                          נראה לי שLatency של מעל 7.5 שניות ב25% מהבקשות זה יותר מטריד.
                                          בכל אופן באתי להראות בהבעיה היא בעיבוד ולא כל כך ברוחב פס.

                                          מייל: nigun@duck.com

                                          תגובה 1 תגובה אחרונה
                                          1
                                          תגובה
                                          • תגובה כנושא
                                          התחברו כדי לפרסם תגובה
                                          • מהישן לחדש
                                          • מהחדש לישן
                                          • הכי הרבה הצבעות


                                          • 1
                                          • 2
                                          בא תתחבר לדף היומי!
                                          • התחברות

                                          • אין לך חשבון עדיין? הרשמה

                                          • התחברו או הירשמו כדי לחפש.
                                          • פוסט ראשון
                                            פוסט אחרון
                                          0
                                          • דף הבית
                                          • קטגוריות
                                          • פוסטים אחרונים
                                          • משתמשים
                                          • חיפוש
                                          • חוקי הפורום