Agent Runtime מספק פרמטרים לפריסה שמאפשרים לכם לשפר את הביצועים של הסוכנים ולהרחיב אותם. הגדרת הפרמטרים האלה מאפשרת לכם לטפל ביעילות בדפוסי תנועה בלתי צפויים או בדפוסי תנועה עם עליות חדות.
בדף הזה מפורטות שיטות מומלצות לאופטימיזציה של הביצועים של Agent Runtime ולהתאמה שלהם לעומס, כולל התרחישים הבאים:
בתרחישים האלה מוסבר איך להשתמש בפרמטרים של פריסה כדי לפתור צווארי בקבוק נפוצים בביצועים, במיוחד בדפוסי תנועה בלתי צפויים עם עליות חדות באפליקציות בעולם האמיתי.
בעיה בהפעלה מההתחלה (cold start)
הפעלה במצב התחלתי (cold start) מתרחשת כשמתקבלת בקשה ואין מופעים או קונטיינרים במצב המתנה שיכולים לטפל בה, ולכן Agent Runtime נאלץ להפעיל חדש. הפעולה הזו מוסיפה זמן אחזור משמעותי לבקשה.
לדוגמה, שליחת 300 בקשות בו-זמניות לסוכן עם ערך ברירת המחדל min_instances=1 יכולה להציג את התוצאות הבאות:
הפעלה מההתחלה (cold start) (הפעלה ראשונה): חביון ממוצע של כ-4.7 שניות.
הפעלה במצב ביניים (Warm start) (הפעלה שנייה מיידית): חביון ממוצע של כ-0.4 שניות.
התקורה של יותר מארבע שניות נובעת כמעט כולה ממופעים חדשים שמופעלים כדי לטפל בעומס.
כדי לפתור את בעיית ההפעלה במצב התחלתי, אפשר לנסות את השיטות הבאות:
מגדירים
min_instancesערך גבוה מספיק כדי לטפל בתנועה הבסיסית. לדוגמה, הגדרתmin_instances=10לסוכן לדוגמה יכולה להפחית את זמן האחזור הממוצע של הפעלה במצב התחלתי (cold start) לכ-1.4 שניות. באפליקציות עם תנועה גבוהה או עם תנועה לא יציבה, צריך להגדיר אתmin_instancesלערך שיכול להתמודד עם העומס הרגיל בלי להגדיל את המכסה מ-1. הערך המקסימלי הוא 10.שליחת עומס יציב, רציף וצפוי ל-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 שניות. המשמעות היא שהבקשות ממתינות בתור ארוך בזמן שהשירות מתרחב לאט.
כדי לצמצם את השימוש הנמוך בעובדים אסינכרוניים, מגדילים את הערך של 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).