نصائح الأداء ل Azure Cosmos DB Async Java SDK v2

• Java SDK v4
• Async Java SDK v2
• Sync Java SDK الإصدار 2
• NET SDK. الإصدار 3
• .NET SDK v2
• حزمة تطوير التطوير الخاصة لبايثون

مهم

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

نصائح الأداء في هذا المقال مخصصة فقط لإصدار Azure Cosmos DB Async Java SDK v2. انظر دليل حلول حلول Azure Cosmos DB Async Java SDK v2 Release,Maven repository, and Azure Cosmos DB Async Java SDK v2 لحل الأخطاء لمزيد من المعلومات.

مهم

في 31 أغسطس 2024، سيتم إيقاف Azure Cosmos DB Async Java SDK v2.x؛ ستستمر مجموعة تطوير التطوير وجميع التطبيقات التي تستخدم الحزمة في العمل؛ سيتوقف 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.

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

Networking

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

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

  • بوابة (افتراضية)
  • مباشر

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

  يتم تكوين وضع الاتصال أثناء بناء مثيل 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 لتحديد أحدث مجموعة تطوير البرمجيات ومراجعة التحسينات.

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

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

• سياسة اتصال الضبط

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

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

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

  

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

  • خيارات تكوين سياسة الاتصال للوضع المباشر

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

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

    خيار التكوين	Default
    حجم الصفحة المؤقت	8192
    connectionTimeout	"PT1M"
    idleChannelTimeout	"PT0S"
    idleEndpointTimeout	"PT1M10S"
    maxBufferCapacity	8388608
    maxChannelsPerEndpoint	10
    maxRequestsPerChannel	30
    receiveHangDetectionTime	"PT1M5S"
    requestExpiryInterval	"PT5S"
    requestTimeout	"PT1M"
    requestTimerResolution	"PT0.5S"
    sendHangDetectionTime	"PT10S"
    إيقاف وقت الإيقاف	"PT15S"

• نصائح البرمجة لوضع Direct

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

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

  • استخدم تعدد الخيوط في تطبيقك لنقل بيانات TCP فعال - بعد تقديم طلب، يجب أن يشترك تطبيقك لاستقبال البيانات في خيط آخر. عدم القيام بذلك يجبر على تشغيل "نصف مزدوج" غير مقصود ويتم حظر الطلبات اللاحقة في انتظار رد الطلب السابق.

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

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

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

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

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

  • مجموعة الضبط MaxDegreeOfParallelism:

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

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

  • مجموعة التعديل: MaxBufferedItemCount:

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

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

• تنفيذ backoff عند فترات getRetryAfterInMilliseconds

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

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

  إذا كنت تختبر بمستويات إنتاجية عالية (>50,000 RU/s)، فقد يصبح تطبيق العميل هو عنق الزجاجة بسبب انتهاء استخدام الجهاز للمعالج أو الشبكة. إذا وصلت إلى هذه النقطة، يمكنك الاستمرار في دفع حساب 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 المشتركة. القيام بعمل مكثف من وحدة المعالجة المركزية أو حجب عملية الحظر على حلقة أحداث الإدخال الداخلي (NTI) قد يسبب تثبيتا أو يقلل بشكل كبير من معدل نقل SDK.

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

  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 أو Netty Thread. يمكنك بدلا من ذلك توفير جدولة خاصة بك لتوفير خيوط خاصة بك لتشغيل عملك.

  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 المناسبة لعملك. اقرأ هنا Schedulers.

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

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

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

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

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

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

  ulimit -a
  

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

  افتح ملف 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 الخاص ب ConnectionPolicy. افتراضيا، يتم إرجاع DocumentClientException مع رمز الحالة 429 بعد فترة انتظار تراكمية قدرها 30 ثانية إذا استمر الطلب في العمل فوق معدل الطلب. يحدث هذا حتى عندما يكون عدد عمليات إعادة المحاولة الحالية أقل من الحد الأقصى لعدد مرات إعادة المحاولة، سواء كانت القيمة الظاهرية 9 أو قيمة معرَّفة من قِبَل المستخدم.

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

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

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

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

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