בדף הזה מוסבר איך ליצור תור דחיפה (push queue) ולהתאים אותו אישית, ואיך לבדוק את התוכן של התור.
שימוש בקובץ תצורת תור ליצירת תורים
כדי לעבד משימה, צריך להוסיף אותה לתור דחיפה (push queue). App Engine מספק תור דחיפה (push queue) ברירת מחדל, בשם default, שמוגדר ומוכן לשימוש עם הגדרות ברירת מחדל. אם רוצים, אפשר פשוט להוסיף את כל המשימות לתור ברירת המחדל, בלי ליצור ולהגדיר תורים אחרים.
כדי להוסיף תורים או לשנות את הגדרת ברירת המחדל, צריך לערוך את קובץ התצורה של התור באפליקציה ולהעלות אותו ל-App Engine. אפשר ליצור עד 100 תורים. אי אפשר ליצור תורים באופן דינמי.
קובץ התצורה של התור הזה מגדיר שני תורים:
queue:
- name: queue-blue
target: v2.task-module
rate: 5/s
- name: queue-red
rate: 1/s
כדי להעלות את הקובץ:
gcloud app deploy queue.yaml
כל המשימות שנוספות ל-queue-blue נשלחות למודול היעד v2.task-module.
קצב הרענון של queue-red השתנה מ-5/s ל-1/s. המשימות יוסרו מהתור ויישלחו ליעדים שלהן בקצב של משימה אחת לשנייה.
אם מוחקים תור, צריך לחכות בערך 7 ימים לפני שיוצרים תור חדש עם אותו שם.
יש עוד הרבה פרמטרים שאפשר להוסיף לקובץ תצורה כדי להתאים אישית את ההתנהגות של תור דחיפה (push queue). מידע נוסף זמין במאמר בנושא קובץ התצורה של התור.
הגדרת קצב העיבוד של תור דחיפה (push queue)
אתם יכולים לקבוע את קצב העיבוד של המשימות בכל אחד מהתורים על ידי הגדרת הנחיות אחרות, כמו rate, bucket_size ו-max_concurrent_requests.
תור המשימות משתמש במאגרי אסימונים כדי לשלוט בקצב הביצוע של המשימות. לכל תור עם שם יש token bucket שמכיל אסימונים, עד למקסימום שצוין על ידי bucket_size, או עד למקסימום של 5 אסימונים אם לא צוין גודל המאגר.
בכל פעם שהאפליקציה מבצעת משימה, אסימון מוסר מהמאגר.
האפליקציה ממשיכה לעבד משימות בתור עד שנגמרים האסימונים בדלי של התור. מערכת App Engine ממלאת מחדש את המאגר באסימונים חדשים באופן רציף על סמך rate שהגדרתם לתור.
אם התור מכיל משימות לעיבוד, והקטגוריה של התור מכילה אסימונים, מערכת App Engine מעבדת בו-זמנית את כל המשימות שיש להן אסימונים. זה עלול להוביל לעיבוד אינטנסיבי, לצריכת משאבי מערכת ולהתחרות בבקשות של משתמשים.
אם רוצים למנוע הפעלה של יותר מדי משימות בו-זמנית או למנוע התנגשות ב-Datastore, משתמשים ב-max_concurrent_requests.
בדוגמה הבאה אפשר לראות איך מגדירים את max_concurrent_requests כדי להגביל את המשימות, וגם איך להתאים את גודל הקטגוריה ואת הקצב בהתאם לצרכים של האפליקציה ולמשאבים הזמינים:
queue:
- name: queue-blue
rate: 20/s
bucket_size: 40
max_concurrent_requests: 10
הגדרת מגבלות אחסון לכל התורים
אפשר להשתמש בקובץ התצורה של התור כדי להגדיר את נפח האחסון הכולל שנתוני המשימות יכולים לתפוס בכל התורים. כדי להגדיר את מגבלת האחסון הכוללת, צריך לכלול רכיב בשם total_storage_limit ברמה העליונה:
# Set the total storage limit for all queues to 120MB
total_storage_limit: 120M
queue:
- name: queue-blue
rate: 35/s
הערך הוא מספר שאחריו יחידה: B לבייטים, K לקילובייטים, M למגה-בייטים, G לג'יגה-בייטים, T לטרה-בייטים. לדוגמה, 100K
מציין מגבלה של 100 קילובייט. אם הוספת משימה תגרום לחריגה ממגבלת האחסון של התור, הקריאה להוספת המשימה תיכשל. המגבלה שמוגדרת כברירת מחדל היא 500M (500 מגה-בייט) לאפליקציות חינמיות. לאפליקציות בתשלום אין מגבלה עד שמגדירים אותה במפורש. אפשר להשתמש במגבלה הזו כדי להגן על האפליקציה מפני פצצת פיצול (fork) – שגיאת תכנות שבה כל משימה מוסיפה כמה משימות אחרות במהלך ההרצה שלה.
אם האפליקציה מקבלת שגיאות לגבי מכסה לא מספיקה כשמוסיפים משימות, הגדלת מגבלת האחסון הכוללת יכולה לעזור. אם אתם משתמשים בתכונה הזו, מומלץ מאוד להגדיר מגבלה שתתאים לנפח האחסון שנדרש למשימות של כמה ימים. כך התורים יכולים לגבות את עצמם באופן זמני ולהמשיך לקבל משימות חדשות בזמן שהם מטפלים במשימות שכבר נמצאות בהם, ועדיין להיות מוגנים מפני שגיאת תכנות של פצצת פיצול.
מעקב אחרי תורים במסוף Google Cloud
במסוף Google Cloud , נכנסים לדף Cloud Tasks.
שימו לב: אם תעברו לדף Task queue של App Engine, תראו הוראות שיעזרו לכם לעבור לדף Cloud Tasks. העדכון הזה ב Google Cloud מסוף לא משנה את אופן הפעולה של תורי משימות.
מפעילים את Cloud Tasks API.
אחרי שתגיעו לדף Cloud Tasks, תופיע רשימה של כל התורים באפליקציה. לחיצה על שם התור פותחת את הדף פרטי התור, שבו מוצגות כל המשימות בתור שנבחר.