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

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

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

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

]]>https://tchumim.com/topic/10278/ניהול-קאש-למאות-קריאות-במקבילRSS for NodeSat, 18 Jul 2026 18:37:26 GMTWed, 02 Dec 2020 17:01:22 GMT60<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Tue, 08 Dec 2020 12:22:28 GMT]]>@אבי
תלוי לפי טבע המוצר
לפעמים אתה תתחיל מSQLite, ולפעמים תשמור בקובץ CSV, העיקר שהגירסה הראשונית תעבוד.
וכמובן יש את הנקודה המסוכנת שעושים טלאי על טלאי, ואם זה לא קורס? אל תשאל שאלות.

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

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

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

]]>https://tchumim.com/post/115132https://tchumim.com/post/115132Tue, 08 Dec 2020 12:22:28 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Tue, 08 Dec 2020 10:17:33 GMT]]>@nigun אמר בניהול קאש למאות קריאות במקביל:

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

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

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

מסקנה: רצתי לעשות אזרחות אמריקאית... 😊

]]>https://tchumim.com/post/115130https://tchumim.com/post/115130Tue, 08 Dec 2020 10:17:33 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Tue, 08 Dec 2020 09:12:45 GMT]]>@dovid
כשיש לי דרישה לפיצ'ר חדש
אני יכול להשקיע וליישם טכנולוגיה שאני עדיין לא מכיר (וובסוקט)
או להשתמש בטכנולוגיה לא יעילה, אבל מוכרת ופותרת את הבעיה באופן ראשוני.
(וכמובן צריך לתכנן את הקוד בצורה שיהיה ניתן לשנות חלקים בקלות בלי לכתוב הכל מהתחלה)

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

]]>https://tchumim.com/post/115128https://tchumim.com/post/115128Tue, 08 Dec 2020 09:12:45 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Tue, 08 Dec 2020 09:03:28 GMT]]>@nigun אני ממש מסכים עם מה שציטטת,
אבל זה שהבאת את זה פה, זה ממש להוציא דברים מהקשרם.
מי ביקש ממך להשקיע? אדרבא, אתה זה שמשקיע.

]]>https://tchumim.com/post/115127https://tchumim.com/post/115127Tue, 08 Dec 2020 09:03:28 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Tue, 08 Dec 2020 08:34:18 GMT]]>@אבי
עוד נקודה ששמעתי השבוע בchangelog

So before Uber I thought you need to have a perfect system of friends, or something. At Uber, I realized when you’re growing it’s a great problem, and you can solve things by throwing money at it in terms of hiring people, who are coming in to fix certain things… Or just buying more infrastructure. At some point we were bleeding, we were using so much infra… But it didn’t matter, because we were already growing.

And on the other side, it doesn’t matter if you build the perfect system if your business model doesn’t work. You’re gonna have to shut down later. And I also saw that at Uber. There were some parts of the business which weren’t running that great, and they got shut down. A case study which is publicly-known - Jump. They were a great team, going really fast, and then I guess the business for this or that didn’t work out, so they were shut down.

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

]]>https://tchumim.com/post/115124https://tchumim.com/post/115124Tue, 08 Dec 2020 08:34:18 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Tue, 08 Dec 2020 07:17:24 GMT]]>@clickone
זה יותר גרוע.

]]>https://tchumim.com/post/115121https://tchumim.com/post/115121Tue, 08 Dec 2020 07:17:24 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Tue, 08 Dec 2020 00:01:54 GMT]]>@nigun אמר בניהול קאש למאות קריאות במקביל:

אגב למה נראה לך שרק בציבור שלנו משתמשים בשיטת ה"סמוך"?

