כוונון הגדרות המחבר

ה-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 שניות.