Agent Runtime מספק פרמטרים לפריסה שמאפשרים לכם לבצע אופטימיזציה ולהתאים את הביצועים של הסוכנים שלכם. הגדרת הפרמטרים האלה מאפשרת לכם לטפל ביעילות בדפוסי תנועה בלתי צפויים או עם עליות חדות.
בדף הזה מפורטות שיטות מומלצות לאופטימיזציה של הביצועים של Agent Runtime ולהתאמה שלהם לעומס, כולל התרחישים הבאים:
התרחישים מראים איך להשתמש בפרמטרים של פריסה כדי לפתור צווארי בקבוק נפוצים בביצועים, במיוחד בדפוסי תנועה בלתי צפויים ועם עליות חדות באפליקציות בעולם האמיתי.
בעיית ההפעלה במצב התחלתי (cold start)
הפעלה במצב התחלתי (cold start) מתרחשת כשמתקבלת בקשה ואין מופעים או קונטיינרים במצב המתנה שיכולים לטפל בה, ולכן Agent Runtime נאלץ להפעיל מופע או קונטיינר חדש. הפעולה הזו מוסיפה זמן אחזור משמעותי לבקשה.
לדוגמה, שליחת 300 בקשות בו-זמניות לסוכן עם ערך ברירת המחדל min_instances=1 יכולה להציג את התוצאות הבאות:
הפעלה מההתחלה (cold start) (הפעלה ראשונה): חביון ממוצע של כ-4.7 שניות.
הפעלה במצב ביניים (Warm start) (הפעלה שנייה מיידית): זמן האחזור הממוצע הוא כ-0.4 שניות.
התקורה של יותר מארבע שניות נובעת כמעט כולה ממופעים חדשים שמופעלים כדי לטפל בעומס.
כדי לנסות לפתור את בעיית ההפעלה במצב התחלתי (cold start), אפשר לנסות את השיטות הבאות:
מגדירים
min_instancesערך גבוה מספיק כדי לטפל בתנועה הבסיסית. לדוגמה, הגדרתmin_instances=10לסוכן לדוגמה יכולה להקטין את זמן האחזור הממוצע להפעלה במצב התחלתי (cold start) לכ-1.4 שניות. באפליקציות עם תנועה גבוהה או תנועה עם עליות וירידות חדות, צריך להגדיר אתmin_instancesלערך שיכול להתמודד עם העומס הרגיל בלי להגדיל את הקיבולת מ-1. הערך המקסימלי הוא 10.שליחת עומס יציב, רציף וצפוי ל-Agent Runtime באמצעות תור. לדוגמה, אם מריצים בדיקת עומס מתמשכת של 1,500 שאילתות לדקה (25 שאילתות לשנייה) למשך 60 שניות בסוכן שמבוסס על Agent Development Kit (ADK) עם
min_instances=10ו-concurrency(9) כברירת מחדל, יכולה להתקבל התוצאה הבאה:- זמן האחזור הממוצע נמוך באופן עקבי, ועומד על כ-1.6 שניות.
עומס יציב ורציף שומר על השירות פעיל ומוביל לביצועים אופטימליים.
עובדים אסינכרוניים שלא מנוצלים מספיק
כברירת מחדל, container_concurrency מוגדר לקוד סינכרוני, שבו כל מופע של Agent Platform מטפל רק בבקשה אחת בכל פעם.
סוכנים אסינכרוניים, כמו אלה שמבוססים על הערכה לפיתוח סוכנים (ADK), יכולים לטפל בכמה בקשות שקשורות לקלט/פלט (כמו LLM או קריאות לכלים) בו-זמנית.
לדוגמה, שליחת 300 בקשות בו-זמניות לסוכן שמבוסס על ADK עם min_instances=10 ועם ברירת המחדל container_concurrency=9 יכולה להניב את התוצאה הבאה:
- זמן האחזור החציוני הוא בערך 4 שניות, אבל זמן האחזור המקסימלי מגיע ל-60 שניות. המשמעות היא שהבקשות ממתינות בתור ארוך בזמן שהשירות מתרחב לאט.
כדי לצמצם את השימוש הנמוך בעובדים אסינכרוניים, מגדילים את container_concurrency כדי לאפשר לכל מופע של Agent Platform לטפל בכמה בקשות. מספר הבקשות בו-זמנית שכל סוכן יכול לטפל בהן הוא container_concurrency / 9. הערך 9 מייצג את מספר התהליכים של הסוכן שפועלים במקביל בכל קונטיינר.
לדוגמה, שליחת 300 בקשות בו-זמניות לאותו סוכן שמבוסס על ADK עם min_instances=10 ו-container_concurrency=36 יכולה להניב את התוצאה הבאה:
- החביון המקסימלי יורד מ-60 שניות לכ-7 שניות. הנתונים האלה מראים שהמופעים הקיימים יכולים לספוג את העלייה החדה בתנועת הגולשים בצורה יעילה יותר.
עבור סוכנים אסינכרוניים (כמו סוכנים שמבוססים על ADK), כנקודת התחלה, מגדירים את container_concurrency ככפולה של 9 (לדוגמה, 36). כך משפרים את מהירות התגובה לעליות חדות בתנועה ומקטינים את זמן האחזור של הרחבת הקיבולת.
הערה: הגדרת ערך גבוה מדי של container_concurrency עלולה לגרום לשגיאות של חוסר זיכרון (OOM).