تلميحات حول أداء Azure Cosmos DB Async Java SDK الإصدار 2

ينطبق على: NoSQL

• Java SDK v4
• Async Java SDK v2
• Sync Java SDK الإصدار 2
• NET SDK. الإصدار 3
• .NET SDK v2
• Python SDK

هام

هذا ليس أحدث Java SDK لـ Azure Cosmos DB! يجب ترقية مشروعك إلى Azure Cosmos DB Java SDK v4 ثم قراءة دليل نصائح أداء Azure Cosmos DB Java SDK v4. اتبع الإرشادات الواردة في دليل الترحيل إلى Azure Cosmos DB Java SDK v4 ودليل Reactor vs RxJava للترقية.

تلميحات الأداء الواردة في هذه المقالة خاصة بـAzure Cosmos DB Async Java SDK v2. انظر Azure Cosmos DB Async Java SDK v2 ملحوظات الإصدار، ومستودع Maven، وAzure Cosmos DB Async Java SDK v2 دليل استكشاف الأخطاء وإصلاحها لمزيد من المعلومات.

هام

في 31 أغسطس 2024، سيتم إيقاف إصدار Azure Cosmos DB Async Java SDK v2.x ؛ SDK وجميع التطبيقات التي تستخدم SDK ستستمر في العمل؛ سيتوقف Azure Cosmos DB ببساطة عن توفير مزيد من الصيانة والدعم لحزمة SDK هذه. نوصي باتباع الإرشادات المذكورة أعلاه للترحيل إلى Azure Cosmos DB Java SDK v4.

Azure Cosmos DB هي قاعدة بيانات موزعة سريعة ومرنة تتوسع بسلاسة مع زمن انتقال ومعدل انتقال مضمونين. لا يتعين عليك إجراء تغييرات هيكلية كبيرة، أو كتابة تعليمات برمجية معقدة لتوسيع نطاق قاعدة البيانات باستخدام Azure Cosmos DB. يعد التوسع لأعلى ولأسفل سهلاً مثل إجراء استدعاء واحد لواجهة برمجة التطبيقات أو استدعاء طريقة SDK. ومع ذلك، نظرًا لأنه يتم الوصول إلى Azure Cosmos DB عبر استدعاءات الشبكة فهناك تحسينات من جانب العميل يمكنك إجراؤها لتحقيق أعلى أداء عند استخدام Azure Cosmos DB Async Java SDK v2.

لذلك إذا كنت تسأل «كيف يمكنني تحسين أداء قاعدة البيانات؟» فخذ الخيارات التالية في الاعتبار:

الشبكات

• وضع الاتصال: استخدم الوضع المباشر

  إن كيفية اتصال العميل بـ Azure Cosmos DB لها آثار مهمة على الأداء، لا سيما فيما يتعلق بزمن الانتقال من جانب العميل. يعد ConnectionMode أحد إعدادات التكوين الرئيسية المتاحة لتكوين العميل ConnectionPolicy. بالنسبة إلى Azure Cosmos DB Async Java SDK الإصدار 2، فإن وضعي ConnectionModes المتاحين هما:

  • البوابة (الظاهرية)
  • مباشر

  يتم دعم وضع البوابة على جميع منصات SDK وهو الخيار الذي تم تكوينه افتراضيًّا. إن كانت تطبيقاتك تعمل ضمن شبكة شركة ذات قيود صارمة على جدار الحماية، فإن وضع البوابة هو الخيار الأفضل لأنه يستخدم منفذ HTTPS قياسيًّا ونقطة نهاية واحدة. ومع ذلك، فإن مفاضلة الأداء هي أن وضع البوابة يتضمن قفزة شبكة إضافية في كل مرة تتم فيها قراءة البيانات أو كتابتها إلى Azure Azure Cosmos DB. لهذا السبب، يوفر الوضع المباشر أداءً أفضل نظرًا لحدوث قفزات شبكة أقل.

  يتم تكوين ConnectionMode أثناء إنشاء مثيل DocumentClientباستخدام معلمة ConnectionPolicy.

Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    public ConnectionPolicy getConnectionPolicy() {
        ConnectionPolicy policy = new ConnectionPolicy();
        policy.setConnectionMode(ConnectionMode.Direct);
        policy.setMaxPoolSize(1000);
        return policy;
    }

    ConnectionPolicy connectionPolicy = new ConnectionPolicy();
    DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);