@אבי ע"ע שירביט. (לא שאני מאשים אותם בשלב הזה...)

]]>https://tchumim.com/post/115118https://tchumim.com/post/115118Tue, 08 Dec 2020 00:01:54 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Mon, 07 Dec 2020 22:37:29 GMT]]>@אבי
זה לא בדיוק שאין לו כח לעבוד כמו בן אדם
אלא גדילה לא מתוכננת, כשבנינו את החלק הזה לא חשבנו על שימוש רחב כזה.

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

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

]]>https://tchumim.com/post/115117https://tchumim.com/post/115117Mon, 07 Dec 2020 22:37:29 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Mon, 07 Dec 2020 21:01:30 GMT]]>@nigun
סליחה על ההקפצה
עברתי על האשכול ואני קולט שאתה עובד קשה וממציא גלגלים בגלל שלמתכנת צד לקוח לא היה נוח לעבוד כמו בן אדם.
נראה לי שאני יודע באיזה פרוייקט מדובר ושהסיפור קצת מורכב.. אבל עדיין נשמע לי מוזר.
משום מה הציבור שלנו לוקח את שיטת ה'סמוך' לעולם התיכנות, אבל הקומבינות מהסוג הזה עולות ביוקר!
ראה הוזהרת! 😲

]]>https://tchumim.com/post/115116https://tchumim.com/post/115116Mon, 07 Dec 2020 21:01:30 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sun, 06 Dec 2020 00:27:17 GMT]]>כאן הורדתי את הקובץ הסטטי עם 9 שרתים של 8 ליבות
(הפקודה נשלחה אחד אחרי השני אז הביצועים קצת יותר טובים בשרת הראשון מאשר באחרון)
מה שיצא לי זה שכמות הבקשות במקביל נשארת בערך אותו דבר
אבל הרבה יותר בקשות נופלות (בערך 100 מתוך 180,000)
והממוצע של הLatency מגיע ל5-6 שניות😰
בהמשך אני ינסה לעשות טסטים על JSON ששמור בזיכרון ולא בקובץ בדיסק, ונראה האם יש הבדל?
אבל נראה לי שהתשובה היא שאין טסט כמו פרודקשן.
עריכה: הוספתי את המודול של קאש שמובנה בשרת
ולא עזר כל כך, בקיצור נשאר לי לעשות עוד בדיקות.

45.79.251.87: 
45.79.251.87: Summary:
45.79.251.87:   Total:  138.9316 secs
45.79.251.87:   Slowest:        20.0004 secs
45.79.251.87:   Fastest:        0.1367 secs
45.79.251.87:   Average:        4.8698 secs
45.79.251.87:   Requests/sec:   143.9558
45.79.251.87:   
45.79.251.87:   Total data:     3021455588 bytes
45.79.251.87:   Size/request:   151103 bytes
45.79.251.87: 
45.79.251.87: Response time histogram:
45.79.251.87:   0.137 [1]       |
45.79.251.87:   2.123 [6431]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
45.79.251.87:   4.109 [3753]    |■■■■■■■■■■■■■■■■■■■■■■■
45.79.251.87:   6.096 [3100]    |■■■■■■■■■■■■■■■■■■■
45.79.251.87:   8.082 [2694]    |■■■■■■■■■■■■■■■■■
45.79.251.87:   10.069 [1975]   |■■■■■■■■■■■■
45.79.251.87:   12.055 [1089]   |■■■■■■■
45.79.251.87:   14.041 [439]    |■■■
45.79.251.87:   16.028 [207]    |■
45.79.251.87:   18.014 [98]     |■
45.79.251.87:   20.000 [209]    |■
45.79.251.87: 
45.79.251.87: 
45.79.251.87: Latency distribution:
45.79.251.87:   10% in 0.7511 secs
45.79.251.87:   25% in 1.5106 secs
45.79.251.87:   50% in 3.9800 secs
45.79.251.87:   75% in 7.3072 secs
45.79.251.87:   90% in 10.1158 secs
45.79.251.87:   95% in 11.9238 secs
45.79.251.87:   99% in 18.3157 secs
45.79.251.87: 
45.79.251.87: Details (average, fastest, slowest):
45.79.251.87:   DNS+dialup:     0.0133 secs, 0.1367 secs, 20.0004 secs
45.79.251.87:   DNS-lookup:     0.0024 secs, 0.0000 secs, 0.0863 secs
45.79.251.87:   req write:      0.0000 secs, 0.0000 secs, 0.0281 secs
45.79.251.87:   resp wait:      0.3169 secs, 0.0012 secs, 13.3027 secs
45.79.251.87:   resp read:      4.4962 secs, 0.0007 secs, 19.9857 secs
45.79.251.87: 
45.79.251.87: Status code distribution:
45.79.251.87:   [200]   19996 responses
45.79.251.87: 

