הסביבה של סוכן מאפשרת להגדיר פרמטרים לפריסה, כדי לשפר את הביצועים של הסוכנים ולהתאים אותם לצרכים שלכם. הגדרת הפרמטרים האלה מאפשרת לכם לטפל ביעילות בדפוסי תנועה בלתי צפויים או בדפוסי תנועה עם עליות חדות.
בדף הזה מפורטות שיטות מומלצות לאופטימיזציה של הביצועים של 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לסוכן לדוגמה יכולה להפחית את זמן האחזור הממוצע של הפעלה קרה לכ-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).