• ترتيب العملاء في نفس منطقة Azure للأداء

  عندما يكون ذلك ممكنا، ضع أي تطبيقات تستدعي Azure Cosmos DB في نفس المنطقة مثل قاعدة بيانات Azure Cosmos DB. لإجراء مقارنة تقريبية، تكتمل المكالمات إلى Azure Cosmos DB داخل نفس المنطقة في غضون 1-2 مللي ثانية، لكن وقت الاستجابة بين الساحلَين الغربي والشرقي للولايات المتحدة يبلغ >50 مللي ثانية. من المحتمل أن يختلف ومن الانتقال هذا من طلب إلى آخر، اعتمادًا على المسار الذي يسلكه الطلب، حيث ينتقل من العميل إلى حد مركز بيانات Azure. يتم تحقيق أقل زمن انتقال ممكن عن طريق التأكد من أن تطبيق الاستدعاء يقع داخل منطقة Azure نفسها كنقطة نهاية Azure Cosmos DB المتوافرة. للحصول على قائمة بالمناطق المتوافرة، راجع مناطق Azure.

  

استخدام SDK

• تثبيت أحدث إصدار من SDK

  يتم تحسين حزم Azure Cosmos DB SDK باستمرار لتوفير أفضل أداء. راجع صفحات Azure Cosmos DB Async Java SDK v2 ملاحظات الإصدار لتحديد أحدث SDK ومراجعة التحسينات.

• استخدم عميل قاعدة بيانات أحادية Azure Cosmos DB طوال عمر تطبيقك

  كل مثيل AsyncDocumentClient آمن لمؤشر الترابط ويقوم بإدارة اتصال فعالة والتخزين المؤقت للعنوان. للسماح بإدارة اتصال فعالة وأداء أفضل بواسطة AsyncDocumentClient، يوصى باستخدام مثيل واحد من AsyncDocumentClient لكل AppDomain طوال فترة تشغيل التطبيق.

• ضبط نهج الاتصال

  بشكل افتراضي، يتم إجراء طلبات Azure Cosmos DB الوضع المباشر عبر TCP عند استخدام Azure Cosmos DB Async Java SDK v2. داخليًّا، تستخدم SDK بنية وضع مباشر خاصة لإدارة موارد الشبكة ديناميكيًّا والحصول على أفضل أداء.

  في Azure Cosmos DB Async Java SDK v2، يعد الوضع المباشر هو الخيار الأفضل لتحسين أداء قاعدة البيانات مع معظم أحمال العمل.

  • نظرة عامة على الوضع المباشر

  

  تتيح بنية جانب العميل المستخدمة في الوضع المباشر الاستخدام المتوقع للشبكة والوصول المتعدد إلى النسخ المتماثلة لـAzure Cosmos DB. يوضح الرسم التخطيطي أعلاه كيفية توجيه الوضع المباشر لطلبات العميل إلى النسخ المتماثلة في الواجهة الخلفية ل Azure Cosmos DB. تخصص بنية الوضع المباشر ما يصل إلى 10 قنوات على جانب العميل لكل نسخة متماثلة من DB. القناة هي اتصال TCP يسبقه مخزن مؤقت للطلب، والذي يبلغ عمقه 30 طلبًا. يتم تخصيص القنوات التي تخص النسخة المتماثلة ديناميكيًّا حسب الحاجة بواسطة نقطة نهاية الخدمة للنسخة المماثلة. عندما يُصدر المستخدم طلبًا في الوضع المباشر، يوجه TransportClient الطلب إلى نقطة نهاية الخدمة المناسبة بناءً على مفتاح القسم. تخزن قائمة الطلبات الطلبات قبل نقطة نهاية الخدمة.

  • خيارات تكوين ConnectionPolicy للوضع المباشر

    كخطوة أولى، استخدم إعدادات التكوين الموصى بها أدناه. اتصل بفريق Azure Cosmos DB إذا واجهت مشكلات في هذا الموضوع المحدد.

    إذا كنت تستخدم Azure Cosmos DB كقاعدة بيانات مرجعية (أي، يتم استخدام قاعدة البيانات للعديد من عمليات قراءة النقاط وعدد قليل من عمليات الكتابة)، فقد يكون من المقبول تعيين idleEndpointTimeout على 0 (أي، بدون مهلة).

    خيار التكوين	الإعداد الافتراضي
    bufferPageSize	8192
    connectionTimeout	"PT1M"
    idleChannelTimeout	"PT0S"
    idleEndpointTimeout	"PT1M10S"
    maxBufferCapacity	8388608
    maxChannelsPerEndpoint	10
    maxRequestsPerChannel	30
    receiveHangDetectionTime	"PT1M5S"
    requestExpiryInterval	"PT5S"
    requestTimeout	"PT1M"
    requestTimerResolution	"PT0.5S"
    sendHangDetectionTime	"PT10S"
    shutdownTimeout	"PT15S"