139.162.173.138: 
139.162.173.138: Summary:
139.162.173.138:   Total:       139.1591 secs
139.162.173.138:   Slowest:     20.0044 secs
139.162.173.138:   Fastest:     0.1255 secs
139.162.173.138:   Average:     6.0115 secs
139.162.173.138:   Requests/sec:        143.7204
139.162.173.138:   
139.162.173.138:   Total data:  3019189043 bytes
139.162.173.138:   Size/request:        151103 bytes
139.162.173.138: 
139.162.173.138: Response time histogram:
139.162.173.138:   0.126 [1]    |
139.162.173.138:   2.113 [2268] |■■■■■■■■■■■■■■■■■■■
139.162.173.138:   4.101 [4711] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
139.162.173.138:   6.089 [4315] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
139.162.173.138:   8.077 [3650] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
139.162.173.138:   10.065 [2590]        |■■■■■■■■■■■■■■■■■■■■■■
139.162.173.138:   12.053 [1316]        |■■■■■■■■■■■
139.162.173.138:   14.041 [557] |■■■■■
139.162.173.138:   16.029 [216] |■■
139.162.173.138:   18.016 [100] |■
139.162.173.138:   20.004 [257] |■■
139.162.173.138: 
139.162.173.138: 
139.162.173.138: Latency distribution:
139.162.173.138:   10% in 1.9748 secs
139.162.173.138:   25% in 3.2285 secs
139.162.173.138:   50% in 5.4599 secs
139.162.173.138:   75% in 8.0990 secs
139.162.173.138:   90% in 10.6191 secs
139.162.173.138:   95% in 12.3935 secs
139.162.173.138:   99% in 20.0001 secs
139.162.173.138: 
139.162.173.138: Details (average, fastest, slowest):
139.162.173.138:   DNS+dialup:  0.0222 secs, 0.1255 secs, 20.0044 secs
139.162.173.138:   DNS-lookup:  0.0025 secs, 0.0000 secs, 0.0786 secs
139.162.173.138:   req write:   0.0000 secs, 0.0000 secs, 0.0010 secs
139.162.173.138:   resp wait:   0.2815 secs, 0.0103 secs, 17.3270 secs
139.162.173.138:   resp read:   5.4470 secs, 0.0009 secs, 19.9804 secs
139.162.173.138: 
139.162.173.138: Status code distribution:
139.162.173.138:   [200]        19981 responses
139.162.173.138: 

45.79.251.152: 
45.79.251.152: Summary:
45.79.251.152:   Total: 139.2413 secs
45.79.251.152:   Slowest:       20.0220 secs
45.79.251.152:   Fastest:       0.0452 secs
45.79.251.152:   Average:       5.9826 secs
45.79.251.152:   Requests/sec:  143.6355
45.79.251.152:   
45.79.251.152:   Total data:    2894529068 bytes
45.79.251.152:   Size/request:  151103 bytes
45.79.251.152: 
45.79.251.152: Response time histogram:
45.79.251.152:   0.045 [1]      |
45.79.251.152:   2.043 [2674]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■
45.79.251.152:   4.041 [3894]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
45.79.251.152:   6.038 [4019]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
45.79.251.152:   8.036 [3738]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
45.79.251.152:   10.034 [2521]  |■■■■■■■■■■■■■■■■■■■■■■■■■
45.79.251.152:   12.031 [1152]  |■■■■■■■■■■■
45.79.251.152:   14.029 [456]   |■■■■■
45.79.251.152:   16.027 [239]   |■■
45.79.251.152:   18.024 [135]   |■
45.79.251.152:   20.022 [327]   |■■■
45.79.251.152: 
45.79.251.152: 
45.79.251.152: Latency distribution:
45.79.251.152:   10% in 1.6045 secs
45.79.251.152:   25% in 3.1226 secs
45.79.251.152:   50% in 5.5370 secs
45.79.251.152:   75% in 8.0623 secs
45.79.251.152:   90% in 10.5575 secs
45.79.251.152:   95% in 12.6362 secs
45.79.251.152:   99% in 20.0001 secs
45.79.251.152: 
45.79.251.152: Details (average, fastest, slowest):
45.79.251.152:   DNS+dialup:    0.1141 secs, 0.0452 secs, 20.0220 secs
45.79.251.152:   DNS-lookup:    0.0004 secs, 0.0000 secs, 0.0556 secs
45.79.251.152:   req write:     0.0000 secs, 0.0000 secs, 0.0350 secs
45.79.251.152:   resp wait:     0.2133 secs, 0.0056 secs, 14.0410 secs
45.79.251.152:   resp read:     5.3768 secs, 0.0114 secs, 19.9866 secs
45.79.251.152: 
45.79.251.152: Status code distribution:
45.79.251.152:   [200]  19156 responses
45.79.251.152: 

