قائمة مراجعة الأداء وقابلية التوسع لتخزين قائمة الانتظار

طورت Microsoft العديد من الممارسات المثبتة لتطوير تطبيقات عالية الأداء باستخدام Queue Storage. تحدد قائمة التحقق هذه الممارسات الرئيسية التي يمكن للمطورين اتباعها لتحسين الأداء. ضع هذه الممارسات في الاعتبار أثناء تصميم التطبيق الخاص بك وطوال العملية.

يحتوي Azure Storage على أهداف قابلية التوسع والأداء للسعة ومعدل الحركة والنطاق الترددي. لمزيد من المعلومات حول أهداف قابلية التوسع في Microsoft Azure Storage، قم بمراجعة أهداف قابلية التوسع والأداء لحسابات التخزين القياسية وقابلية التوسع وأهداف الأداء لتخزين قائمة الانتظار .

قائمة الاختيار

تنظم هذه المقالة الممارسات المثبتة للأداء في قائمة تحقق يمكنك اتباعها أثناء تطوير تطبيق تخزين قائمة الانتظار.

أهداف قابلية التوسع

إذا اقترب تطبيقك من أي من أهداف قابلية التوسع أو تجاوزها، فقد يواجه زيادة في زمن انتقال المعاملات أو تقييدها. عندما يخنق Microsoft Azure Storage تطبيقك، تبدأ الخدمة في إرجاع رموز الخطأ 503 (Server Busy) أو 500 (Operation Timeout). يمثل تجنب هذه الأخطاء بالتواجد ضمن حدود أهداف قابلية التوسع جزءًا مهمًا من تحسين أداء التطبيق لديك.

لمزيد من المعلومات حول أهداف قابلية التوسع للتخزين في قائمة الانتظار، راجع أهداف قابلية التخزين والأداء في Azure Storage.

أقصى عدد لحسابات التخزين

إذا كنت تقترب من أقصى عدد لحسابات التخزين المسموح بها لاشتراك محدد/مجموعة مناطق، هل تستخدم حسابات تخزين متعددة على علبة بريد مقطعية لزيادة الدخول أو الخروج أو عمليات الإدخال/الإخراج في الثانية (IOPS) أو السعة؟ في هذا السيناريو، توصي Microsoft بالاستفادة من زيادة حدود حسابات التخزين لتقليل عدد حسابات التخزين اللازمة لحمل العمل الخاص بك إذا أمكن. اتصل ِAzure Support لطلب زيادة حدود حساب التخزين لديك.

أهداف السعة والحركة

في حال كان التطبيق لديك يقترب من أهداف قابلية التوسع لحساب تخزين واحد، فحاول استخدام أحد النهج التالية:

• إذا كانت أهداف قابلية التوسع لقوائم الانتظار غير كافية لتطبيقك، فقم باستخدام قوائم انتظار متعددة ووزع الرسائل عبرها.
• قم بإعادة النظر في حجم العمل الذي يتسبب في اقتراب تطبيقك من هدف قابلية التوسع أو تجاوزه. هل يمكنك تصميمه بشكل مختلف لتقليل استخدام النطاق الترددي أو السعة، أو حركات أقل؟
• في حال كان يجب أن يتجاوز التطبيق الخاص بك أحد أهداف قابلية التوسع، فيُرجى إنشاء حسابات تخزين متعددة وتقسيم بيانات التطبيق لديك عبر حسابات التخزين المتعددة هذه. في حال كنت تستخدم هذا النمط، فتأكد من تصميم التطبيق الخاص بك حيث يمكنك إضافة المزيد من حسابات التخزين في المستقبل لموازنة التحميل. ليس لحسابات التخزين نفسها أي تكلفة غير استخدامك فيما يتعلق بالبيانات المخزنة أو الحركات المنفذة أو البيانات المنقولة.
• في حال كان التطبيق يقترب من أهداف النطاق الترددي، فحاول ضغط البيانات من جانب العميل لتقليل النطاق الترددي اللازم لإرسال البيانات إلى Azure Storage. بينما قد يؤدي ضغط البيانات إلى حفظ النطاق الترددي وتحسين أداء الشبكة، يمكن أن يكون له أيضا تأثيرات سلبية على الأداء. قيم تأثير أداء متطلبات المعالجة الإضافية لضغط البيانات وفك الضغط من جانب العميل. ضع في اعتبارك أن تخزين البيانات المضغوطة يمكن أن يجعل استكشاف الأخطاء وإصلاحها أكثر صعوبة لأنه قد يكون من الصعب عرض البيانات باستخدام الأدوات القياسية.
• إذا كان تطبيقك يقترب من أهداف قابلية التوسع، فتأكد من استخدام تراجع أسي لإعادة المحاولة. من الأفضل محاولة تجنب الوصول إلى أهداف قابلية التوسع بتنفيذ التوصيات الموضحة في هذه المقالة. ومع ذلك، فإن استخدام التراجع الأسي لإعادة المحاولة يمنع التطبيق الخاص بك من إعادة المحاولة بسرعة، مما قد يجعل التقييد أسوأ. للمزيد من المعلومات، راجع Timeout and Server Busy errors section.