• تلميحات حول البرمجة للوضع المباشر

  راجع مقالة استكشاف الأخطاء وإصلاحها في Azure Cosmos DB Async Java SDK v2 كأساس لحل أي مشاكل في SDK.

  بعض نصائح البرمجة المهمة عند استخدام الوضع المباشر:

  • استخدم تعدد مؤشرات الترابط في تطبيقك لنقل بيانات TCP الفعال - بعد تقديم طلب، يجب أن يشترك تطبيقك لتلقي البيانات في سلسلة رسائل أخرى. عدم القيام بذلك يفرض عملية «أحادي الاتجاه» غير مقصودة ويتم حظر الطلبات اللاحقة في انتظار رد الطلب السابق.

  • نفّذ أحمال عمل كثيفة الحساب على مؤشرات ترابط مخصصة - لأسباب مماثلة للنصيحة السابقة، من الأفضل وضع العمليات مثل معالجة البيانات المعقدة في مؤشر ترابط منفصل. قد يواجه الطلب الذي يسحب البيانات من مخزن بيانات آخر (على سبيل المثال إذا كان مؤشر الترابط يستخدم Azure Cosmos DB ومخازن بيانات Spark في وقت واحد) زيادة في زمن الانتقال ويوصى بإنشاء مؤشر ترابط إضافي ينتظر استجابة من مخزن البيانات الآخر.

    • تتم إدارة IO الشبكة الأساسية في Azure Cosmos DB Async Java SDK v2 بواسطة Netty. راجع هذه التلميحات لتجنب أنماط الترميز التي تحظر مؤشرات ترابط Netty IO.

  • نمذجة البيانات - تفترض اتفاقية مستوى الخدمة في Azure Cosmos DB أن حجم المستند أقل من 1 كيلوبايت. سيؤدي تحسين نموذج البيانات والبرمجة لتفضيل حجم مستند أصغر بشكل عام إلى تقليل زمن الانتقال. إذا كنت ستحتاج إلى تخزين واسترداد مستندات أكبر من 1 كيلوبايت، فإن النهج الموصى به هو ربط المستندات بالبيانات في Azure Blob Storage.