172.104.253.220: 
172.104.253.220: Summary:
172.104.253.220:   Total:       139.2822 secs
172.104.253.220:   Slowest:     20.0003 secs
172.104.253.220:   Fastest:     0.0099 secs
172.104.253.220:   Average:     6.1217 secs
172.104.253.220:   Requests/sec:        143.5934
172.104.253.220:   
172.104.253.220:   Total data:  3021304485 bytes
172.104.253.220:   Size/request:        151103 bytes
172.104.253.220: 
172.104.253.220: Response time histogram:
172.104.253.220:   0.010 [1]    |
172.104.253.220:   2.009 [2125] |■■■■■■■■■■■■■■■■■■■■
172.104.253.220:   4.008 [4271] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.253.220:   6.007 [4244] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.253.220:   8.006 [4062] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.253.220:   10.005 [2808]        |■■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.253.220:   12.004 [1312]        |■■■■■■■■■■■■
172.104.253.220:   14.003 [550] |■■■■■
172.104.253.220:   16.002 [247] |■■
172.104.253.220:   18.001 [89]  |■
172.104.253.220:   20.000 [286] |■■■
172.104.253.220: 
172.104.253.220: 
172.104.253.220: Latency distribution:
172.104.253.220:   10% in 1.9524 secs
172.104.253.220:   25% in 3.3358 secs
172.104.253.220:   50% in 5.7098 secs
172.104.253.220:   75% in 8.1748 secs
172.104.253.220:   90% in 10.5963 secs
172.104.253.220:   95% in 12.4480 secs
172.104.253.220:   99% in 20.0001 secs
172.104.253.220: 
172.104.253.220: Details (average, fastest, slowest):
172.104.253.220:   DNS+dialup:  0.0500 secs, 0.0099 secs, 20.0003 secs
172.104.253.220:   DNS-lookup:  0.0027 secs, 0.0000 secs, 0.0678 secs
172.104.253.220:   req write:   0.0000 secs, 0.0000 secs, 0.0042 secs
172.104.253.220:   resp wait:   0.2811 secs, 0.0018 secs, 13.6498 secs
172.104.253.220:   resp read:   5.4899 secs, 0.0080 secs, 19.9840 secs
172.104.253.220: 
172.104.253.220: Status code distribution:
172.104.253.220:   [200]        19995 responses
172.104.253.220: 

172.105.248.5: 
172.105.248.5: Summary:
172.105.248.5:   Total: 139.3178 secs
172.105.248.5:   Slowest:       20.0263 secs
172.105.248.5:   Fastest:       0.0171 secs
172.105.248.5:   Average:       6.4666 secs
172.105.248.5:   Requests/sec:  143.5567
172.105.248.5:   
172.105.248.5:   Total data:    3019340146 bytes
172.105.248.5:   Size/request:  151103 bytes
172.105.248.5: 
172.105.248.5: Response time histogram:
172.105.248.5:   0.017 [1]      |
172.105.248.5:   2.018 [2181]   |■■■■■■■■■■■■■■■■■■■■■■
172.105.248.5:   4.019 [3944]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.248.5:   6.020 [3996]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.248.5:   8.021 [3838]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.248.5:   10.022 [2748]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.248.5:   12.023 [1527]  |■■■■■■■■■■■■■■■
172.105.248.5:   14.024 [788]   |■■■■■■■■
172.105.248.5:   16.024 [425]   |■■■■
172.105.248.5:   18.025 [173]   |■■
172.105.248.5:   20.026 [361]   |■■■■
172.105.248.5: 
172.105.248.5: 
172.105.248.5: Latency distribution:
172.105.248.5:   10% in 1.9207 secs
172.105.248.5:   25% in 3.4414 secs
172.105.248.5:   50% in 5.9593 secs
172.105.248.5:   75% in 8.6282 secs
172.105.248.5:   90% in 11.5480 secs
172.105.248.5:   95% in 13.8490 secs
172.105.248.5:   99% in 20.0002 secs
172.105.248.5: 
172.105.248.5: Details (average, fastest, slowest):
172.105.248.5:   DNS+dialup:    0.0721 secs, 0.0171 secs, 20.0263 secs
172.105.248.5:   DNS-lookup:    0.0034 secs, 0.0000 secs, 0.1369 secs
172.105.248.5:   req write:     0.0001 secs, 0.0000 secs, 0.0624 secs
172.105.248.5:   resp wait:     0.2481 secs, 0.0026 secs, 12.9038 secs
172.105.248.5:   resp read:     5.5493 secs, 0.0145 secs, 19.9869 secs
172.105.248.5: 
172.105.248.5: Status code distribution:
172.105.248.5:   [200]  19982 responses
172.105.248.5: 

