שימוש ב-gRPC עם ספריית הלקוח של Java

לקוח Java למצב Datastore מציע gRPC כאפשרות לשכבת התעבורה. שימוש באיגום חיבורים ב-gRPC מאפשר להפיץ בקשות RPC על פני כמה חיבורים, מה שיכול לשפר את הביצועים.

לפני שמתחילים

מתקינים את הגרסה האחרונה של הספרייה google-cloud-datastore.

איך מפעילים את התנהגות ההעברה של gRPC

כדי להפעיל את התנהגות ההעברה של gRPC, מוסיפים setTransportOptions לאתחול של הלקוח:

Java

DatastoreOptions datastoreOptions =
       DatastoreOptions.newBuilder()
               .setProjectId("my-project")
               .setDatabaseId("my-database")
               .setTransportOptions(GrpcTransportOptions.newBuilder().build())
               .build();

הגדרת אפשרויות התעבורה באופן מפורש ל-GrpcTransportOptions מגדירה את הלקוח להשתמש ב-gRPC במקום ב-HTTP כשהוא מבצע קריאות לשרת.

השבתת התנהגות ההעברה של gRPC

אפשר להשבית את התנהגות התעבורה של gRPC על ידי חזרה להתנהגות התעבורה של HTTP. כדי לעשות את זה, צריך להסיר את שורת הקוד .setTransportOptions או להחליף את GrpcTransportOptions ב-HttpTransportOptions. בנוסף, צריך לבנות מחדש את האפליקציה ולהפעיל אותה מחדש.

Java

// Use this code to deactivate the gRPC transport behavior
// by reverting to the HTTP transport behavior.
DatastoreOptions datastoreOptions = DatastoreOptions.newBuilder()
            .setProjectId("my-project")
            .setDatabaseId("my-database")
            .build();

// You can also use this code to revert to the HTTP transport behavior
DatastoreOptions datastoreOptions =
            DatastoreOptions.newBuilder()
                    .setProjectId("my-project")
                    .setDatabaseId("my-database")
                    .setTransportOptions(HttpTransportOptions.newBuilder()
                            .setConnectTimeout(1000)
                            .build())
                    .build();

הערה: רק לקוחות שהגדירו במפורש את GrpcTransportOptions ישנו את ההתנהגות שלהם עם השקת התכונה הזו. התכונה הזו לא תשנה את ההתנהגות של מופעי לקוח שכבר משתמשים ב-setTransportOptions עם HttpTransportOptions.

אימות אפשרויות התחבורה

כדי לבדוק באיזה סוג של TransportOptions הלקוח משתמש, בודקים את הסוג של אפשרויות התעבורה:

Java

// Compares datastore transport options type

boolean isGRPC = datastore.getOptions().getTransportOptions() instanceof GrpcTransportOptions;

boolean isHTTP = datastore.getOptions().getTransportOptions() instanceof HTTPTransportOptions;

הגדרת מאגר חיבורים

מאגר חיבורים, שנקרא גם מאגר ערוצים, הוא מטמון של חיבורים למסד נתונים שהלקוח משתף ומשתמש בהם מחדש כדי לשפר את זמן האחזור והביצועים של החיבור. כדי לשפר את הביצועים של האפליקציה, צריך להגדיר את מאגר החיבורים.

בקטע הזה מוסבר איך לקבוע את הגודל האופטימלי של מאגר החיבורים, ומוצגות דוגמאות להגדרת הגודל בספריית הלקוח של Java.

קביעת הגודל האופטימלי של מאגר החיבורים

גודל ברירת המחדל של מאגר החיבורים מתאים לרוב האפליקציות, וברוב המקרים אין צורך לשנות אותו. עם זאת, יכול להיות שתרצו לשנות את גודל מאגר החיבורים בגלל תפוקה גבוהה או בקשות שנשמרו בזיכרון הזמני.

