ניהול קאש למאות קריאות במקביל
-
-
@dovid
כל צופה מבצע קריאה כל שניה.
זה מסך תצוגה (לחדר ועידה עם סקר/חידון) שמציג בזמן אמת גרף כמה ענו נכון או לא נכון, וכן מציג אנימציה על כל הקשה חדשה.
אולי היה נכון לבנות את זה עם וובסוקט, אבל הדבר הכי נוח למתכנת של הצד לקוח היה ליצור מערך גדול של התשובות, ולתת לצד לקוח לנהל את כל הערכים החדשים במערך וליצור אנימציה מתאימה.כבר דיברנו בעבר של זה שלא חכם לשמור הכל במערכים, והמלצת לי על go-memdb
אבל למעשה הרבה מהמידע עדיין נשמר במערכים
ואני ממשיך לבצע נעילות.בהתחלה המסך היה מיועד לתצוגה אצל מספר קטן של צופים
אז ביצעתי נעילה כללית שנועלת את כל הכתיבות הרלוונטיות
ובאמת אין סיבה שיצור בעיה כל שהיא, כי מדובר במילישניות.אבל אם אני מבצע 2000 בקשות בשניה (== 2000 נעילות)
אז נוצר תור לכתיבה למערך, ובהנחה שיהיו כמה אלפי כתיבות בשניה
אז אולי יהיה כאן קצת בעיה.
בצד הטלפוני (הכותבים) אם יש 3 שניות של שקט של המתנה בתור זה נשמע יותר גרוע מאשר התמנה באתר.אמנם אני צריך לחשוש לזה גם אם יש לי 5000 כותבים (לא ניסיתי עדיין)
אבל נראה לי שהנעילות יותר קצרות אצל הכותבים
לעומת הקריאות ממירות כל פעם מספר מערכים לJSON (כל קריאה בהמרה נפרדת)נ.ב. לא יודע האם הייתי מספיק ברור
אם חסר פרטים, אני ינסה לפרט עוד. -
במחשבה שניה
לכאורה כלin-memory key/value storeמשתמש בנעילה כל שהיא
(אני שיש כאלו שכותבים במפורש שמשמשתים במערך)אז מעניין איך הם מתמודדים עם אפלי קריאות וכתיבות מקבילים?
האם יש דרך אחרת לאחסן בזכרון?עריכה: אני רואה שגם go-memdb מבצע נעילה בכתיבה
אבל משום מה הוא לא נועל בקריאה אפילו כשהוא קורא ממערך .עריכה2:
זה נראה שהוא יוצר משתנה חדש שמצביע למערך המקורי
וכך הוא קורא רק מהמשתנה החדש, ללא הגבלה. -
-
@dovid אמר בניהול קאש למאות קריאות במקביל:
@nigun אמר בניהול קאש למאות קריאות במקביל:
אולי היה נכון לבנות את זה עם וובסוקט, אבל הדבר הכי נוח למתכנת של הצד לקוח היה ליצור מערך גדול של התשובות, ולתת לצד לקוח לנהל את כל הערכים החדשים במערך וליצור אנימציה מתאימה.
למה זה קשור?
מה הדרכים לעדכן את הלקוח שיש שינוי?
-
-
@nigun
הבעיה שיש עומס הרבה הרבה יותר גדול.
כל שניה יש 2000 בקשות http חדשות לחלוטין,
הרבה לפני שאתה חושב על המערך שלך תחשוב על הרשת, על קצב העלאה הורדה, על יכולת שרת הhttp וכולי. המערך זה הכי הכי זניח פה. נראה לי שבשניה מחשב מסוגל להרבה הרבה מעבר לזה. -
@nigun אמר בניהול קאש למאות קריאות במקביל:
אז אני חושב לשמור את כל הJSON כל שניה בדף סטטי (כולם קוראים את אותם נתונים)
אני מתחבר לזה (במקרה שלך....)
עם קאש מנוהל -לדוגמא מאחורי קלאודפלרהדבר היחיד שמציק שם יהיה גודל הJSON
אם הוא קטן זה לא נורא,
אבל אם הוא עצמו יכול להכיל המון נתונים זה אכן מציק. -
אני יכול גם לבנות קאש לבד
שכל כמה שניות ימשוך את הנתונים מהשרת, ושמור בזיכרון
השאלה היא מה יהיה הטריגר?
אני יכול לבצע בדיקה בכל בקשה שנכנסת לשרת קאש
מתי היה העדכון האחרון?
ואם עבר כבר יותר משניה? לבצע עדכון חדש.
הבעיה בזה היא שיהיו לי כל פעם עשרות או מאות עדכונים
כי העדכון אורך לפחות 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 בנוד מתבצע בכל רגע נתון רק פקודה אחת, כך שגם אם יש מיליון בקשות ביחד, הם עוברות את הקוד בזו אחר זו (סדרתי) ולא יחד (מקבילי - parallel). ברגע שהראשונה עברה את השורה שיוצרת את הפרומייס, כל המיליון שאחריה מחכים יחד לסיומו של הפרומייס.
כדי להגיע לתוצאה דומה בסביבות שמאפשרים ריצה מקבילה של קוד כמו go נדרשת פה נעילה: קטע קוד שרק תהליך אחד יכול להיכנס בזמן נתון. ניהול מלא ידני של כל הסיפור הזה הוא קצת בגדר המצאת הגלגל.
אבל שוב, 2000 קריאות בשניה זה עומס כבד עוד לפני שזה בכלל מגיע לטיפול ביישום גו/נוד. אם אפשר לחסוך בזה זה מבורך. שנית, המצב הזה של עדכון במערכת אחת וחיווי במערכת אחרת הוא בדיעבד. הכי טוב שהמערכת שמדווחת היא זו שגם מעודכנת ומעדכנת את נתוני האמת. -
@dovid אמר בניהול קאש למאות קריאות במקביל:
המצב הזה של עדכון במערכת אחת וחיווי במערכת אחרת הוא בדיעבד. הכי טוב שהמערכת שמדווחת היא זו שגם מעודכנת ומעדכנת את נתוני האמת.
חשבתי שההפך
עדיף לפזר את העומסים כך שגם אם יש איטיות בשרת אחד לא נפגעים שאר השרתים. -
ניסיתי קצת לשחק עם כלים של בדיקות עומסים
כל כלי עובד קצת שונה, אז אני לא בטוח מה באמת מדמה נכון ומה לא.אבל בכל אופן אלו התוצאות
אני משתמש בכלי הזה
עם הפקודה:
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 -
-
כאן הורדתי את הקובץ הסטטי עם 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: -
@nigun
סליחה על ההקפצה
עברתי על האשכול ואני קולט שאתה עובד קשה וממציא גלגלים בגלל שלמתכנת צד לקוח לא היה נוח לעבוד כמו בן אדם.
נראה לי שאני יודע באיזה פרוייקט מדובר ושהסיפור קצת מורכב.. אבל עדיין נשמע לי מוזר.
משום מה הציבור שלנו לוקח את שיטת ה'סמוך' לעולם התיכנות, אבל הקומבינות מהסוג הזה עולות ביוקר!
ראה הוזהרת!