45.83.42.165: 
45.83.42.165: Summary:
45.83.42.165:   Total:  141.6212 secs
45.83.42.165:   Slowest:        20.0007 secs
45.83.42.165:   Fastest:        0.1838 secs
45.83.42.165:   Average:        6.7893 secs
45.83.42.165:   Requests/sec:   141.2218
45.83.42.165:   
45.83.42.165:   Total data:     3021153382 bytes
45.83.42.165:   Size/request:   151103 bytes
45.83.42.165: 
45.83.42.165: Response time histogram:
45.83.42.165:   0.184 [1]       |
45.83.42.165:   2.165 [4096]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
45.83.42.165:   4.147 [3173]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
45.83.42.165:   6.129 [2664]    |■■■■■■■■■■■■■■■■■■■■■■■■■■
45.83.42.165:   8.111 [2530]    |■■■■■■■■■■■■■■■■■■■■■■■■■
45.83.42.165:   10.092 [2348]   |■■■■■■■■■■■■■■■■■■■■■■■
45.83.42.165:   12.074 [2119]   |■■■■■■■■■■■■■■■■■■■■■
45.83.42.165:   14.056 [1523]   |■■■■■■■■■■■■■■■
45.83.42.165:   16.037 [779]    |■■■■■■■■
45.83.42.165:   18.019 [354]    |■■■
45.83.42.165:   20.001 [407]    |■■■■
45.83.42.165: 
45.83.42.165: 
45.83.42.165: Latency distribution:
45.83.42.165:   10% in 0.8031 secs
45.83.42.165:   25% in 2.7718 secs
45.83.42.165:   50% in 6.1787 secs
45.83.42.165:   75% in 10.2434 secs
45.83.42.165:   90% in 13.3162 secs
45.83.42.165:   95% in 15.2976 secs
45.83.42.165:   99% in 20.0002 secs
45.83.42.165: 
45.83.42.165: Details (average, fastest, slowest):
45.83.42.165:   DNS+dialup:     0.1249 secs, 0.1838 secs, 20.0007 secs
45.83.42.165:   DNS-lookup:     0.0078 secs, 0.0000 secs, 0.1237 secs
45.83.42.165:   req write:      0.0000 secs, 0.0000 secs, 0.0059 secs
45.83.42.165:   resp wait:      0.2989 secs, 0.0437 secs, 16.1208 secs
45.83.42.165:   resp read:      5.8916 secs, 0.0008 secs, 19.9380 secs
45.83.42.165: 
45.83.42.165: Status code distribution:
45.83.42.165:   [200]   19994 responses
45.83.42.165: 