כדי להשאיר מקום לתנודות בתעבורה, כדאי שמספר החיבורים במאגר החיבורים יהיה כפול ממספר החיבורים שנדרשים לשימוש מקסימלי. חיבור יכול לטפל במקסימום 100 בקשות בו-זמניות, ולכן מומלץ שיהיו בין 10 ל-50 בקשות בהמתנה לכל חיבור. שכבת הביניים אוכפת את המגבלה של 100 סטרימינג בו-זמני לכל חיבור gRPC, ואי אפשר להגדיר את המגבלה הזו. כדי לחשב את מספר החיבורים האופטימלי במאגר החיבורים באמצעות הערכה של QPS לכל לקוח ומספרי חביון ממוצעים, מבצעים את הפעולות הבאות:

מהמדדים בצד הלקוח, אוספים את הפרטים הבאים ומבצעים את החישובים הבאים:

1. קובעים את המספר המקסימלי של שאילתות לשנייה (QPS) לכל לקוח כשמריצים עומס עבודה באפליקציה.
2. קובעים את זמן האחזור הממוצע (זמן התגובה לבקשה יחידה) באלפיות השנייה.
3. כדי לקבוע את מספר הבקשות שאפשר לשלוח ברצף בכל שנייה, מחלקים את המספר 1,000 בערך של זמן האחזור הממוצע.
4. מחלקים את השאילתות לשנייה בשניות במספר הבקשות הסדרתיות לשנייה.
5. מחלקים את התוצאה ב-50 בקשות לכל ערוץ כדי לקבוע את הגודל המינימלי האופטימלי של מאגר החיבורים. (אם החישוב שלכם נמוך מ-2, בכל מקרה צריך להשתמש לפחות ב-2 ערוצים כדי להבטיח יתירות).
6. מחלקים את אותה התוצאה ב-10 בקשות לכל ערוץ כדי לקבוע את הגודל המקסימלי האופטימלי של מאגר החיבורים.

כדי לבצע את השלבים האלה, משתמשים במשוואות הבאות:

(QPS sec ÷ (1,000 ÷ latency ms)) ÷ 50 streams = Minimum optimal number of
connections

(QPS sec ÷ (1,000 ÷ latency ms)) ÷ 10 streams = Maximum optimal number of
connections

לדוגמה, אם האפליקציה שלכם בדרך כלל שולחת 50,000 בקשות בשנייה, וזמן האחזור הממוצע הוא 10 אלפיות השנייה. מחלקים את 1,000 ב-10 אלפיות השנייה כדי לקבוע שאפשר לשלוח 100 בקשות ברצף בשנייה. מחלקים את המספר הזה ב-50,000 כדי לקבל את רמת המקביליות שנדרשת לשליחת 50,000 QPS: 500.

לכל ערוץ יכולות להיות עד 100 בקשות בו-זמניות, והשימוש בערוץ היעד הוא בין 10 ל-50 סטרימינג בו-זמניים. לכן, כדי לחשב את הגודל המינימלי של מאגר החיבורים, מחלקים את 500 ב-50 ומקבלים 10. כדי למצוא את הגודל המקסימלי של מאגר החיבורים, מחלקים את 500 ב-10 ומקבלים 50.

כלומר, גודל מאגר החיבורים בדוגמה הזו הוא בין 10 ל-50 חיבורים. חשוב גם לעקוב אחרי התנועה אחרי שמבצעים את השינויים האלה, ולשנות את מספר החיבורים במאגר לפי הצורך.

הגדרת גודל המאגר

בדוגמת הקוד הבאה אפשר לראות איך להגדיר את מאגר החיבורים בספריות הלקוח באמצעות DatastoreOptions.

Java

InstantiatingGrpcChannelProvider channelProvider =
        DatastoreSettings.defaultGrpcTransportProviderBuilder()
                .setChannelPoolSettings(
                       ChannelPoolSettings.builder()
                                .setInitialChannelCount(MIN_VAL)
                                .setMaxChannelCount(MAX_VAL)
                                .build())
                .build();

DatastoreOptions options = DatastoreOptions.newBuilder()
         .setProjectId("my-project")
         .setChannelProvider(channelProvider)
         .setTransportOptions(GrpcTransportOptions.newBuilder().build())
         .build();

המאמרים הבאים

מידע נוסף על מאגרי חיבורים ושיטות מומלצות לשיפור הביצועים זמין במאמרים הבאים:

• ChannelPoolSettings
• שיטות מומלצות לשיפור הביצועים