• ضبط الاستعلامات المتوازية للمجموعات المقسَّمة

  يدعم Azure Cosmos DB Async Java SDK الإصدار 2 الاستعلامات المتوازية، والتي تمكنك من الاستعلام عن مجموعة مقسمة بالتوازي. لمزيد من المعلومات، راجع نماذج التعليمات البرمجية المتعلقة بالعمل مع SDKs. تم تصميم الاستعلامات الموازية لتحسين زمن انتقال الاستعلام وإنتاجيته على نظيرتها التسلسلية.

  • ضبط setMaxDegreeOfParallelism:

    تعمل الاستعلامات المتوازية عن طريق الاستعلام عن أقسام متعددة بالتوازي. ومع ذلك، يتم جلب البيانات من مجموعة مقسَّمة فردية بشكل تسلسلي فيما يتعلق بالاستعلام. لذلك، استخدم setMaxDegreeOfParallelism لتعيين عدد الأقسام التي لديها أقصى فرصة لتحقيق الاستعلام الأكثر أداءً، بشرط أن تظل جميع شروط النظام الأخرى كما هي. إذا كنت لا تعرف عدد الأقسام، يمكنك استخدام setMaxDegreeOfParallelism لتعيين رقم كبير، ويختار النظام الحد الأدنى (عدد الأقسام، المدخلات المقدمة من المستخدم) كأقصى درجة للتوازي.

    من المهم ملاحظة أن الاستعلامات المتوازية تنتج أفضل الفوائد إذا تم توزيع البيانات بالتساوي عبر جميع الأقسام فيما يتعلق بالاستعلام. إذا تم تقسيم المجموعة المقسمة بطريقة تركز كل أو معظم البيانات التي تم إرجاعها بواسطة استعلام في بعض الأقسام (قسم واحد في أسوأ الحالات)، ازدحام أداء الاستعلام بواسطة هذه الأقسام.

  • ضبط setMaxBufferedItemCount

    تم تصميم الاستعلام المتوازي لإحضار النتائج مسبقا أثناء معالجة الدفعة الحالية من النتائج من قبل العميل. يساعد الإحضار المسبق في تحسين زمن الانتقال الكلي للاستعلام. يحدد setMaxBufferedItemCount عدد النتائج التي تم إحضارها مسبقا. يؤدي تعيين setMaxBufferedItemCount إلى العدد المتوقع من النتائج التي تم إرجاعها (أو رقم أعلى) إلى تمكين الاستعلام من الحصول على أقصى فائدة من الإحضار المسبق.

    يعمل الإحضار المسبق بنفس الطريقة بغض النظر عن MaxDegreeOfParallelism، وهناك مخزن مؤقت واحد للبيانات من جميع الأقسام.

• تنفيذ التراجع في الفواصل الزمنية getRetryAfterInMilliseconds

  أثناء اختبار الأداء، يجب عليك زيادة الحمل حتى يتم اختناق معدل صغير من الطلبات. إذا تم التحكم في السرعة، يجب أن يتراجع تطبيق العميل عن الفاصل الزمني لإعادة المحاولة المحدد من قبل الخادم. يضمن احترام التراجع قضاء أقل قدر من الوقت في الانتظار بين عمليات إعادة المحاولة.

• توسيع نطاق عبء عمل العميل

  إذا كنت تختبر بمستويات معدل نقل عالية (>50000 وحدة طلب/ثانية)، فقد يصبح تطبيق العميل مزدحماً بسبب تقييد الجهاز لاستخدام وحدة المعالجة المركزية أو الشبكة. إذا وصلت إلى هذه النقطة، يمكنك الاستمرار في دفع حساب Azure Cosmos DB بشكل أكبر عن طريق توسيع نطاق تطبيقات العميل عبر خوادم متعددة.

• استخدم العنونة المستندة إلى الاسم

  استخدم العنونة المستندة إلى الاسم، حيث تكون الروابط بالتنسيق dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId، بدلًا من SelfLinks (_self)، التي لها التنسيق dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> لتجنب استرداد ResourceIds لجميع الموارد المستخدمة لإنشاء الرابط. أيضاً، نظراً لإعادة إنشاء هذه الموارد (ربما بالاسم نفسه)، فقد لا يساعد تخزينها مؤقتاً.

• ضبط حجم الصفحة للاستعلامات / قراءة الخلاصات للحصول على أداء أفضل

  عند إجراء قراءة مجمعة للمستندات باستخدام وظيفة موجز القراءة (على سبيل المثال، readDocuments) أو عند إصدار استعلام SQL، يتم إرجاع النتائج بطريقة مجزأة إذا كانت مجموعة النتائج كبيرة جداً. بشكل ظاهري يتم إرجاع النتائج في أجزاء من 100 عنصر أو 1 ميغابايت، أيهما يتم الوصول إليه أولاً.

  لتقليل عدد الرحلات ذهابًا وإيابًا عبر الشبكة المطلوبة لاسترداد جميع النتائج القابلة للتطبيق، يمكنك زيادة حجم الصفحة باستخدام عنوان الطلب x-ms-max-item-count حتى 1000. في الحالات التي تحتاج فيها إلى عرض قليل من النتائج فقط، على سبيل المثال، إذا كانت واجهة المستخدم، أو واجهة برمجة التطبيقات الخاصة بالتطبيق تعرض 10 نتائج فقط في كل مرة، يمكنك أيضاً تقليل حجم الصفحة إلى 10؛ لتقليل معدل النقل المستهلك للقراءات والاستعلامات.

  يمكنك أيضًا ضبط حجم الصفحة باستخدام طريقة setMaxItemCount.

