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

‏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 הוא 1,000 והערך של batchSize הוא 5, הערך של maxActiveBatches צריך להיות 250. 50 הבקשות הנוספות הן מאגר לניסיון חוזר של בקשות. הגדלת המכסה הזו מאפשרת למחבר לאסוף את כל הבקשות בקבוצה אחת ללא חסימה.
traverse.threadPoolSize	מספר השרשוריים שהמחבר יוצר כדי לאפשר עיבוד מקביל. איטרטור יחיד מאחזר פעולות (בדרך כלל אובייקטים מסוג RepositoryDoc) באופן טורי, אבל הקריאות ל-API מעובדות במקביל באמצעות מספר חוטים של threadPoolSize. כל שרשור מעבד פריט אחד בכל פעם. אם תגדירו את הערך 50 כברירת מחדל, המערכת תעבד בו-זמנית עד 50 פריטים בלבד, ותהליך העיבוד של פריט בודד (כולל הבקשה להוספה לאינדקס) נמשך כ-4 שניות.	50	כדאי לנסות להגדיל את threadPoolSize בכפולה של 10.

לבסוף, כדאי להשתמש ב-method‏ setRequestMode() כדי לשנות את מצב הבקשה ל-API (ASYNCHRONOUS או SYNCHRONOUS).

מידע נוסף על פרמטרים של קובץ תצורה זמין במאמר פרמטרים של תצורה שסופקו על ידי Google.

קצב העברת הנתונים להוספה לאינדקס נמוך ב-ListTraversalConnector

כברירת מחדל, מחבר שמטמיע את ListTraversalConnnector משתמש ב-traverser יחיד כדי להוסיף את הפריטים לאינדקס. כדי להגדיל את תפוקת ההוספה לאינדקס, אפשר ליצור כמה מודלים של סריקה, לכל אחד מהם הגדרה משלו שמתמקדת בסטטוסים ספציפיים של פריטים (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 שניות לפני שהוא מנסה שוב. ההגדרה הזו משמשת רק את ListingConnector	10	כדאי לנסות להקטין את הערך ל-1.
traverser.t1.pollRequest.statuses = status1, status2, …	מציין את הסטטוסים status1,‏ status2,‏ … של הפריטים שרוצים להוסיף לאינדקס. לדוגמה, הגדרת status1 ל-NEW_ITEM ו-status2 ל-MODIFIED מורה לכלי הניווט t1 להוסיף לאינדקס רק פריטים עם הסטטוסים האלה.	בודק אחד בודק את כל הסטטוסים	כדאי לנסות להשתמש במודלים שונים של סריקה כדי לבדוק סטטוסים שונים.

מידע נוסף על פרמטרים של קובץ תצורה זמין במאמר פרמטרים של תצורה שסופקו על ידי Google.

ערכות SDK שנגמרות או מופסקות במהלך העלאת קבצים גדולים

אם חל תוקף זמן קצוב או הפסקה ב-SDK במהלך העלאת קבצים גדולים, צריך לציין זמן קצוב ארוך יותר באמצעות traverser.timeout=s (כאשר s = מספר השניות). הערך הזה מציין כמה זמן לוקח לשרשראות העבודה לעבד פריט. הזמן הקצוב לתפוגה שמוגדר כברירת מחדל ב-SDK הוא 60 שניות לשרשראות של כלי הניווט. בנוסף, אם חל זמן קצוב לתפוגה של בקשות API מסוימות, תוכלו להשתמש בשיטות הבאות כדי להגדיל את ערכי הזמן הקצוב לתפוגה של הבקשות:

פרמטר של זמן קצוב לבקשה	תיאור	ברירת מחדל
indexingService.connectTimeoutSeconds	זמן קצוב לתפוגה של חיבור לבקשות API להוספה לאינדקס.	120 שניות.
indexingService.readTimeoutSeconds	זמן קצוב לתפוגה לקריאה של בקשות API להוספה לאינדקס.	120 שניות.