ה-SDK של Google Cloud Search מכיל מספר פרמטרים של הגדרה, ש-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 = מספר השניות). הערך הזה מציין את משך הזמן שנדרש לשרשורי עובדים כדי לעבד פריט. הזמן הקצוב לתפוגה שמוגדר כברירת מחדל ב-SDK הוא 60 שניות לשרשורי מעבר. בנוסף, אם נתקלים בבקשות API נפרדות לזמן קצוב, תוכלו להשתמש בשיטות הבאות כדי להגדיל את ערכי הזמן הקצוב לתפוגה של בקשות:
פרמטר של זמן קצוב לתפוגה של בקשה | תיאור | ברירת המחדל |
---|---|---|
indexingService.connectTimeoutSeconds |
זמן קצוב לתפוגה של חיבור לבקשות API להוספה לאינדקס. | 120 שניות. |
indexingService.readTimeoutSeconds |
קריאת הזמן הקצוב לתפוגה של בקשות API להוספה לאינדקס. | 120 שניות. |