الشبكات

قد يكون لقيود الشبكة الفعلية للتطبيق تأثير كبير على الأداء. تصف الأقسام التالية بعض القيود التي قد يواجهها المستخدمون.

إمكانيات شبكة العميل

يؤدي النطاق الترددي وجودة ارتباط الشبكة أدوارًا مهمة في أداء التطبيق، كما هو موضح في المقاطع التالية.

الإنتاجية

فيما يتعلق بالنطاق الترددي، تكون المشكلة غالبًا إمكانيات العميل. تحتوي مثيلات Microsoft Azure الأكبر على بطاقات NIC ذات سعة أكبر، لذا يجب أن تفكر في استخدام مثيل أكبر أو عدد أكبر من الأجهزة الظاهرية إذا كنت بحاجة إلى حدود شبكة أعلى من جهاز واحد. إذا كنت تقوم بالوصول إلى Azure Storage من تطبيق محلي، فإن نفس القاعدة تنطبق: فهم قدرات الشبكة لجهاز العميل واتصال الشبكة بموقع Azure Storage وإما تحسينها حسب الحاجة أو تصميم التطبيق الخاص بك للعمل ضمن قدراتها.

جودة الارتباط

كما هو الحال مع أي استخدام للشبكة، ضع في اعتبارك أن ظروف الشبكة التي تؤدي إلى أخطاء وفقدان الحزمة تبطئ معدل النقل الفعال. قد يساعد استخدام Wireshark أو Network Monitor في تشخيص هذه المشكلة.

Location

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

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

توقيعات الوصول المشتركة ومشاركة الموارد عبر المصادر

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

يمكنك تجنب استخدام تطبيق الخدمة كوكيل لـAzure Storage باستخدام توقيعات الوصول المشتركة (SAS). باستخدام SAS، يمكنك تمكين جهاز المستخدم الخاص بك لتقديم طلبات مباشرة إلى Microsoft Azure Storage باستخدام رمز وصول محدود. على سبيل المثال، إذا أراد المستخدم تحميل صورة إلى التطبيق الخاص بك، فيمكن لتطبيق الخدمة الخاص بك إنشاء SAS وإرساله إلى جهاز المستخدم. يمكن أن يمنح رمز SAS الإذن بالكتابة إلى مورد Microsoft Azure Storage لفترة زمنية محددة، تنتهي بعدها صلاحية رمز SAS المميز. لمزيد من المعلومات حول SAS، يُرجى الرجوع إلى الوصول المحدود إلىAzure Storage resources باستخدام رموز (SAS).

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

