قائمة التحقق من الأداء وقابلية التوسع لتخزين Blob
طورت Microsoft عددًا من الممارسات المجربة لتطوير تطبيقات عالية الأداء مع تخزين كائن ثنائي كبير الحجم. تحدد قائمة التحقق هذه الممارسات الرئيسية التي يمكن للمطورين اتباعها لتحسين الأداء. ضع هذه الممارسات في الاعتبار أثناء تصميم التطبيق الخاص بك وطوال العملية.
يحتوي Azure Storage على أهداف قابلية التوسع والأداء للسعة ومعدل الحركة والنطاق الترددي. لمزيد من المعلومات حول أهداف قابلية التوسع في Azure Storage، راجع أهداف قابلية التوسع والأداء لحسابات التخزين القياسية وأهداف قابلية التوسع والأداء لتخزين Blob.
قائمة الاختيار
تنظم هذه المقالة الممارسات المثبتة للأداء في قائمة تحقق يمكنك اتباعها في أثناء تطوير تطبيق تخزين كائن ثنائي كبير الحجم خاصتك.
أهداف قابلية التوسع
إذا اقترب تطبيقك من أي من أهداف قابلية التوسع أو تجاوزها، فقد يواجه زيادة في زمن انتقال المعاملات أو تقييدها. عندما يقوم Azure Storage بتقييد التطبيق لديك، تبدأ الخدمة بإرجاع رموز الخطأ 503 (الخادم مشغول) أو خطأ 500 (انتهاء مهلة العملية). يمثل تجنب هذه الأخطاء بالتواجد ضمن حدود أهداف قابلية التوسع جزءًا مهمًا من تحسين أداء التطبيق لديك.
لمزيد من المعلومات حول أهداف قابلية التوسع لخدمة قائمة الانتظار، راجع أهداف قابلية التوسع والأداء في Azure Storage.
أقصى عدد لحسابات التخزين
إذا كنت تقترب من الحد الأقصى لعدد حسابات التخزين المسموح بها لمجموعة اشتراك/منطقة معينة، فقيّم السيناريو خاصتك وحدد ما إذا كان أي من الشروط التالية ينطبق:
- هل تستخدم حسابات التخزين لتخزين الأقراص غير المدارة وإضافة هذه الأقراص إلى أجهزتك الافتراضية (VMS )؟ بالنسبة إلى هذا السيناريو، توصي Microsoft باستخدام الأقراص المدارة. مقياس الأقراص المدارة لك تلقائيًا ودون الحاجة إلى إنشاء وإدارة حسابات تخزين فردية. لمزيد من المعلومات، راجع مقدمة حول الأقراص المدارة من Azure
- هل تستخدم حساب تخزين واحد لكل عميل، لغرض عزل البيانات؟ بالنسبة إلى هذا السيناريو، توصي Microsoft باستخدام حاوية كائن ثنائي كبير الحجم لكل عميل، بدلاً من حساب تخزين كامل. يسمح لك تخزين Azure الآن بتعيين أدوار Azure على أساس كل حاوية. لمزيد من المعلومات، راجع تعيين دور Azure للوصول إلى بيانات كائن ثنائي كبير الحجم.
- هل تستخدم حسابات تخزين متعددة لزيادة عمليات الدخول أو الخروج أو الإدخال/الإخراج في الثانية (IOPS) أو السعة؟ في هذا السيناريو، توصي Microsoft بالاستفادة من زيادة حدود حسابات التخزين لتقليل عدد حسابات التخزين اللازمة لحمل العمل الخاص بك إذا أمكن. اتصل ِAzure Support لطلب زيادة حدود حساب التخزين لديك.
أهداف السعة والحركة
في حال كان التطبيق لديك يقترب من أهداف قابلية التوسع لحساب تخزين واحد، فحاول استخدام أحد النهج التالية:
- إذا وصل طلبك إلى هدف المعاملة، ففكر في استخدام حسابات تخزين كتلة كائن ثنائي كبير الحجم، والتي تم تحسينها لمعدلات المعاملات المرتفعة والوقت المستغرق المنخفض والثابت. لمزيد من المعلومات، راجع نظرة عامة على حساب تخزين Azure.
- قم بإعادة النظر في حجم العمل الذي يتسبب في اقتراب تطبيقك من هدف قابلية التوسع أو تجاوزه. هل يمكنك تصميمه بشكل مختلف لتقليل استخدام النطاق الترددي أو السعة، أو حركات أقل؟
- في حال كان يجب أن يتجاوز التطبيق الخاص بك أحد أهداف قابلية التوسع، فيُرجى إنشاء حسابات تخزين متعددة وتقسيم بيانات التطبيق لديك عبر حسابات التخزين المتعددة هذه. في حال كنت تستخدم هذا النمط، فتأكد من تصميم التطبيق الخاص بك حيث يمكنك إضافة المزيد من حسابات التخزين في المستقبل لموازنة التحميل. ليس لحسابات التخزين نفسها أي تكلفة غير استخدامك فيما يتعلق بالبيانات المخزنة أو الحركات المنفذة أو البيانات المنقولة.
- في حال كان التطبيق يقترب من أهداف النطاق الترددي، فحاول ضغط البيانات من جانب العميل لتقليل النطاق الترددي اللازم لإرسال البيانات إلى Azure Storage. بينما ضغط البيانات قد يحفظ النطاق الترددي ويُحسن أداء الشبكة، فيمكن أيضًا أن يكون له تأثيرات سلبية على الأداء. قيم تأثير أداء متطلبات المعالجة الإضافية لضغط البيانات وفك الضغط من جانب العميل. تذكَّر أن تخزين البيانات المضغوطة يمكن أن يجعل استكشاف الأخطاء وإصلاحها أكثر صعوبة لأنه قد يكون من الصعب عرض البيانات باستخدام أدوات قياسية.
- إذا كان تطبيقك يقترب من أهداف قابلية التوسع، فتأكد من استخدام تراجع أسي لإعادة المحاولة. من الأفضل محاولة تجنب الوصول إلى أهداف قابلية التوسع بتنفيذ التوصيات الموضحة في هذه المقالة. ومع ذلك، فإن استخدام التراجع الأسي لإعادة المحاولة يمنع التطبيق الخاص بك من إعادة المحاولة بسرعة، مما قد يجعل التقييد أسوأ. للحصول على مزيد من المعلومات، راجع المقطع بعنوان أخطاء انتهاء المهلة والخادم مشغول.
وصول العديد من العملاء إلى كائن ثنائي كبير الحجم واحد في وقت واحد
إذا كان لديك عدد كبير من العملاء الذين يصلون إلى كائن ثنائي كبير الحجم واحد في وقت واحد، فستحتاج إلى مراعاة كل من أهداف قابلية التوسع لكل كائن ثنائي كبير الحجم ولكل حساب تخزين. يختلف العدد الدقيق للعملاء الذين يمكنهم الوصول إلى كائن ثنائي كبير الحجم واحد اعتمادا على عوامل مثل عدد العملاء الذين يطلبون الكائن الثنائي كبير الحجم في وقت واحد وحجم الكائن الثنائي كبير الحجم وظروف الشبكة.
إذا كان من الممكن توزيع الكائن الثنائي كبير الحجم من خلال CDN مثل الصور أو مقاطع الفيديو التي يتم عرضها من موقع ويب، فإنه يمكنك استخدام CDN. لمزيد من المعلومات، راجع القسم المسمى توزيع المحتوى.
في سيناريوهات أخرى، مثل المحاكاة العلمية حيث تكون البيانات سرية، لديك خياران. الأول هو ترتيب الوصول إلى حِمل العمل خاصتك بحيث يتم الوصول إلى الكائن الثنائي كبير الحجم خلال فترة من الزمن مقابل الوصول إليها في وقت واحد. بدلاً من ذلك، يمكنك نسخ الكائن الثنائي كبير الحجم مؤقتًا إلى حسابات تخزين متعددة لزيادة إجمالي عمليات الإدخال والإخراج في الثانية لكل كائن ثنائي كبير الحجم وعبر حسابات التخزين. تختلف النتائج وفقا لسلوك التطبيق الخاص بك، لذا تأكد من اختبار أنماط التزامن أثناء التصميم.
عرض النطاق الترددي والعمليات لكل كائن ثنائي كبير الحجم
يدعم كائن ثنائي كبير الحجم واحد ما يصل إلى 500 طلب في الثانية. إذا كان لديك العديد من العملاء الذين يحتاجون إلى قراءة نفس الكائن الثنائي كبير الحجم وقد تتجاوز هذا الحد، ففكر في استخدام حساب تخزين كائن ثنائي كبير الحجم. يوفر حساب تخزين كائن ثنائي كبير الحجم معدل طلب أعلى، أو عمليات الإدخال/الإخراج في الثانية (IOPS).
يمكنك أيضًا استخدام شبكة توصيل المحتوى (CDN) مثل Azure CDN لتوزيع العمليات على الكائن الثنائي كبير الحجم. لمزيد من المعلومات حول Azure CDN، راجع نظرة عامة على Azure CDN.
التقسيم
يعتبر فهم كيفية تقسيم تخزين Azure لبيانات كائن ثنائي كبير الحجم مفيدًا لتحسين الأداء. يمكن لتخزين Azure تقديم البيانات في قسم واحد بسرعة أكبر من البيانات التي تمتد عبر أقسام متعددة. من خلال تسمية الكائنات الثنائية كبيرة الحجم خاصتك بشكل مناسب، يمكنك تحسين كفاءة قراءة الطلبات.
يستخدم تخزين كائن ثنائي كبير الحجم مخطط تقسيم قائم على النطاق لتوسيع النطاق وموازنة الحمل. يحتوي كل كائن ثنائي كبير الحجم على مفتاح تقسيم يتكون من الاسم الكامل لكائن ثنائي كبير الحجم (الحساب+الحاوية+الكائن الثنائي كبير الحجم). يُستخدم مفتاح التقسيم لتقسيم بيانات الكائنات الثنائية كبيرة الحجم إلى نطاقات. بعد ذلك تكون النطاقات متوازنة الحمل عبر تخزين كائن ثنائي كبير الحجم.
التقسيم المستند إلى النطاق يعني أن اصطلاحات التسمية التي تستخدم الترتيب المعجمي (على سبيل المثال، من المرجح أن يؤدي mypayroll أو myperformance أو myemployees وما إلى ذلك) أو الطوابع الزمنية (log20160101 وlog20160102 وlog20160102 وما إلى ذلك) إلى تعايش الأقسام على نفس خادم القسم حتى يتطلب التحميل المتزايد تقسيمها إلى نطاقات أصغر. إن وضع الكائنات الثنائية كبيرة الحجم على نفس خادم القسم يعزز الأداء، لذا فإن جزءًا مهمًا من تحسين الأداء يتضمن تسمية الكائن الثنائي كبير الحجم بطريقة تنظمها بشكل أكثر فعالية.
على سبيل المثال، يمكن خدمة جميع الكائنات الثنائية كبيرة الحجم داخل الحاوية بواسطة خادم واحد حتى يتطلب الحمل على هذه الكائنات الثنائية كبيرة الحجم المزيد من إعادة التوازن لنطاقات التقسيم. وبالمثل، يمكن خدمة مجموعة من الحسابات خفيفة التحميل بأسمائها مرتبة بترتيب معجمي بواسطة خادم واحد حتى يتطلب الحمل على واحد من هذه الحسابات أو جميعها تقسيمها عبر العديد من خوادم التقسيم.
يمكن أن تؤثر كل عملية موازنة حمل على زمن وصول مكالمات التخزين في أثناء العملية. قدرة الخدمة على التعامل مع الاندفاع المفاجئ لحركة المرور إلى أحد الأقسام محدودة من خلال قابلية توسيع خادم قسم واحد حتى تبدأ عملية موازنة الحمل وإعادة موازنة نطاق مفتاح التقسيم.
يمكنك اتباع بعض أفضل الممارسات لتقليل وتيرة هذه العمليات.
إذا أمكن، فاستخدم أحجام كائنات ثنائية كبيرة الحجم أو بلوك أكبر من 256 كيلوبايت لحسابات التخزين القياسية والمتميزة. تنشط أحجام الكائنات الثنائية كبيرة الحجم أو الكتل الأكبر تلقائيًا كائنات ثنائية كبيرة الحجم للكتلة ذات معدل نقل عالٍ. توفر الكائنات الثنائية كبيرة الحجم للكتلة عالية الإنتاجية استيعابا عالي الأداء لا يتأثر بتسمية القسم.
افحص اتفاقية التسمية التي تستخدمها للحسابات والحاويات والكائنات الثنائية كبيرة الحجم والجداول وقوائم الانتظار. ضع في اعتبارك إضافة بادئة لأسماء الحسابات أو الحاويات أو الكائنات الثنائية كبيرة الحجم باستخدام تجزئة مكونة من ثلاثة أرقام باستخدام وظيفة تجزئة تناسب احتياجاتك على أفضل وجه.
إذا قمت بتنظيم بياناتك باستخدام الطوابع الزمنية أو المعرفات الرقمية، فتأكد من أنك لا تستخدم نمط حركة مرور إلحاقي فقط (أو prepend-only). هذه الأنماط غير مناسبة لنظام التقسيم المستند إلى النطاق. قد تؤدي هذه الأنماط إلى ذهاب كل حركة المرور إلى قسم واحد والحد من موازنة الحمل بشكل فعال.
على سبيل المثال، إذا كان لديك عمليات يومية تستخدم كائن ثنائي كبير الحجم مع طابع زمني مثل yyyymmdd، فسيتم توجيه كل حركة المرور لهذه العملية اليومية إلى كائن ثنائي كبير الحجم واحد، والذي يتم تقديمه بواسطة خادم قسم واحد. ضع في اعتبارك ما إذا كانت حدود كل كائن ثنائي كبير الحجم وحدود كل قسم تلبي احتياجاتك، وفكر في تقسيم هذه العملية إلى كائنات ثنائية كبيرة الحجم متعددة إذا لزم الأمر. وبالمثل، إذا خزنت بيانات السلاسل الزمنية في جداولك، فقد يتم توجيه جميع الزيارات إلى الجزء الأخير من مساحة الاسم الرئيسية. إذا كنت تستخدم معرفات رقمية، فقم ببادئة المعرف بتجزئة مكونة من ثلاثة أرقام. إذا كنت تستخدم الطوابع الزمنية، فبادئة الطابع الزمني بقيمة ثانية، على سبيل المثال، ssyyyymmdd. إذا كان التطبيق الخاص بك ينفذ عمليات إدخال القوائم والاستعلام بشكل روتيني، فاختر دالة تجزئة تحد من عدد الاستعلامات. في بعض الحالات، قد تكون البادئة العشوائية كافية.
لمزيد من المعلومات حول نظام التقسيم المستخدم في Azure Storage، راجع تخزين Azure: خدمة التخزين السحابي عالية التوفر مع تناسق قوي.
الشبكات
قد يكون لقيود الشبكة المادية للتطبيق تأثير كبير على الأداء. توضح المقاطع التالية بعض القيود التي قد يواجهها المستخدمون.
إمكانيات شبكة العميل
يؤدي النطاق الترددي وجودة ارتباط الشبكة أدوارًا مهمة في أداء التطبيق، كما هو موضح في المقاطع التالية.
الإنتاجية
فيما يتعلق بالنطاق الترددي، تكون المشكلة غالبًا إمكانيات العميل. تحتوي مثيلات Microsoft Azure الأكبر على بطاقات NIC ذات سعة أكبر، لذا يجب أن تفكر في استخدام مثيل أكبر أو عدد أكبر من الأجهزة الظاهرية إذا كنت بحاجة إلى حدود شبكة أعلى من جهاز واحد. إذا كنت تصل إلى Azure Storage من تطبيق محلي، فإن نفس القاعدة تنطبق: فهم قدرات الشبكة لجهاز العميل واتصال الشبكة بموقع Azure Storage وإما تحسينها حسب الحاجة أو تصميم التطبيق الخاص بك للعمل ضمن قدراتها.
جودة الارتباط
كما هو الحال مع أي استخدام للشبكة، ضع في اعتبارك أن ظروف الشبكة التي تؤدي إلى أخطاء وفقدان الحزمة تبطئ معدل النقل الفعال. قد يساعد استخدام WireShark أو NetMon على تشخيص هذه المشكلة.
Location
في أي بيئة موزعة، يحقق وضع العميل بالقرب من الخادم أفضل أداء. للوصول إلى Azure Storage في أقل زمن انتقال، يكون أفضل موقع للعميل في منطقة Azure ذاتها. على سبيل المثال، إذا كان لديك تطبيق ويب Azure يستخدم Azure Storage، فحدد موقعهما داخل منطقة واحدة، مثل غرب الولايات المتحدة أو جنوب شرقي آسيا. تقلل موارد تحديد الموقع المشترك من زمن الانتقال والتكلفة، حيث إن استخدام النطاق الترددي داخل منطقة واحدة مجاني.
إذا كانت تطبيقات العميل تصل إلى Azure Storage ولكن لم تتم استضافتها داخل Azure، مثل تطبيقات الأجهزة المحمولة أو خدمات المؤسسة المحلية، فإن تحديد موقع حساب التخزين في منطقة قريبة من هؤلاء العملاء قد يقلل من زمن الانتقال. إذا كان العملاء موزعين بشكل عام (على سبيل المثال، بعضهم في أمريكا الشمالية، وبعضهم في أوروبا)، فحاول استخدام حساب تخزين واحد لكل منطقة. يكون تنفيذ هذا الأسلوب أسهل إذا كانت البيانات التي يخزنها التطبيق خاصة بالمستخدمين الفرديين، ولا تتطلب نسخ البيانات نسخا متماثلا بين حسابات التخزين.
للتوزيع الواسع لمحتوى الكائنات الثنائية كبيرة الحجم، استخدم شبكة توصيل المحتوى مثل Azure CDN. لمزيد من المعلومات حول Azure CDN، راجع Azure CDN.
توقيعات الوصول المشتركة ومشاركة الموارد عبر المصادر
افترض أنك بحاجة إلى تخويل تعليمات برمجية مثل 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 في تجنب التحميل غير الضروري على تطبيق الويب الخاص بك.
التخزين المؤقت
يلعب التخزين المؤقت دورًا مهمًا في الأداء. تتناول الأقسام التالية أفضل ممارسات التخزين المؤقت.
قراءة البيانات
عامةً، يفضل قراءة البيانات مرة واحدة عن قراءتها مرتين. ضع في اعتبارك مثال تطبيق الويب الذي استرد كائنًا ثنائيًا كبير الحجم 50 ميغابايت من تخزين Azure ليكون بمثابة محتوى للمستخدم. من الناحية المثالية، يخفي التطبيق الكائن الثنائي كبير الحجم محليًا على القرص ثم يسترجع الإصدار المخبأ لطلبات المستخدم اللاحقة.
إحدى الطرق لتجنب استرداد كائن ثنائي كبير الحجم إذا لم يتم تعديلها منذ أن تم تخزينها مؤقتًا هي تأهيل عملية الحصول على عنوان مشروط لوقت التعديل. إذا كانت آخر مرة تم تعديلها بعد الوقت الذي تم فيه تخزين الكائن الثنائي كبير الحجم، فسيتم استرجاع الكائن الثنائي كبير الحجم وإعادة تخزينه. خلاف ذلك، يتم استرداد كائن ثنائي كبير الحجم المؤقت للحصول على الأداء الأمثل.
قد تقرر أيضًا تصميم طلبك لافتراض أن الكائن الثنائي كبير الحجم يظل دون تغيير لفترة قصيرة بعد استعادته. في هذه الحالة، لا يحتاج التطبيق إلى التحقق مما إذا كان قد تم تعديل الكائن الثنائي كبير الحجم أثناء هذا الفاصل الزمني.
تعد بيانات التكوين وبيانات البحث والبيانات الأخرى التي يستخدمها التطبيق بشكل متكرر مرشحات جيدة للتخزين المؤقت.
لمزيد من المعلومات حول استخدام الرؤوس الشرطية، راجع تحديد الرؤوس الشرطية لعمليات خدمة Blob.
تحميل البيانات في دفعات
في بعض السيناريوهات، يمكنك تجميع البيانات محليًا، ثم تحميلها بشكل دوري في دفعة بدلاً من تحميل كل قطعة من البيانات على الفور. على سبيل المثال، لنفترض أن تطبيق الويب يحتفظ بملف سجل للأنشطة. يمكن للتطبيق إما تحميل تفاصيل كل نشاط لأنه يحدث لجدول (والذي يتطلب العديد من عمليات التخزين)، أو يمكنه حفظ تفاصيل النشاط في ملف سجل محلي ثم تحميل جميع تفاصيل النشاط بشكل دوري كملف محدد إلى كائن ثنائي كبير الحجم. إذا كان حجم كل إدخال في السجل يساوي 1 كيلو بايت، فإنه يمكنك تحميل آلاف الإدخالات في معاملة واحدة. تدعم معاملة واحدة تحميل كائن ثنائي كبير الحجم يصل حجمه إلى 64 ميجا بايت. يجب على مطور التطبيق التصميم لاحتمال فشل جهاز العميل أو التحميل. إذا كانت بيانات النشاط بحاجة إلى تنزيل لفترة زمنية بدلاً من نشاط واحد، فمن المستحسن استخدام تخزين ثنائي كبير الحجم فوق تخزين الجدول.
تكوين NET
بالنسبة للمشاريع التي تستخدم .NET Framework، يسرد هذا القسم بعض إعدادات التكوين السريعة التي يمكنك استخدامها لإجراء تحسينات كبيرة على الأداء. إذا كنت تستخدم لغة أخرى غير .NET، فتحقق لمعرفة ما إذا كانت المفاهيم المماثلة تنطبق على اللغة التي اخترتها.
رفع حد الاتصال الافتراضي
إشعار
ينطبق هذا القسم على المشاريع التي تستخدم .NET Framework، حيث يتم التحكم في تجميع الاتصال بواسطة فئة ServicePointManager. أدخل .NET Core تغييرا كبيرا حول إدارة تجمع الاتصال، حيث يحدث تجميع الاتصال على مستوى HttpClient ولا يقتصر حجم التجمع بشكل افتراضي. وهذا يعني أن اتصالات HTTP يتم قياسها تلقائيا لتلبية حمل العمل الخاص بك. يوصى باستخدام أحدث إصدار من .NET، عندما يكون ذلك ممكنا، للاستفادة من تحسينات الأداء.
بالنسبة للمشاريع التي تستخدم .NET Framework، يمكنك استخدام التعليمات البرمجية التالية لزيادة حد الاتصال الافتراضي (وهو عادة اثنان في بيئة عميل أو عشرة في بيئة خادم) إلى 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 بشكل نشط بتطوير مكتبات العميل وأدواته مع وضع الأداء في الاعتبار، وتواصل تحديثها بأحدث إصدارات الخدمة، وتضمن معالجتها للعديد من ممارسات الأداء المثبتة داخليًا.
تلميح
تم تصميم برنامج تشغيل ABFS للتغلب على أوجه القصور المتأصلة في WASB. توصي Microsoft باستخدام برنامج تشغيل ABFS عبر برنامج تشغيل WASB، حيث تم تحسين برنامج تشغيل ABFS خصيصًا لتحليلات البيانات الضخمة.
تعامل مع أخطاء الخدمة
يقوم Azure Storage بإرجاع خطأ عندما لا تتمكن الخدمة من معالجة طلب. يكون فهم الأخطاء التي قد يتم إرجاعها باستخدام Azure Storage في سيناريو محدد مفيدًا لتحسين الأداء. للحصول على قائمة رموز الخطأ الشائعة، راجع رموز خطأ واجهة برمجة تطبيقات REST الشائعة.
أخطاء انتهاء المهلة والخادم مشغول
قد يخنق Microsoft Azure Storage تطبيقك إذا اقترب من حدود قابلية التوسع. قد لا يكون Azure Storage في بعض الحالات قادرًا على معالجة طلب بسبب بعض الحالات العابرة. قد ترجع الخدمة في كلتا الحالتين خطأ 503 (الخادم مشغول) أو خطأ 500 (انتهاء المُهلة). يمكن أن تحدث هذه الأخطاء أيضاً إذا كانت الخدمة تعيد موازنة أقسام البيانات للسماح بمعدل النقل. يجب على تطبيق العميل عادةً إعادة محاولة العملية التي تسببت في أحد هذه الأخطاء. ومع ذلك، إذا كان Azure Storage يخنق تطبيقك لأنه يتجاوز أهداف قابلية التوسع، أو حتى إذا كانت الخدمة غير قادرة على خدمة الطلب لسبب آخر، فقد تؤدي عمليات إعادة المحاولة العدوانية إلى تفاقم المشكلة. يوصى باستخدام سياسة إعادة محاولة التراجع الأسي ومكتبات العميل الافتراضي لهذا السلوك. على سبيل المثال، قد يعاود التطبيق الخاص بك المحاولة بعد ثانيتين ثم 4 ثوانٍ ثم 10 ثوانٍ ثم 30 ثانية ثم يتخلى تمامًا. وبهذه الطريقة، يقلل التطبيق الخاص بك تحميله على الخدمة بشكل ملحوظ، بدلاً من تفاقم السلوك الذي يمكن أن يتسبب في التقييد.
يمكن إعادة محاولة أخطاء الاتصال ivity على الفور، لأنها ليست نتيجة للتقييد ومن المتوقع أن تكون عابرة.
أخطاء غير قابلة لإعادة المحاولة
تعالج مكتبات العميل عمليات إعادة المحاولة مع الوعي بالأخطاء التي يمكن إعادة محاولة تنفيذها والتي لا يمكن إعادة المحاولة. ومع ذلك، إذا كنت تتصل بواجهة برمجة تطبيقات AZURE Storage REST مباشرة، فهناك بعض الأخطاء التي يجب عدم إعادة المحاولة. على سبيل المثال، يشير الخطأ 400 (طلب غير صحيح) إلى أن تطبيق العميل أرسل طلبا تعذرت معالجته لأنه لم يكن في النموذج المتوقع. تؤدي إعادة إرسال هذا الطلب إلى نفس الاستجابة في كل مرة، لذلك لا جدوى من إعادة المحاولة. إذا كنت تتصل بواجهة برمجة تطبيقات Azure Storage REST مباشرة، فكن على دراية بالأخطاء المحتملة وما إذا كان يجب إعادة المحاولة.
لمزيد من المعلومات حول رموز خطأ تخزين Microsoft Azure، راجع رموز الحالة والأخطاء.
نسخ ونقل كائنات ثنائية كبيرة الحجم
يوفر تخزين Azure عددًا من الحلول لنسخ ونقل الكائنات الثنائية كبيرة الحجم داخل حساب التخزين، وبين حسابات التخزين، وبين الأنظمة المحلية والسحابة. يُبين هذا القسم بعض هذه الخيارات من حيث آثارها على الأداء. للحصول على معلومات حول نقل البيانات بكفاءة من أو إلى تخزين Blob، راجع اختيار حل Azure لنقل البيانات.
واجهات برمجة تطبيقات نسخ عنصر ثنائي كبير الحجم
لنسخ الكائنات الثنائية كبيرة الحجم عبر حسابات التخزين، استخدم عملية Put Block From URL . تقوم هذه العملية بنسخ البيانات بشكل متزامن من أي مصدر عنوان URL إلى كائن ثنائي كبير الحجم للكتلة. Put Block from URL يمكن أن يؤدي استخدام العملية إلى تقليل النطاق الترددي المطلوب بشكل كبير عند ترحيل البيانات عبر حسابات التخزين. نظرا لأن عملية النسخ تتم على جانب الخدمة، فلن تحتاج إلى تنزيل البيانات وإعادة تحميلها.
لنسخ البيانات داخل نفس حساب التخزين، استخدم عملية Copy Blob . عادة ما يتم نسخ البيانات داخل حساب التخزين نفسه بسرعة.
استخدام AzCopy
تعد الأداة المساعدة AzCopy Command - line خيارًا بسيطًا وفعالاً لنقل الكائنات الثنائية كبيرة الحجم بكميات كبيرة إلى حسابات التخزين ومنها وعبرها. تم تحسين AzCopy لهذا السيناريو، ويمكن أن يحقق معدلات نقل عالية. يستخدم Put Block From URL الإصدار 10 من AzCopy العملية لنسخ بيانات الكائن الثنائي كبير الحجم عبر حسابات التخزين. لمزيد من المعلومات، راجع نسخ البيانات أو نقلها إلى Azure Storage باستخدام AzCopy v10.
استخدام صندوق بيانات Azure
لاستيراد كميات كبيرة من البيانات إلى تخزين كائن ثنائي كبير الحجم، ضع في اعتبارك استخدام فئة صندوق بيانات Azure للتحويلات دون اتصال بالإنترنت. تعد أجهزة صندوق البيانات التي توفرها Microsoft خيارًا جيدًا لنقل كميات كبيرة من البيانات إلى Azure عندما تكون محدودًا بالوقت أو توفر الشبكة أو التكاليف. لمزيد من المعلومات، راجع وثائق Azure DataBox.
توزيع المحتوى
في بعض الأحيان يحتاج التطبيق إلى تقديم نفس المحتوى للعديد من المستخدمين (على سبيل المثال، فيديو المنتج التجريبي المستخدم في الصفحة الرئيسية لموقع الويب)، الموجود إما في نفس المناطق أو في مناطق متعددة. في هذا السيناريو، استخدم شبكة تسليم المحتوى (CDN) مثل Azure Front Door. Azure Front Door هو شبكة CDN سحابية حديثة من Microsoft توفر وصولا سريعا وموثوقا وآمنا بين المستخدمين ومحتوى الويب الثابت والديناميكي لتطبيقاتك في جميع أنحاء العالم. يقدم Azure Front Door محتوى Blob Storage الخاص بك باستخدام شبكة الحافة العالمية من Microsoft مع مئات من نقاط الحضور العالمية والمحلية (PoPs). يمكن أن تدعم شبكة تسليم المحتوى عادة حدود خروج أعلى بكثير من حساب تخزين واحد وتوفر زمن انتقال محسنا لتسليم المحتوى إلى عمليات إعادة الدمج الأخرى.
لمزيد من المعلومات حول Azure Front Door، راجع Azure Front Door.
استخدام بيانات التعريف
تدعم خدمة كائن ثنائي كبير الحجم طلبات HEAD، والتي يمكن أن تشمل خصائص كائن ثنائي كبير الحجم أو بيانات التعريف. على سبيل المثال، إذا كان طلبك يحتاج إلى بيانات Exif (تنسيق الصورة القابلة للتبديل) من الصورة، فإنه يمكنه استرداد الصورة واستخراجها. لتوفير عرض النطاق الترددي وتحسين الأداء، يمكن للتطبيق تخزين بيانات Exif في بيانات تعريف كائن ثنائي كبير الحجم عند تحميل التطبيق للصورة. يمكنك بعد ذلك استرداد بيانات EXIF في بيانات التعريف باستخدام طلب HEAD فقط. إن استرداد بيانات التعريف فقط وليس المحتويات الكاملة للقطعة يوفر عرض النطاق الترددي الكبير ويقلل من وقت المعالجة المطلوب لاستخراج بيانات Exif. ضع في اعتبارك أنه يمكن تخزين 8 كيلو بايت من بيانات التعريف لكل كائن ثنائي كبير الحجم.
تحديثات بيانات تعريف الحساب والحاوية
يتم نشر بيانات تعريف الحساب والحاوية عبر خدمة التخزين في المنطقة التي يوجد فيها الحساب. يمكن أن يستغرق النشر الكامل لبيانات التعريف هذه ما يصل إلى 60 ثانية اعتمادا على العملية. على سبيل المثال:
- إذا كنت تقوم بإنشاء حسابات بنفس اسم الحساب وحذفها وإعادة إنشائها بسرعة في نفس المنطقة، فتأكد من أنك تنتظر 60 ثانية حتى يتم نشر حالة الحساب بشكل كامل، أو قد تفشل طلباتك.
- عند إنشاء نهج وصول مخزن على حاوية، قد يستغرق تطبيق النهج ما يصل إلى 30 ثانية.
ضبط الأداء لنقل البيانات
عندما يقوم أحد التطبيقات بنقل البيانات باستخدام مكتبة عميل Azure Storage، هناك عدة عوامل يمكن أن تؤثر على سرعة الطلب واستخدام الذاكرة وحتى نجاح الطلب أو فشله. لتحقيق أقصى قدر من الأداء والموثوقية لنقل البيانات، من المهم أن تكون استباقيا في تكوين خيارات نقل مكتبة العميل استنادا إلى البيئة التي يعمل فيها تطبيقك. لمعرفة المزيد، راجع ضبط الأداء للتحميلات والتنزيلات.
تحميل الكائنات الثنائية كبيرة الحجم بسرعة
لتحميل الكائنات الثنائية كبيرة الحجم بسرعة، حدد أولا ما إذا كنت تقوم بتحميل كائن ثنائي كبير الحجم واحد أو أكثر. استخدم الإرشادات أدناه لتحديد الطريقة الصحيحة لاستخدامها اعتمادًا على السيناريو خاصتك. إذا كنت تستخدم مكتبة عميل Azure Storage لنقل البيانات، فشاهد ضبط الأداء لنقل البيانات لمزيد من الإرشادات.
تحميل كائن ثنائي كبير الحجم كبير بسرعة
لتحميل كائن ثنائي كبير الحجم واحد كبير بسرعة، يمكن لتطبيق العميل تحميل كتله أو صفحاته بالتوازي، مع مراعاة أهداف قابلية التوسع لكل كائن ثنائي كبير الحجم وحساب التخزين ككل. تدعم مكتبات عملاء تخزين Azure التحميل على التوازي. توفر مكتبات العملاء للغات الأخرى المدعومة خيارات مماثلة.
تحميل العديد من الكائنات الثنائية كبيرة الحجم بسرعة
لتحميل العديد من الكائنات الثنائية كبيرة الحجم بسرعة، قم بتحميل الكائنات الثنائية كبيرة الحجم بالتوازي. التحميل بالتوازي أسرع من تحميل كائن ثنائي كبير الحجم في وقت واحد مع تحميلات كتلة متوازية لأنه ينشر التحميل عبر أقسام متعددة من خدمة التخزين. يقوم AzCopy بإجراء التحميلات بشكل متوازٍ افتراضيًا، ويوصى به لهذا السيناريو. لمزيد من المعلومات، راجع البدء باستخدام AzCopy.
اختر النوع الصحيح من الكائن الثنائي كبير الحجم
يدعم تخزين كائنات ثنائية كبيرة الحجم للكتلة، وكائنات ثنائية كبيرة الحجم للإلحاق، وكائنات ثنائية كبيرة الحجم للصفحة. بالنسبة لسيناريو استخدام معين، يؤثر اختيارك لنوع الكائن الثنائي كبير الحجم على أداء الحل وقابليته للتوسع.
تعد الكائنات الثنائية كبيرة الحجم للكتلة مناسبة عندما تريد تحميل كميات كبيرة من البيانات بكفاءة. على سبيل المثال، سيستهدف تطبيق العميل الذي يقوم بتحميل صور أو مقاطع فيديو إلى تخزين كائنات ثنائية كبيرة الحجم للكتلة.
تشبه الكائنات الثنائية كبيرة الحجم الملحقة الكائنات الثنائية كبيرة الحجم للكتلة من حيث أنها تتكون من كتل. عند تعديل كائن ثنائي كبير الحجم ملحق، تتم إضافة الكتل إلى نهاية الكائن الثنائي كبير الحجم فقط. إلحاق كائنات ثنائية كبيرة الحجم مفيدة لسيناريوهات مثل تسجيل الأداء، عندما يحتاج التطبيق إلى إضافة بيانات إلى كائن ثنائي كبير الحجم موجود.
نقط الصفحة مناسبة إذا كان التطبيق يحتاج إلى أداء كتابات عشوائية على البيانات. على سبيل المثال، يتم تخزين أقراص الماكينة الظاهرية Azure ككائنات ثنائية كبيرة الحجم للصفحة. لمزيد من المعلومات، راجع فهم الكائنات الثنائية كبيرة الحجم للكتلة، وإلحاق الكائنات الثنائية كبيرة الحجم، والكائنات الثنائية كبيرة الحجم للصفحة.