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

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