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

ב-Google Cloud Search SDK יש מספר פרמטרים של הגדרה באספקה של Google, שמשמשים את כל המחברים. אם יודעים איך לכוונן את ההגדרות האלה, תוכלו לייעל מאוד את הוספת הנתונים לאינדקס. במדריך הזה מפורטות כמה בעיות שעשויות להופיע במהלך ההוספה לאינדקס, יחד עם ההגדרות שמשמשות כדי לפתור אותן.

הערה: התנאים וההגדרות שמוזכרים במדריך הזה מפורטים במאמר יצירת מחבר תוכן ובפרמטרים של הגדרות שסופקו על ידי 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.

לבסוף, כדאי להשתמש בשיטה 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	מזהה את מספר ה-threads, 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 להוסיף לאינדקס רק פריטים עם הסטטוסים האלה.	משתמש מעבר אחד בודק את כל הסטטוסים	כדאי להתנסות בשימוש במודלים שונים של תעבורה בו-זמנית כדי לקבל סטטוסים שונים.

הערה: אל תציינו כמה הגדרות של מעברים עם בקשות חופפות לסקר (אותו תור וערכי סטטוס). במקום זאת, כדאי להגדיל את hostload כדי למקסם את התפוקה.

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

ה-SDK מפסיק לזמן קצוב או מפריע בזמן העלאה של קבצים גדולים

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

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

הערה: Cloud Search לא תומך בשימוש בערך 0 כדי להשבית את הזמנים הקצובים לתפוגה.