ב-Google Cloud Search SDK יש כמה הגדרות ש-Google מספקת הפרמטרים שבהם משתמשים כל המחברים. הידעת איך לכוונן את ההגדרות האלה לייעל מאוד את הוספת הנתונים לאינדקס. במדריך הזה מפורטות כמה בעיות עשויות להופיע במהלך ההוספה לאינדקס ואת ההגדרות שמשמשות לפתרון הבעיות.
תפוקת ההוספה לאינדקס נמוכה עבור FullTraversalConnector
הטבלה הבאה מפרטת את הגדרות התצורה לשיפור התפוקה של FullTraversalConnector:
| הגדרה | תיאור | ברירת מחדל | אפשר לנסות לשנות את ההגדרות האישיות |
|---|---|---|---|
traverse.partitionSize |
מספר הApiOperation() לעיבוד בקבוצות לפני אחזור של APIOperation() נוספים. ה-SDK ממתין לעיבוד המחיצה הנוכחית לפני שהוא מאחזר פריטים נוספים. ההגדרה הזו תלויה בנפח הזיכרון הזמין. מחיצות בגדלים קטנים יותר, כמו 50 או 100, דורשים פחות זיכרון אבל יותר המתנה ממתינים בשם ה-SDK. |
50 | אם יש לך הרבה זיכרון, כדאי להגדיל את partitionSize ל-1,000 או יותר. |
batch.batchSize |
מספר הבקשות באצווה. בסיום החלוקה למחיצות, ה-SDK ימתין עד שכל הבקשות באצווה יעובדו מהמחיצה. קבוצות גדולות יותר מחייבות המתנה ארוכה יותר. | 10 | כדאי לנסות להקטין את גודל הקבוצה. |
batch.maxActiveBatches |
מספר הקבוצות המותרות להפעלה בו-זמנית. | 20 | אם מקטינים את הערך של batchSize, צריך להצמיד את maxActiveBatches לנוסחה הבאה: maxActiveBatches = (partitionSize / batchSize) + 50. לדוגמה, אם הערך במדד partititionSize הוא 1000 והערך של batchSize הוא 5, הערך של maxActiveBatches צריך להיות 250. ה-50 הנוספים משמשים כמאגר נתונים זמני לבקשות של ניסיונות חוזרים. העלייה הזו מאפשרת למחבר לקבץ את כל הבקשות ללא חסימה. |
traverse.threadPoolSize |
מספר השרשורים שהמחבר יוצר כדי לאפשר עיבוד מקביל. איטרטור יחיד מאחזר פעולות (בדרך כלל RepositoryDoc אובייקטים) באופן סדרתי, אבל עיבוד הקריאות ל-API מתבצע במקביל באמצעות מספר threadPoolSize של תהליכונים. כל שרשור מעובד פריט אחד בכל פעם. ברירת המחדל של 50 פריטים תעבד רק 50 פריטים בו-זמנית, והעיבוד של פריט יחיד יימשך כ-4 שניות (כולל הבקשה להוספה לאינדקס). |
50 | צריך להגדיל את threadPoolSize בכפולה של 10. |
לסיום, כדאי להשתמש בשיטה setRequestMode() כדי לשנות את מצב הבקשה של ה-API (ASYNCHRONOUS או SYNCHRONOUS).
למידע נוסף על פרמטרים של קובצי תצורה, ניתן לעיין ב- פרמטרים של הגדרות ש-Google מספקת.
תפוקת ההוספה לאינדקס נמוכה ב-ListTraversalConnector
כברירת מחדל, מחבר שמטמיע את ListTraversalConnnector משתמש
משתמש יחיד לאינדקס כדי להוסיף את הפריטים שלך לאינדקס. כדי להגדיל את תפוקת ההוספה לאינדקס, אפשר:
ליצור כמה משתמשים וכל אחד מהם עם הגדרה משלו תוך התמקדות
סטטוסים של פריטים (NEW_ITEM, MODIFIED וכן הלאה). בטבלה הבאה מפורטים
הגדרות אישיות לשיפור התפוקה:
| הגדרה | תיאור | ברירת מחדל | אפשר לנסות לשנות את ההגדרות האישיות |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | יצירת מעבר נפרד אחד או יותר כאשר t1, t2, t3, ... הוא השם הייחודי של כל אחד מהם. לכל משתמש חולף בעל שם יש קבוצת הגדרות משלו, שמזוהות באמצעות השם הייחודי של מבצע הדילוג, למשל traversers.t1.hostload ו-traversers.t2.hostload. | משתמש/ת אחד/ת | השתמש בהגדרה הזו כדי להוסיף חוצים נוספים |
traversers.t1.hostload = n | משמש לזיהוי מספר השרשורים, n, שישמשו להוספת פריטים לאינדקס בו-זמנית. | 5 | כדאי לנסות לבצע כוונון של n בהתאם לעומס שרוצים להוסיף למאגר. מתחילים בערכים של 10 ומעלה. |
schedule.pollQueueIntervalSecs = s | מזהה את מספר השניות, s, שצריך להמתין לפני סקרים מחדש . מחבר התוכן ימשיך לבדוק פריטים כל עוד ה-API מחזיר פריטים בתגובה לסקר. כשהתגובה לסקר ריקה, המחבר ממתין למשך s שניות לפני שמנסים שוב. ההגדרה הזו משמשת רק את ListingsConnector | 10 | כדאי לנסות להוריד ל-1. |
traverser.t1.pollRequest.statuses = status1, status2, … | המדיניות הזו מציינת את הסטטוסים של הפריטים שרוצים להוסיף לאינדקס: status1, status2, …. לדוגמה, אם קובעים את הערך status1 לערך NEW_ITEM ואת הערך status2 לערך MODIFIED, למשתמש t1 תהיה הוראה להוסיף לאינדקס רק פריטים עם הסטטוסים האלה. | בדיקת traverser אחד לכל הסטטוסים | התנסו עם סקרים שונים של מעברים לגבי סטטוסים שונים. |
למידע נוסף על פרמטרים של קובצי תצורה, ניתן לעיין ב- פרמטרים של הגדרות ש-Google מספקת.
הזמן הקצוב לתפוגה של ערכת ה-SDK מופסק בזמן ההעלאה של קבצים גדולים
אם בזמן ההעלאה של קבצים גדולים יש הפרעות או זמנים קצובים לתפוגה של ה-SDK:
מציינים זמן קצוב ארוך יותר באמצעות
traverser.timeout=s
(s = מספר השניות). הערך הזה מציין את משך הזמן של
שה-threads צריכים לעבד פריט. הזמן הקצוב לתפוגה שמוגדר כברירת מחדל ב-SDK הוא 60 שניות
לשרשורים מעבירים. בנוסף, אם אתם נתקלים בבקשות API נפרדות
של הזמן הקצוב לתפוגה, השתמשו בשיטות הבאות כדי להגדיל את ערכי הזמן הקצוב לתפוגה של בקשות:
| פרמטר של זמן קצוב לתפוגה של בקשה | תיאור | ברירת מחדל |
|---|---|---|
indexingService.connectTimeoutSeconds |
זמן קצוב לתפוגה של חיבור לבקשות API להוספה לאינדקס. | 120 שניות. |
indexingService.readTimeoutSeconds |
קריאת הזמן הקצוב לתפוגה של בקשות API להוספה לאינדקס. | 120 שניות. |