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

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

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

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

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

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

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

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

  • הפעלה במצב ביניים (Warm start) (הפעלה שנייה מיידית): זמן אחזור ממוצע של כ-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 או לכלים) בו-זמנית.

לדוגמה, שליחת 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.