172.104.202.190: 
172.104.202.190: Summary:
172.104.202.190:   Total:       148.0799 secs
172.104.202.190:   Slowest:     20.0623 secs
172.104.202.190:   Fastest:     0.0015 secs
172.104.202.190:   Average:     6.0749 secs
172.104.202.190:   Requests/sec:        135.0622
172.104.202.190:   
172.104.202.190:   Total data:  2924447462 bytes
172.104.202.190:   Size/request:        151103 bytes
172.104.202.190: 
172.104.202.190: Response time histogram:
172.104.202.190:   0.001 [1]    |
172.104.202.190:   2.008 [2585] |■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.202.190:   4.014 [3953] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.202.190:   6.020 [4102] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.202.190:   8.026 [3732] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.104.202.190:   10.032 [2450]        |■■■■■■■■■■■■■■■■■■■■■■■■
172.104.202.190:   12.038 [1230]        |■■■■■■■■■■■■
172.104.202.190:   14.044 [489] |■■■■■
172.104.202.190:   16.050 [249] |■■
172.104.202.190:   18.056 [159] |■■
172.104.202.190:   20.062 [404] |■■■■
172.104.202.190: 
172.104.202.190: 
172.104.202.190: Latency distribution:
172.104.202.190:   10% in 1.6407 secs
172.104.202.190:   25% in 3.1305 secs
172.104.202.190:   50% in 5.5645 secs
172.104.202.190:   75% in 8.1119 secs
172.104.202.190:   90% in 10.8448 secs
172.104.202.190:   95% in 13.1672 secs
172.104.202.190:   99% in 20.0002 secs
172.104.202.190: 
172.104.202.190: Details (average, fastest, slowest):
172.104.202.190:   DNS+dialup:  0.1039 secs, 0.0015 secs, 20.0623 secs
172.104.202.190:   DNS-lookup:  0.0028 secs, 0.0000 secs, 0.1537 secs
172.104.202.190:   req write:   0.0001 secs, 0.0000 secs, 0.0757 secs
172.104.202.190:   resp wait:   0.2265 secs, 0.0003 secs, 14.0700 secs
172.104.202.190:   resp read:   5.3429 secs, 0.0011 secs, 19.9867 secs
172.104.202.190: 
172.104.202.190: Status code distribution:
172.104.202.190:   [200]        19354 responses
172.104.202.190: 

172.105.250.39: 
172.105.250.39: Summary:
172.105.250.39:   Total:        152.9620 secs
172.105.250.39:   Slowest:      20.1078 secs
172.105.250.39:   Fastest:      0.0024 secs
172.105.250.39:   Average:      6.5224 secs
172.105.250.39:   Requests/sec: 130.7514
172.105.250.39:   
172.105.250.39:   Total data:   3018584631 bytes
172.105.250.39:   Size/request: 151103 bytes
172.105.250.39: 
172.105.250.39: Response time histogram:
172.105.250.39:   0.002 [1]     |
172.105.250.39:   2.013 [2418]  |■■■■■■■■■■■■■■■■■■■■■■■■
172.105.250.39:   4.023 [3981]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.250.39:   6.034 [3882]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.250.39:   8.045 [3576]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.250.39:   10.055 [2670] |■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.250.39:   12.066 [1453] |■■■■■■■■■■■■■■■
172.105.250.39:   14.076 [820]  |■■■■■■■■
172.105.250.39:   16.087 [437]  |■■■■
172.105.250.39:   18.097 [270]  |■■■
172.105.250.39:   20.108 [469]  |■■■■■
172.105.250.39: 
172.105.250.39: 
172.105.250.39: Latency distribution:
172.105.250.39:   10% in 1.7630 secs
172.105.250.39:   25% in 3.2887 secs
172.105.250.39:   50% in 5.8703 secs
172.105.250.39:   75% in 8.8007 secs
172.105.250.39:   90% in 12.0638 secs
172.105.250.39:   95% in 14.8308 secs
172.105.250.39:   99% in 20.0002 secs
172.105.250.39: 
172.105.250.39: Details (average, fastest, slowest):
172.105.250.39:   DNS+dialup:   0.1170 secs, 0.0024 secs, 20.1078 secs
172.105.250.39:   DNS-lookup:   0.0047 secs, 0.0000 secs, 0.3834 secs
172.105.250.39:   req write:    0.0003 secs, 0.0000 secs, 0.1147 secs
172.105.250.39:   resp wait:    0.2484 secs, 0.0005 secs, 17.7064 secs
172.105.250.39:   resp read:    5.4540 secs, 0.0018 secs, 19.9841 secs
172.105.250.39: 
172.105.250.39: Status code distribution:
172.105.250.39:   [200] 19977 responses
172.105.250.39: 

