שיטות מומלצות לשימוש ברשת עם זמן אחזור

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

הסבר על ביצועים של זמן אחזור

הביצועים של Cloud Healthcare API נמדדים לפי זמן האחזור בין:

  1. כששולחים בקשה ל-Cloud Healthcare API.
  2. כשמקבלים תשובה מלאה לבקשה.

החביון מורכב משלושה רכיבים:

  • זמן הלוך ושוב (RTT)
  • זמן האחזור של עיבוד בשרת
  • תפוקת השרת

המרחק הגיאוגרפי בינך לבין השרת שאליו נשלחות הבקשות יכול להשפיע באופן משמעותי על זמני הלוך ושוב (RTT) ועל קצב העברת הנתונים של השרת. אפשר למצוא את זמן האחזור ואת קצב העברת הנתונים בין אזורים שנמדדו עבור רשתות Google Cloud בלוח בקרה בזמן אמת. במרכז הבקרה מוצגים הביצועים שהלקוח יכול לצפות להם ממיקומים שונים כששולחים בקשות לשרתים של Cloud Healthcare API.

מדידת ביצועים של זמן האחזור

הכלים ולוחות הבקרה הבאים מאפשרים למדוד את ביצועי הבקשות לשרתים של Cloud Healthcare API ומשרתים של Cloud Healthcare API:

  • Google Cloud מדדי זמן האחזור של המסוף: אפשר לראות את זמן האחזור בצד השרת של בקשות Cloud Healthcare API בGoogle Cloud מסוף. מידע נוסף זמין במאמר בנושא Google Cloud מדדים.

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

  • חלונית הרשת ב-Chrome: אפשר לעיין בפעילות ברשת בכלי הפיתוח ל-Chrome כדי לראות את פרטי הביצועים של בקשת HTTP שנשלחה מדפדפן.

הפחתת זמן האחזור של הבקשה

בקטע הזה מתוארות שיטות שונות לצמצום זמן האחזור של בקשות שנשלחות אל Cloud Healthcare API.

שליחת בקשות למיקום האזורי הקרוב ביותר

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

שליחת בקשות warmup

כשלקוח שולח בקשות לשרת Cloud Healthcare API בפעם הראשונה במהלך סשן, הלקוח מבצע לחיצות ידיים של TCP עם השרת כדי ליצור חיבורים לבקשות HTTP. בכל הבקשות הבאות אפשר להמשיך להשתמש בחיבורים האלה, וכך הלקוח לא צריך לשלם את העלות הנוספת של TCP שקשורה בדרך כלל לבקשה. כך מתקבלים ביצועים טובים יותר בשליחת בקשות.

שליחת בקשות במקביל באמצעות HTTP/1.1 או HTTP/2

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

  • כששולחים בקשות מקבילות, כדאי לנסות למצוא מספר אידיאלי של בקשות מקבילות. המספר האידיאלי תלוי בכמה גורמים, כולל יכולות החומרה והרשת שלכם ומספר הבקשות שנשלחות. כדאי לערוך בדיקות כדי למצוא את המספר האידיאלי.
  • כשהדבר אפשרי, שולחים בקשות מהלקוח באמצעות HTTP/2. פרוטוקול HTTP/2 מספק ביצועים טובים יותר מאשר HTTP/1.1, כי הוא דורש רק חיבור TCP אחד כששולחים כמה בקשות ברצף או בו-זמנית. כתוצאה מכך, אפשר להימנע מתקורה של לחיצת יד של TCP.

  • אם אי אפשר להשתמש ב-HTTP/2, צריך להשתמש ב-HTTP/1.1 עם חיבור מתמשך. אפשר להימנע מתקורה של לחיצת יד ב-TCP אם בקשות החימום כבר נשלחו. אם משתמשים בחיבור מתמשך, יכול להיות שיהיה צורך לנהל חיבור אופטימלי עם מאגר חיבורים לספריית ה-HTTP.

    לדוגמה, כדי להגדיר מאגר חיבורים עם 20 בקשות בו-זמניות באמצעות ספריית הלקוח של Google HTTP ל-Java, הקוד שלכם יכלול את השורות הבאות:

    PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
// Support 20 concurrent requests.
cm.setDefaultMaxPerRoute(20);
cm.setMaxTotal(100);
HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();

    כדי להגדיר מאגר חיבורים עם 20 בקשות בו-זמניות באמצעות Node.js, הקוד שלכם יכלול את השורות הבאות:

    require('http').globalAgent.maxSockets = 20