• استخدام برنامج الجدولة المناسب (تجنب سرقة سلاسل الأحداث IO Netty ذات حلقة الأحداث)

  يستخدم Azure Cosmos DB Async Java SDK v2 netty لعدم حظر الإدخال/الإخراج. يستخدم SDK عددًا ثابتًا من مؤشرات ترابط حلقة أحداث IO netty (مثل كثير من نوى CPU التي يمتلكها جهازك) لتنفيذ عمليات IO. يرسل المرصد الذي تم إرجاعه بواسطة API النتيجة على أحد مؤشرات ترابط netty لحلقة أحداث IO المشتركة. لذلك من المهم عدم حظر مؤشرات ترابط netty حلقة أحداث IO المشتركة. قد يؤدي القيام بعمل مكثف لـCPU أو عملية حظر على مؤشر ترابط netty لحلقة حدث IO إلى توقف تام أو تقليل معدل نقل SDK بشكل كبير.

  على سبيل المثال، تنفذ الكود التالي عملاً مكثفاً لوحدة المعالجة المركزية على سلسلة أحداث حلقة IO الصغيرة:

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument(
      collectionLink, document, null, true);
  
    createDocObs.subscribe(
      resourceResponse -> {
        //this is executed on eventloop IO netty thread.
        //the eventloop thread is shared and is meant to return back quickly.
        //
        // DON'T do this on eventloop IO netty thread.
        veryCpuIntensiveWork();
      });
  

  بعد تسلُّم النتيجة إذا كنت تريد القيام بعمل مكثف لوحدة المعالجة المركزية على النتيجة، يجب عليك تجنب القيام بذلك في حلقة الحدث IO الخيط الصغير. يمكنك بدلاً من ذلك توفير برنامج الجدولة الخاص بك لتوفير سلسلة المحادثات الخاصة بك لتشغيل عملك.

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    import rx.schedulers;
  
    Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument(
      collectionLink, document, null, true);
  
    createDocObs.subscribeOn(Schedulers.computation())
    subscribe(
      resourceResponse -> {
        // this is executed on threads provided by Scheduler.computation()
        // Schedulers.computation() should be used only when:
        //   1. The work is cpu intensive 
        //   2. You are not doing blocking IO, thread sleep, etc. in this thread against other resources.
        veryCpuIntensiveWork();
      });
  

  استنادا إلى نوع عملك، يجب عليك استخدام RxJava Scheduler المناسب لعملك. اقرأ هنا Schedulers.

  لمزيد من المعلومات، يرجى إلقاء نظرة على صفحة GitHub الخاصة بـAzure Cosmos DB Async Java SDK v2.

• تعطيل تسجيل netty

  يعد تسجيل مكتبة Netty أمراً شاذًّا ويجب إيقاف تشغيله (قد لا يكون منع تسجيل الدخول في التكوين كافيًا) لتجنب تكاليف CPU الإضافية. إذا لم تكن في وضع التصحيح، فقم بتعطيل تسجيل netty تماماً. لذلك إذا كنت تستخدم log4j لإزالة تكاليف CPU الإضافية التي تكبدتها org.apache.log4j.Category.callAppenders() من netty فأضف السطر التالي إلى قاعدة التعليمات البرمجية الخاصة بك:

  org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);
  

