אופטימיזציה של הביצועים של Agent Runtime והרחבתם

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

בדף הזה מפורטות שיטות מומלצות לאופטימיזציה ולהתאמה לעומס של הביצועים ב-Agent Runtime, בתרחישים הבאים:

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

בעיה בהפעלה במצב התחלתי (cold start)

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

לדוגמה, אם שולחים 300 בקשות מקבילות לנציג עם ערך ברירת המחדל של min_instances=1, יכולות להתקבל התוצאות הבאות:

  • הפעלה מההתחלה (הפעלה ראשונה): זמן אחזור ממוצע של כ-4.7 שניות.

  • הפעלה במצב ביניים (הפעלה שנייה מיידית): זמן אחזור ממוצע של כ-0.4 שניות.

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

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

  • מגדירים ערך min_instances גבוה מספיק כדי לטפל בתנועה הבסיסית. לדוגמה, אם מגדירים את min_instances=10 לסוכן לדוגמה, זמן האחזור הממוצע של התחלה קרה יכול לרדת לכ-1.4 שניות. באפליקציות עם נפח תנועה גבוה או עם קפיצות בנפח התנועה, צריך להגדיר את min_instances לערך שיכול להתמודד עם העומס הרגיל בלי צורך לשנות את קנה המידה מ-1. לגבי טווח הערכים המקובלים, ראו את מאמר העזר של משאב ה-REST ReasoningEngineSpec.

  • שליחת עומס יציב, רציף וצפוי ל-Agent Runtime באמצעות תור. לדוגמה, אם מריצים בדיקת עומס מתמשכת של 1,500 שאילתות לדקה (25 שאילתות לשנייה) למשך 60 שניות על סוכן שמבוסס על ערכת פיתוח לסוכנים (ADK) עם min_instances=10 וערך ברירת המחדל של concurrency (9), יכולה להתקבל התוצאה הבאה:

    • זמן האחזור הממוצע נמוך באופן עקבי, בערך 1.6 שניות.

עומס יציב ורציף שומר על השירות חם ומניב ביצועים אופטימליים.

עובדים אסינכרוניים שלא מנוצלים מספיק

כברירת מחדל, container_concurrency מוגדר לקוד סינכרוני, שבו כל מכונה של Agent Platform מטפלת רק בבקשה אחת בכל פעם. סוכנים אסינכרוניים, כמו אלה שמבוססים על ADK, יכולים לטפל בכמה בקשות קלט/פלט (כמו קריאות ל-LLM או קריאות API לכלי) בו-זמנית.

לדוגמה, שליחת 300 בקשות מקבילות לנציג מבוסס-ADK עם min_instances=10 ו-container_concurrency=9 כברירת מחדל יכולה להניב את התוצאה הבאה:

  • זמן האחזור החציוני הוא בערך 4 שניות, אבל זמן האחזור המקסימלי מגיע ל-60 שניות. זה מצביע על כך שהבקשות ממתינות בתור ארוך בזמן שהשירות מתרחב אופקית בהתאם לעומס (scale out) באיטיות.

כדי לצמצם את מספר ה-workers האסינכרוניים שלא מנוצלים, מגדילים את הערך של container_concurrency כדי לאפשר לכל מכונה של Agent Platform לטפל במספר בקשות. מספר הבקשות המקבילות שכל תהליך של סוכן יכול לטפל בהן הוא container_concurrency / 9. הערך 9 מייצג את מספר תהליכי הסוכן שפועלים במקביל בכל קונטיינר.

לדוגמה, אם שולחים 300 בקשות מקבילות לאותו סוכן מבוסס-ADK עם min_instances=10 ו-container_concurrency=36, יכולה להתקבל התוצאה הבאה:

  • זמן האחזור המקסימלי יורד מ-60 שניות ל-7 שניות בערך. זה מראה שהמכונות הקיימות יכולות להתמודד עם העלייה החדה בתנועה בצורה יעילה יותר.

לסוכנים אסינכרוניים (כמו סוכנים שמבוססים על ADK), הגדירו את container_concurrency לכפולה של 9 (לדוגמה, 36) כנקודת התחלה. כך אפשר לשפר את התגובה לעליות חדות בתנועה ולצמצם את זמן האחזור שנובע מהרחבה אופקית בהתאם לעומס (scale out).

שימו לב שאם הערך של container_concurrency גבוה מדי, עלולות להתרחש שגיאות של מחסור בזיכרון (OOM).

המאמרים הבאים

מדריך

איך מנהלים סוכנים שנפרסו בסביבת זמן הריצה המנוהלת של Agent Platform.

מדריך

שימוש בסוכן עם Agent Platform Runtime.

משאב

מידע ולמידה על המכסות והמגבלות של Agent Platform.