172.105.247.100: 
172.105.247.100: Summary:
172.105.247.100:   Total:       152.9953 secs
172.105.247.100:   Slowest:     20.0809 secs
172.105.247.100:   Fastest:     0.0024 secs
172.105.247.100:   Average:     6.2010 secs
172.105.247.100:   Requests/sec:        130.7230
172.105.247.100:   
172.105.247.100:   Total data:  3021002279 bytes
172.105.247.100:   Size/request:        151103 bytes
172.105.247.100: 
172.105.247.100: Response time histogram:
172.105.247.100:   0.002 [1]    |
172.105.247.100:   2.010 [1929] |■■■■■■■■■■■■■■■■■
172.105.247.100:   4.018 [4376] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.247.100:   6.026 [4478] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.247.100:   8.034 [3727] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
172.105.247.100:   10.042 [2707]        |■■■■■■■■■■■■■■■■■■■■■■■■
172.105.247.100:   12.049 [1482]        |■■■■■■■■■■■■■
172.105.247.100:   14.057 [685] |■■■■■■
172.105.247.100:   16.065 [277] |■■
172.105.247.100:   18.073 [122] |■
172.105.247.100:   20.081 [209] |■■
172.105.247.100: 
172.105.247.100: 
172.105.247.100: Latency distribution:
172.105.247.100:   10% in 2.0431 secs
172.105.247.100:   25% in 3.4775 secs
172.105.247.100:   50% in 5.6590 secs
172.105.247.100:   75% in 8.3569 secs
172.105.247.100:   90% in 10.9436 secs
172.105.247.100:   95% in 12.7125 secs
172.105.247.100:   99% in 18.3445 secs
172.105.247.100: 
172.105.247.100: Details (average, fastest, slowest):
172.105.247.100:   DNS+dialup:  0.0302 secs, 0.0024 secs, 20.0809 secs
172.105.247.100:   DNS-lookup:  0.0033 secs, 0.0000 secs, 0.1149 secs
172.105.247.100:   req write:   0.0001 secs, 0.0000 secs, 0.0459 secs
172.105.247.100:   resp wait:   0.2708 secs, 0.0004 secs, 13.1431 secs
172.105.247.100:   resp read:   5.6111 secs, 0.0002 secs, 19.9857 secs
172.105.247.100: 
172.105.247.100: Status code distribution:
172.105.247.100:   [200]        19993 responses
172.105.247.100:
]]>https://tchumim.com/post/115025https://tchumim.com/post/115025Sun, 06 Dec 2020 00:27:17 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 23:35:50 GMT]]>@חוקר
נראה לי שLatency של מעל 7.5 שניות ב25% מהבקשות זה יותר מטריד.
בכל אופן באתי להראות בהבעיה היא בעיבוד ולא כל כך ברוחב פס.

]]>https://tchumim.com/post/115024https://tchumim.com/post/115024Sat, 05 Dec 2020 23:35:50 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 23:22:48 GMT]]>@nigun אמר בניהול קאש למאות קריאות במקביל:

[200] 19968 responses

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

]]>https://tchumim.com/post/115023https://tchumim.com/post/115023Sat, 05 Dec 2020 23:22:48 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 23:29:27 GMT]]>ניסיתי קצת לשחק עם כלים של בדיקות עומסים
כל כלי עובד קצת שונה, אז אני לא בטוח מה באמת מדמה נכון ומה לא.

אבל בכל אופן אלו התוצאות
אני משתמש בכלי הזה
עם הפקודה:
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
]]>https://tchumim.com/post/115022https://tchumim.com/post/115022Sat, 05 Dec 2020 23:29:27 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 20:44:04 GMT]]>@dovid אמר בניהול קאש למאות קריאות במקביל:

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

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

]]>https://tchumim.com/post/115019https://tchumim.com/post/115019Sat, 05 Dec 2020 20:44:04 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 19:37:42 GMT]]>@nigun בנוד מתבצע בכל רגע נתון רק פקודה אחת, כך שגם אם יש מיליון בקשות ביחד, הם עוברות את הקוד בזו אחר זו (סדרתי) ולא יחד (מקבילי - parallel). ברגע שהראשונה עברה את השורה שיוצרת את הפרומייס, כל המיליון שאחריה מחכים יחד לסיומו של הפרומייס.
כדי להגיע לתוצאה דומה בסביבות שמאפשרים ריצה מקבילה של קוד כמו go נדרשת פה נעילה: קטע קוד שרק תהליך אחד יכול להיכנס בזמן נתון. ניהול מלא ידני של כל הסיפור הזה הוא קצת בגדר המצאת הגלגל.
אבל שוב, 2000 קריאות בשניה זה עומס כבד עוד לפני שזה בכלל מגיע לטיפול ביישום גו/נוד. אם אפשר לחסוך בזה זה מבורך. שנית, המצב הזה של עדכון במערכת אחת וחיווי במערכת אחרת הוא בדיעבד. הכי טוב שהמערכת שמדווחת היא זו שגם מעודכנת ומעדכנת את נתוני האמת.

]]>https://tchumim.com/post/115015https://tchumim.com/post/115015Sat, 05 Dec 2020 19:37:42 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 19:29:40 GMT]]>@חוקר
מה אתה עושה אם עברה שניה, ועכשיו מגיעים 100 בקשות חדשות
ולוקח 200 מילי שניות לבצע את החישוב, איך אני יודע שהבקשה השניה והלאה אמורה להמתין בתור ולא להפעיל חישוב חדש?

]]>https://tchumim.com/post/115013https://tchumim.com/post/115013Sat, 05 Dec 2020 19:29:40 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 19:04:46 GMT]]>@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);
                });

