ניהול קאש למאות קריאות במקביל
-
אני יכול גם לבנות קאש לבד
שכל כמה שניות ימשוך את הנתונים מהשרת, ושמור בזיכרון
השאלה היא מה יהיה הטריגר?
אני יכול לבצע בדיקה בכל בקשה שנכנסת לשרת קאש
מתי היה העדכון האחרון?
ואם עבר כבר יותר משניה? לבצע עדכון חדש.
הבעיה בזה היא שיהיו לי כל פעם עשרות או מאות עדכונים
כי העדכון אורך לפחות 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
סליחה על ההקפצה
עברתי על האשכול ואני קולט שאתה עובד קשה וממציא גלגלים בגלל שלמתכנת צד לקוח לא היה נוח לעבוד כמו בן אדם.
נראה לי שאני יודע באיזה פרוייקט מדובר ושהסיפור קצת מורכב.. אבל עדיין נשמע לי מוזר.
משום מה הציבור שלנו לוקח את שיטת ה'סמוך' לעולם התיכנות, אבל הקומבינות מהסוג הזה עולות ביוקר!
ראה הוזהרת!
-
@אבי
זה לא בדיוק שאין לו כח לעבוד כמו בן אדם
אלא גדילה לא מתוכננת, כשבנינו את החלק הזה לא חשבנו על שימוש רחב כזה.אגב למה נראה לך שרק בציבור שלנו משתמשים בשיטת ה"סמוך"?
לכאורה כל ישראלי מצוי עובד כך, אא"כ הוא בחברה מסודרת שקובעת כללים ברורים (וגם אז לא בטוח).אגב בסוף יצא לנו
שבעצם הצד לקוח לא יכול להציג כל כך הרבה אנימציות בבת אחת
אז אין באמת צורך לטעון את כל המידע, אז חתכתי את הגודל ל2.2KB ובשילוב עם שמירה בקאש
לא נראה לי שאמור להיות בעיה רצינית. -
-
@אבי
עוד נקודה ששמעתי השבוע בchangelogSo 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.
ובעברית בתחילת הדרך של מוצר לא תמיד כדאי להשקיע את הזמן בבניית המוצר המושלם.
כי אם המוצר מצליח מקסימום תבזבז יותר כסף על חומרה או על שכתוב הקוד,
אבל אם המוצר לא מצליח בסוף אז סתם השקעת. -
-
@dovid
כשיש לי דרישה לפיצ'ר חדש
אני יכול להשקיע וליישם טכנולוגיה שאני עדיין לא מכיר (וובסוקט)
או להשתמש בטכנולוגיה לא יעילה, אבל מוכרת ופותרת את הבעיה באופן ראשוני.
(וכמובן צריך לתכנן את הקוד בצורה שיהיה ניתן לשנות חלקים בקלות בלי לכתוב הכל מהתחלה)ואם אחר כך המוצר מצליח
וכל הבעיה היא סקייליניג, אז שווה להשקיע את הזמן ליעל את המוצר. -
@nigun אמר בניהול קאש למאות קריאות במקביל:
כי אם המוצר מצליח מקסימום תבזבז יותר כסף על חומרה או על שכתוב הקוד,
אבל אם המוצר לא מצליח בסוף אז סתם השקעת.קודם כל, אם המוצר לא יהיה כתוב טוב הוא פשוט לא יצליח!
זה נכון לגבי ממשקים ויזואליים וכדו' ופיצ'רים פחות מהותיים שאיתם אפשר לחכות להמשך
אבל הארכיטקטורה של הדטהבייס ומבנה התקשורת הבסיסי חייב להיות מושלם כבר מהתחלה..
דברים כאלו אסור להגיד לישראלים...דבר שני, ה'גדילה' שעכשיו אתם מתמודדים איתה, היא היא ההצלחה האמורה, והיא אמורה לגרום לשכתוב הקוד בצורה מסודרת, ולא להוסיף קומבינות...
אלא מאי, זה ענין של גישה, מי שעובד בשיטת הסמוך (ואני מסכים שזה כל הישראלים.. אם כי זה נכנס לאט לאט.. והציבור שלנו מקבל את זה בסוף, כרגיל
) ימשיך תמיד בשיטה הזו, גם כשהמוצר יצליח..
אני גם הייתי שם, והגעתי לשלב של שכתוב מחדש, אבל כישראלי טוב, לא באמת פתחתי דף חדש, אלא ניסיתי להעתיק קטעים והתבסס על הקיים וכו'
התוצאה: באגים שלא שערום אבותינו... שעות עבודה... תלונות... וכו'מסקנה: רצתי לעשות אזרחות אמריקאית...
-
@אבי
תלוי לפי טבע המוצר
לפעמים אתה תתחיל מSQLite, ולפעמים תשמור בקובץ CSV, העיקר שהגירסה הראשונית תעבוד.
וכמובן יש את הנקודה המסוכנת שעושים טלאי על טלאי, ואם זה לא קורס? אל תשאל שאלות.הפתרון לכל זה (ועוד), הוא לכתוב את הקוד בצורה שתוכל להחליף את הגלגלים בקלות
בצירוף בדיקות יחידה לכל רכיב בקוד, כדי לוודאות ששכתוב של רכיב לא ישבור את הכל.אני כמובן לא מושלם בזה
אבל לאט לאט מתחיל לכתוב בדיקות יחידה על הפונקציות החדשות, להקפיד יותר שלכל פונקציה יהיה תפקיד ברור ופשוט, וכן הלאה.נ.ב. אזרחות אמריקאית לא עוזרת כל עוד לא ביטלת את הישראלית