على سبيل المثال، افترض أن تطبيق ويب قيد التشغيل في Azure يطلب مصدرًا لحساب في Azure Storage. تطبيق الويب هو مجال المصدر، وحساب التخزين هو مجال الهدف. يمكنك تكوين CORS لأي من خدمات Azure Storage للاتصال بمستعرض الويب الذي يطلب من مجال المصدر أنها موثوقة باستخدام Azure Storage. للحصول على مزيد من المعلومات عن مشاركة الموارد عبر المصادر CORS، راجع دعم مشاركة الموارد عبر المصادر (CORS) في Azure Storage.

يمكن أن يساعدك كل من SAS وCORS في تجنب التحميل غير الضروري على تطبيق الويب الخاص بك.

تكوين NET

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

رفع حد الاتصال الافتراضي

بالنسبة للمشاريع التي تستخدم .NET Framework، يمكنك استخدام التعليمات البرمجية التالية لزيادة حد الاتصال الافتراضي (وهو عادة 2 في بيئة عميل أو 10 في بيئة خادم) إلى 100. بشكل متطابق، يجب تعيين القيمة إلى عدد مؤشرات الترابط المستخدمة من قِبل التطبيق الخاص بك تقريبًا. عين حد الاتصال قبل فتح أي اتصالات.

ServicePointManager.DefaultConnectionLimit = 100; //(Or More)  

لمعرفة المزيد حول حدود تجمع الاتصال في .NET Framework، راجع حدود تجمع .NET Framework الاتصال ion وAzure SDK الجديد ل .NET.

للاطلاع على لغات البرمجة الأخرى، راجع الوثائق لتحديد كيفية تعيين حد الاتصال.

رفع الحد الأدنى لعدد مؤشرات الترابط

إذا كنت تستخدم استدعاءات متزامنة مع مهام غير متزامنة، فقد تحتاج إلى زيادة عدد مؤشرات الترابط في تجمع مؤشر الترابط:

ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)  

للحصول على مزيد من المعلومات، راجع أسلوب ThreadPool.SetMinThreads.

التوازي غير المحدود

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

مكتبات وأدوات العميل

للحصول على أفضل أداء، استخدم دائمًا أحدث مكتبات وأدوات العميل التي تقدمها Microsoft. تتوفر مكتبات عميل Azure Storage بلغات مختلفة. يدعم Azure Storage أيضًا PowerShell وAzure CLI. تهتم Microsoft بشكل نشط بتطوير مكتبات العميل وأدواته مع وضع الأداء في الاعتبار، وتواصل تحديثها بأحدث إصدارات الخدمة، وتضمن معالجتها للعديد من ممارسات الأداء المثبتة داخليًا. لمزيد من المعلومات، قم بمراجعة Azure Storage reference documentation.

تعامل مع أخطاء الخدمة

يقوم Azure Storage بإرجاع خطأ عندما لا تتمكن الخدمة من معالجة طلب. يعد فهم الأخطاء التي قد يتم إرجاعها بواسطة Azure Storage في سيناريو معين مفيدا لتحسين الأداء.

أخطاء انتهاء المهلة والخادم مشغول

قد يقيد Azure Storage تطبيقك إذا اقترب من حدود قابلية التوسع. في بعض الحالات، قد يكون Azure Storage غير قادر على معالجة طلب بسبب بعض الحالات العابرة. في كلتا الحالتين، قد ترجع الخدمة خطأ 503 (Server Busy) أو 500 (Timeout). يمكن أن تحدث هذه الأخطاء أيضاً إذا كانت الخدمة تعيد موازنة أقسام البيانات للسماح بمعدل النقل. يجب على تطبيق العميل عادةً إعادة محاولة العملية التي تسببت في أحد هذه الأخطاء. ومع ذلك، إذا كان Azure Storage يخنق تطبيقك لأنه يتجاوز أهداف قابلية التوسع، أو حتى إذا كانت الخدمة غير قادرة على خدمة الطلب لسبب آخر، فقد تؤدي عمليات إعادة المحاولة العدوانية إلى تفاقم المشكلة. يوصى باستخدام سياسة إعادة محاولة التراجع الأسي ومكتبات العميل الافتراضي لهذا السلوك. على سبيل المثال، قد يعيد التطبيق الخاص بك المحاولة بعد ثانيتين، ثم 4 ثوان، ثم 10 ثوان، ثم 30 ثانية، ثم يستسلم تماما. وبهذه الطريقة، يقلل التطبيق الخاص بك تحميله على الخدمة بشكل ملحوظ، بدلاً من تفاقم السلوك الذي يمكن أن يتسبب في التقييد.

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