בהצלחה

]]>https://tchumim.com/post/115012https://tchumim.com/post/115012Sat, 05 Dec 2020 19:04:46 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 18:17:57 GMT]]>אני יכול גם לבנות קאש לבד
שכל כמה שניות ימשוך את הנתונים מהשרת, ושמור בזיכרון
השאלה היא מה יהיה הטריגר?
אני יכול לבצע בדיקה בכל בקשה שנכנסת לשרת קאש
מתי היה העדכון האחרון?
ואם עבר כבר יותר משניה? לבצע עדכון חדש.
הבעיה בזה היא שיהיו לי כל פעם עשרות או מאות עדכונים
כי העדכון אורך לפחות 100 ms, ובזמן הזה יוצרו לי מאות טריגרים.

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

]]>https://tchumim.com/post/115011https://tchumim.com/post/115011Sat, 05 Dec 2020 18:17:57 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Sat, 05 Dec 2020 17:51:08 GMT]]>@clickone @dovid
עשיתי עכשיו הדמיה
וכל בקשה שוקלת 75 KB ואורכת 300- 450 ms (השרת בחו"ל)
אם אני עושה בדיקת עומסים (עם הכלים המיועדים לכך) משרת ישראלי (של 8 ליבות)
זה באמת יצליח לדמות את זה?

]]>https://tchumim.com/post/115010https://tchumim.com/post/115010Sat, 05 Dec 2020 17:51:08 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Fri, 04 Dec 2020 11:38:40 GMT]]>@nigun אמר בניהול קאש למאות קריאות במקביל:

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

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

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

]]>https://tchumim.com/post/115004https://tchumim.com/post/115004Fri, 04 Dec 2020 11:38:40 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Fri, 04 Dec 2020 11:29:40 GMT]]>@nigun
הבעיה שיש עומס הרבה הרבה יותר גדול.
כל שניה יש 2000 בקשות http חדשות לחלוטין,
הרבה לפני שאתה חושב על המערך שלך תחשוב על הרשת, על קצב העלאה הורדה, על יכולת שרת הhttp וכולי. המערך זה הכי הכי זניח פה. נראה לי שבשניה מחשב מסוגל להרבה הרבה מעבר לזה.

]]>https://tchumim.com/post/115002https://tchumim.com/post/115002Fri, 04 Dec 2020 11:29:40 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Fri, 04 Dec 2020 13:48:30 GMT]]>@dovid
ומה כל כך נורא בלמשוך כל שניה מחדש?
אולי לא הכי יעיל, אבל הכי נוח במקרה הזה
(המפתח צד לקוח אף פעם לא התעסק עם וובסוקט ולא רצה להתחיל עם זה עכשיו)(

]]>https://tchumim.com/post/114996https://tchumim.com/post/114996Fri, 04 Dec 2020 13:48:30 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Thu, 03 Dec 2020 23:55:54 GMT]]>@nigun אתה אמרת, וובסוקט...

]]>https://tchumim.com/post/114995https://tchumim.com/post/114995Thu, 03 Dec 2020 23:55:54 GMT<![CDATA[Reply to ניהול קאש למאות קריאות במקביל on Thu, 03 Dec 2020 23:53:53 GMT]]>@dovid אמר בניהול קאש למאות קריאות במקביל:

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

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

למה זה קשור?

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

]]>https://tchumim.com/post/114994https://tchumim.com/post/114994Thu, 03 Dec 2020 23:53:53 GMT