• حد موارد ملفات فتح OS

  تحتوي بعض أنظمة Linux (مثل Red Hat) على حد أعلى لعدد الملفات المفتوحة وبالتالي إجمالي عدد الاتصالات. شغل ما يلي لعرض الحدود الحالية:

  ulimit -a
  

  يجب أن يكون عدد الملفات المفتوحة (nofile) كبيرًا بما يكفي لتوفير مساحة كافية لحجم تجمع الاتصال الذي تم تكوينه والملفات المفتوحة الأخرى بواسطة OS. يمكن تعديله للسماح بحجم أكبر لتجمع الاتصال.

  افتح ملف limits.conf:

  vim /etc/security/limits.conf
  

  قم بإضافة / تعديل الأسطر التالية:

  * - nofile 100000
  

نهج الفهرسة

• استبعاد المسارات غير المستخدمة من الفهرسة لعمليات كتابة أسرع

  يسمح لك نهج الفهرسة في Azure Cosmos DB بتحديد مسارات المستندات التي يجب تضمينها أو استبعادها من الفهرسة باستخدام مسارات الفهرسة (setIncludedPaths و setExcludedPaths). يمكن أن يوفر استخدام مسارات الفهرسة أداء كتابة محسناً وتخزين فهرس أقل للسيناريوهات التي تُعرف فيها أنماط الاستعلام سابقاً، حيث ترتبط تكاليف الفهرسة ارتباطاً مباشراً بعدد المسارات الفريدة المفهرسة. على سبيل المثال، يوضح الكود التالي كيفية استبعاد قسم كامل من المستندات (يُعرف أيضًا باسم الشجرة الفرعية) من الفهرسة باستخدام حرف البدل "*".

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

  Index numberIndex = Index.Range(DataType.Number);
  numberIndex.set("precision", -1);
  indexes.add(numberIndex);
  includedPath.setIndexes(indexes);
  includedPaths.add(includedPath);
  indexingPolicy.setIncludedPaths(includedPaths);
  collectionDefinition.setIndexingPolicy(indexingPolicy);
  

  للحصول على مزيد من المعلومات، راجع خدمة Azure Cosmos DB: نهج الفهرسة.

الإنتاجية

• قياس وضبط وحدات الطلب الأقل / الاستخدام الثاني

  يوفر Azure Cosmos DB مجموعة غنية من عمليات قاعدة البيانات بما في ذلك الاستعلامات العلائقية والتسلسلية باستخدام UDFs، والإجراءات المخزنة، والمشغلات - تعمل جميعها على المستندات ضمن مجموعة قاعدة بيانات. تختلف التكلفة المقترنة بكل من هذه العمليات استناداً إلى وحدة المعالجة المركزية، والمدخلات/ المخرجات، والذاكرة المطلوبة لإكمال العملية. بدلًا من التفكير في موارد الأجهزة وإدارتها، يمكنك التفكير في وحدة الطلب (RU) كمقياس واحد للموارد المطلوبة لإجراء عمليات قاعدة بيانات متنوعة وخدمة طلب تطبيق.

  يتم توفير معدل النقل بناءً على عدد وحدات الطلب التي تم تعيينها لكل حاوية. يتم تقييم استهلاك وحدة الطلب كمعدل في الثانية. التطبيقات التي تتجاوز معدل وحدة الطلب المخصص لحاوياتها تكون محدودة حتى ينخفض ​​المعدل إلى ما دون المستوى المخصص للحاوية. إذا كان تطبيقك يتطلب مستوى معدل نقل أعلى، يمكنك زيادة معدل نقلك من خلال توفير وحدات طلب إضافية.

  يؤثر تعقيد الاستعلام على عدد وحدات الطلب التي يتم استهلاكها لعمليةٍ ما. عدد الدالات وطبيعتها وعدد دالات UDF وحجم مجموعة بيانات المصدر جميعها عوامل تؤثر على تكلفة عمليات الاستعلام.

  لقياس النفقات العامة لأي عملية (إنشاء أو تحديث أو حذف)، افحص عنوان x-ms-request-charge لقياس عدد وحدات الطلب التي تستهلكها هذه العمليات. يمكنك أيضًا الاطلاع على خاصية RequestCharge المكافئة في ResourceResponse<T> أو FeedResponse<T>.

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

  ResourceResponse<Document> response = asyncClient.createDocument(collectionLink, documentDefinition, null,
                                                   false).toBlocking.single();
  response.getRequestCharge();
  

  تُعد رسوم الطلب التي تم إرجاعها في هذا العنوان جزءًا صغيرًا من معدل النقل المقدم. على سبيل المثال، إذا كان لديك 2000 RU/s تم توفيرها، وإذا كان الاستعلام السابق يرجع 1000 مستند 1 كيلوبايت، فإن تكلفة العملية هي 1000. على هذا النحو، في غضون ثانية واحدة، ينفذ الخادم طلبَيْن فقط من هذا القبيل قبل أن يحد المعدل الطلبات اللاحقة. لمزيد من المعلومات، راجع وحدات الطلب وحاسبة وحدات الطلب.