أخطاء غير قابلة لإعادة المحاولة

تعالج مكتبات العميل عمليات إعادة المحاولة مع الوعي بالأخطاء التي يمكن إعادة محاولة تنفيذها والتي لا يمكن. ومع ذلك، إذا كنت تتصل بواجهة برمجة تطبيقات AZURE Storage REST مباشرة، فهناك بعض الأخطاء التي يجب عدم إعادة المحاولة. على سبيل المثال، يشير الخطأ 400 (Bad Request) إلى أن تطبيق العميل أرسل طلبا تعذرت معالجته لأنه لم يكن في النموذج المتوقع. تؤدي إعادة إرسال هذا الطلب إلى نفس الاستجابة في كل مرة، لذلك لا جدوى من إعادة المحاولة. إذا كنت تتصل بواجهة برمجة تطبيقات Azure Storage REST مباشرة، فكن على دراية بالأخطاء المحتملة وما إذا كان يجب إعادة المحاولة.

لمزيد من المعلومات حول رموز خطأ تخزين Microsoft Azure، راجع رموز الحالة والأخطاء.

تعطيل خوارزمية Nagle

يتم تنفيذ خوارزمية Nagle على نطاق واسع عبر شبكات TCP / IP كوسيلة لتحسين أداء الشبكة. ومع ذلك، فإنه ليس الأمثل في جميع الظروف (مثل البيئات التفاعلية للغاية). خوارزمية Nagle لها تأثير سلبي على أداء الطلبات إلى Microsoft Azure Table Storage، ويجب عليك تعطيلها إن أمكن.

حجم الرسالة

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

استرجاع الدفعة

يمكنك استرداد ما يصل إلى 32 رسالة من قائمة انتظار في عملية واحدة. يمكن أن يقلل استرداد الدُفعات من عدد الرحلات ذهاباً وإياباً من تطبيق العميل، وهو أمر مفيد بشكل خاص للبيئات، مثل الأجهزة المحمولة، ذات زمن انتقال عالٍ.

الفاصل الزمني للاقتراع في قائمة الانتظار

تقوم معظم التطبيقات باستقصاء الرسائل من قائمة انتظار، والتي يمكن أن تكون أحد أكبر مصادر المعاملات لهذا التطبيق. قم بتحديد الفاصل الزمني للاقتراع بحكمة: قد يؤدي إجراء الاقتراع بشكل متكرر إلى اقتراب تطبيقك من أهداف قابلية التوسع لقائمة الانتظار. ومع ذلك، عند 200,000 معاملة مقابل 0.01 دولار (في وقت كتابة هذا التقرير)، سيكلف استقصاء معالج واحد مرة واحدة كل ثانية لمدة شهر أقل من 15 سنتا، لذا فإن التكلفة ليست عادة عاملا يؤثر على اختيارك للفاصل الزمني للاستقصاء.

للحصول على معلومات محدثة عن التكلفة، راجع أسعار سعة التخزين في Microsoft Azure.

قم بإجراء عملية رسالة تحديث

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

تصميم التطبيق

قم باستخدام قوائم الانتظار لجعل بنية التطبيق قابلة للتطوير. فيما يلي قائمة ببعض الطرق التي يمكنك من خلالها استخدام قوائم الانتظار لجعل تطبيقك أكثر قابلية للتوسع:

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

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

• قابلية التوسع وأهداف الأداء لتخزين قائمة الانتظار
• قابلية التوسع وأهداف الأداء لحسابات التخزين القياسية
• رموز الحالة والخطأ