פיצ'ר | ממשק ניטור מערכות נטפרי

[chv]

@magicode אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

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

אני לא יודע על איזה חיבור אתה גולש ואיזה חיפושים אתה עושה.
אני גולש על חיבור קווי 019, 100 מגה. מהירות הגלישה מעולה. אין לי תלונות על זה.
מהירות חיפוש גוגל מוציאה מהדעת, ובעיקר לעומת החוויה המהירה באינטרנט רגיל (גם בחיבורים איטיים מאוד, סלולרי על 3G בקרית ספר, חיפוש גוגל זה דבר שלוקח פחות משניה)

החיפושים שלי דיי קלאסיים.. אני מניח שברוב החיפושים שלי, רוב ה-10 תוצאות הראשונות יהיו פתוחות.

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

[chv]

@ברצינות אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

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

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

אבל אני לא מבין ככ על מה אתם מתווכחים כאן.
לא ברור לי מה המטרה של הפיצ'ר הזה, של בדיקת התוצאות והסתרה של תוצאה ב-x-x-x-x (הרי אפילו לא משנים את ה-URL שלה) אם זה בעייתי - כלומר טקסט בעייתי - זה אכן אמור להיות מסונן מלכתחילה על ידי הרובוט, ואם זה לא בעייתי - אז מה הבעיה פשוט לשים את זה?
ומקסימום - אפשר לממש את הפיצ'ר בצורה כזו, שהתוצאות המקוריות כן ייטענו לדף בצורה מיידית, ורק בתור אינדיקציה נוחה למשתמש אם התוצאה הזו פתוחה או לא, יהיה אחר כך סימן לצד התוצאה. שהיא חסומה/פתוחה/לא נבדקה וכו'

למה לתקוע את התוצאות?

[magicode]

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

בכל מקרה כמה שאני בודק אצלי אני לא רואה איטיות אפילו לא יותר מ2 שניות. הרוב אצלי סביבות 300ms.
עריכה: בדקתי שוב ואני רואה שבדומיין שהוא בודק אותו פעם ראשונה מתווסף המתנה ל DNS בין 50ms ל 300ms שזה דבר שאי אפשר להימנע ממנו.
פעם שניה יש לו כבר קאש.

[shraga]

פוסט זה נמחק!

[chv]

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

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

[magicode]

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

[magicode]

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

[Chocolate]

@magicode
בעבר כבר פניתי על זה, ואז זכור לי שהאירכו את הTIMEOUT

אני נתקל בזה המון, וגם שלחתי פניה על זה
https://netfree.link/app/#/tickets/ticket/2193550

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

[אלף אלף]

@magicode אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

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

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

@magicode אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

בכל מקרה כמה שאני בודק אצלי אני לא רואה איטיות אפילו לא יותר מ2 שניות. הרוב אצלי סביבות 300ms.

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

[YP]

@magicode אני מבקש לשאול שאלת בור, אני לא מבין גדול: במקום שכל משתמש ישלח את ה API לבדוק בסרטון מאיזה ערוץ הוא, למה לא תכתבו סקריפט שסורק בכל יום למשל את כלל הערוצים הפתוחים בנטפרי ומאנדקס את רשימות הסרטונים שלהם. ובעת חיפוש גוגל, ה API יבדוק מול מאגר המידע של נטפרי.
זה לא יפחית גם את המשאבים שדורש ענין זה מנטפרי?

[magicode]

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

[magicode]

@chocolate אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

@magicode
בעבר כבר פניתי על זה, ואז זכור לי שהאירכו את הTIMEOUT

אני נתקל בזה המון, וגם שלחתי פניה על זה
https://netfree.link/app/#/tickets/ticket/2193550

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

זה שיחזור מאוד טוב של הבאג.

פה זה מגיב מהר.
https://www.united.com/

ופה זה בכלל לא מגיב.
https://www.google.com/~netfree/test-url?u=https%3A%2F%2Fwww.united.com%2F

[משוש]

@chv אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

@עמאר השרשור לא על הנושא הזה, אבל אני יענה בקצרה.

לא אני לא מדבר על ה'חתיכה של עמוד בנטפרי'.

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

וגם מציק החלק המרגיז באיטיותו שנכפה על המשתמש - בדיקת הכתובות של התוצאות אם פתוחות בנטפרי או לא.
לדף התוצאות חיפוש מוזרק קוד, ששולח בקשת HTTP על כל אחת מהכתובות בדף התוצאות, ל-API של נטפרי לראות אם פתוח או לא, ורק אז מציג את התוצאה ברשימת התוצאות (אם היא פתוחה)
ה-API הזה רחוק מלהיקרא 'מהיר', ועוד יותר גרוע - כשהוא נתקע או מאיזו סיבה שהיא לא מחזיר תשובה - הקוד בקליינט ממתין 30 שניות (כך נראה מעיון בקוד - 30000ms)!! ואפילו אז - הוא לא פשוט מציג את התוצאה וזהו, אלא כותב לי מידע מחכים "TIMEOUT". לא יכלו פשוט להציג את התוצאה וזהו? הרי מה יקרה, אם זה חסום זה חסום, ואם לא אז לא.. נשגב מבינתי.
עריכה יכול להיות שלא נכון להאשים את ה-API עצמו באיטיות (הוא לא כזה איטי באמת) אלא יכול להיות שהבעיה היא בקוד. כלומר במימוש הזה בצורה של הרבה קריאות HTTP שיוצאות יחד (ולא מנוהלות בצורה חדשנית יותר מידיי. היום אפשר להאזין ישירות לסוקט, בדפדפן. לא משנה) יש בעייתיות, זה יהיה איטי תמיד, הן בגלל הגבלות של הדפדפן של כמות הבקשות שהוא נותן לשלוח ולקבל בו זמנית, והן בגלל הגבלות טכניות של הכמות האפשרית במכונה הספציפית של משתמש הקצה.
אפשר לשדרג את הקוד הזה בצורה מאוד פשוטה, לשלוח את כל הכתובות ל-API בבקשת HTTP אחת, ולקבל תשובה אחת מה-API שתכיל מערך תוצאות.
זה לכשעצמו ימהיר את חוויית הגוגל בנטפרי פי כמה וכמה.

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

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

[nigun]

@magicode אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

בכל מקרה כמה שאני בודק אצלי אני לא רואה איטיות אפילו לא יותר מ2 שניות. הרוב אצלי סביבות 300ms.

זה אולי תלוי בחיפוש
עכשיו הקלטתי נושא שאני בדיוק מחפש עליו והתשובות נעות בין 1-3.44 שניות (באינטרנט קווי)

[yzahn]

אם אני לא טועה, יש לאחרונה שינוי לטובה בחיפושי גוגל

[shloimy95]

@yzahn אמר בפיצ'ר | ממשק ניטור מערכות נטפרי:

אם אני לא טועה, יש לאחרונה שינוי לטובה בחיפושי גוגל

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

[yzahn]

@shloimy95 לא התעמקתי, אולי לא השתנה כלום

[טהור נט]

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