• تقييد معدل المعالجة/معدل الطلب كبير جدًّا

  عند محاولة عميل تجاوز معدل النقل المحجوز لأحد الحسابات، فلا يكون هناك انخفاض في الأداء في الخادم ولا استخدام لسعة معدل نقل يتجاوز المستوى المحجوز. سينهي الخادم الطلب بشكل استباقي باستخدام RequestRateTooLarge (رمز حالة HTTP 429) ويعيد عنوان x-ms-retry-after-ms الذي يشير إلى مقدار الوقت، بالمللي ثانية، الذي يجب على المستخدم انتظاره قبل إعادة محاولة الطلب.

  HTTP Status 429,
  Status Line: RequestRateTooLarge
  x-ms-retry-after-ms :100
  

  تلتقط جميع حزم SDK هذه الاستجابة ضمنياً، وتحترم عنواناً بعد إعادة المحاولة المحدد من الخادم، ثم تعيد محاولة الطلب. ما لم يتم الوصول إلى حسابك بشكل متزامن من قبل عدة عملاء، فستنجح المحاولة التالية.

  إذا كان لديك أكثر من عميل واحد يعمل بشكل تراكمي بشكل متسق زيادة على معدل الطلب، فقد لا يكفي عدد مرات إعادة المحاولة الافتراضي المعين حاليًّا على 9 داخليًّا بواسطة العميل؛ في هذه الحالة، يرمي العميل DocumentClientException مع رمز الحالة 429 إلى التطبيق. يمكن تغيير عدد مرات إعادة المحاولة الافتراضي باستخدام setRetryOptions في مثيل ConnectionPolicy. بشكل ظاهري يتم إرجاع DocumentClientException برمز الحالة 429 بعد وقت انتظار تراكمي قدره 30 ثانية، إذا استمر الطلب في العمل فوق معدل الطلب. يحدث هذا حتى عندما يكون عدد عمليات إعادة المحاولة الحالية أقل من الحد الأقصى لعدد مرات إعادة المحاولة، سواء كانت القيمة الظاهرية 9 أو قيمة معرَّفة من قِبَل المستخدم.

  في حين أن سلوك إعادة المحاولة الآلي يساعد على تحسين المرونة وسهولة الاستخدام لمعظم التطبيقات، إلا أنه قد يتعارض عند القيام بمعايير الأداء، خاصة عند قياس معدل الانتقال. سوف يرتفع وقت الانتقال الذي يَلْحَظه العميل إذا وصلت التجربة إلى تقييد الخادم وتسببت في إعادة محاولة SDK للعميل بصمت. لتجنب ارتفاع وقت الانتقال أثناء تجارب الأداء، قم بقياس الرسوم التي يتم إرجاعها بواسطة كل عملية وتأكد من أن الطلبات تعمل بأقل من معدل الطلب المحجوز. لمزيد من المعلومات، راجع وحدات الطلب.

• تصميم مستندات أصغر حجمًا للحصول على معدل نقل أعلى

  ترتبط رسوم الطلب (تكلفة معالجة الطلب) لعملية معينة ارتباطا مباشرا بحجم المستند. تكلف العمليات على المستندات الكبيرة أكثر من عمليات المستندات الصغيرة.

الخطوات التالية

لمعرفة مزيد حول تصميم تطبيقك بحيث يتناسب مع الحجم والأداء العالي، راجع التقسيم والقياس في Azure Cosmos DB.