مشاركة عبر

ضبط الأداء للتحميلات والتنزيلات باستخدام .NET

  • مقالة

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

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

ضبط الأداء باستخدام StorageTransferOptions

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

يمكن ضبط الخصائص التالية ل StorageTransferOptions استنادا إلى احتياجات تطبيقك:

  • InitialTransferSize - حجم الطلب الأول بالبايت
  • MaximumConcurrency - الحد الأقصى لعدد التحويلات الفرعية التي يمكن استخدامها بالتوازي
  • MaximumTransferSize - الحد الأقصى لطول النقل بالبايت

إشعار

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

تحويل الحجم الأولي

InitialTransferSize هو حجم طلب النطاق الأول بالبايت. طلب نطاق HTTP هو طلب جزئي، مع الحجم المحدد من قبل InitialTransferSize في هذه الحالة. يتم نقل الكائنات الثنائية كبيرة الحجم الأصغر من هذا الحجم في طلب واحد. يستمر نقل الكائنات الثنائية كبيرة الحجم أكبر من هذا الحجم في أجزاء من الحجم MaximumTransferSize.

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

إذا لم تكن متأكدا من القيمة الأفضل لموقفك، فإن الخيار الآمن هو تعيين InitialTransferSize إلى نفس القيمة المستخدمة ل MaximumTransferSize.

إشعار

عند استخدام كائن BlobClient ، سيتم تنفيذ تحميل كائن ثنائي كبير الحجم أصغر من InitialTransferSize باستخدام Put Blob، بدلا من Put Block.

الحد الأقصى للتزامن

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

تخضع فعالية هذه القيمة لحدود تجمع الاتصال في .NET، والتي قد تقيد الأداء بشكل افتراضي في سيناريوهات معينة. لمعرفة المزيد حول حدود تجمع الاتصال في .NET، راجع حدود تجمع اتصال .NET Framework وAzure SDK الجديد ل .NET.

الحد الأقصى للتحفير

MaximumTransferSize هو الحد الأقصى لطول النقل بالبايت. كما ذكرنا سابقا، لا تحد هذه القيمة ، والتي يمكن أن تكون أكبر من MaximumTransferSize.InitialTransferSize

للحفاظ على نقل البيانات بكفاءة، قد لا تصل مكتبات العميل دائما إلى MaximumTransferSize قيمة كل عملية نقل. اعتمادا على العملية، يمكن أن يختلف الحد الأقصى للقيمة المدعومة لحجم النقل. على سبيل المثال، تحتوي الكائنات الثنائية كبيرة الحجم للكتل التي تستدعي عملية Put Block بإصدار خدمة من 2019-12-12 أو أحدث على الحد الأقصى لحجم الكتلة 4000 ميبي بايت. لمزيد من المعلومات حول حدود حجم النقل لتخزين Blob، راجع المخطط في أهداف المقياس لتخزين Blob.

مثال على التعليمات البرمجية

تتضمن مكتبة العميل التحميلات الزائدة للأساليب Upload و UploadAsync ، والتي تقبل مثيل StorageTransferOptions كجزء من معلمة BlobUploadOptions . توجد أيضا حمولات زائدة مماثلة DownloadTo للأساليب و DownloadToAsync ، باستخدام معلمة BlobDownloadToOptions .

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

// Specify the StorageTransferOptions
BlobUploadOptions options = new BlobUploadOptions
{
    TransferOptions = new StorageTransferOptions
    {
        // Set the maximum number of parallel transfer workers
        MaximumConcurrency = 2,

        // Set the initial transfer length to 8 MiB
        InitialTransferSize = 8 * 1024 * 1024,

        // Set the maximum length of a transfer to 4 MiB
        MaximumTransferSize = 4 * 1024 * 1024
    }
};

// Upload data from a stream
await blobClient.UploadAsync(stream, options);

في هذا المثال، قمنا بتعيين عدد عمال النقل المتوازيين إلى 2، باستخدام الخاصية MaximumConcurrency . يفتح هذا التكوين ما يصل إلى اتصالين في وقت واحد، مما يسمح بحدوث التحميل بالتوازي. يحاول طلب نطاق HTTP الأولي تحميل ما يصل إلى 8 MiB من البيانات، كما هو محدد بواسطة الخاصية InitialTransferSize . لاحظ أنه InitialTransferSize ينطبق فقط على التحميلات عند استخدام دفق قابل للبحث. إذا كان حجم الكائن الثنائي كبير الحجم أصغر من 8 ميبي بايت، فمن الضروري طلب واحد فقط لإكمال العملية. إذا كان حجم الكائن الثنائي كبير الحجم أكبر من 8 ميبي بايت، فإن جميع طلبات النقل اللاحقة لها حد أقصى يبلغ 4 ميجابايت، والتي قمنا بتعيينها مع الخاصية MaximumTransferSize .

اعتبارات الأداء للتحميلات

أثناء التحميل، تقوم مكتبات عميل التخزين بتقسيم دفق تحميل معين إلى تحميلات فرعية متعددة استنادا إلى القيم المعرفة في المثيل StorageTransferOptions . كل تحميل فرعي له استدعاء مخصص خاص به لعملية REST. بالنسبة لكائن BlobClient أو BlockBlobClient كائن، هذه العملية هي Put Block. بالنسبة للعنصر DataLakeFileClient ، هذه العملية هي إلحاق البيانات. تدير مكتبة عميل التخزين عمليات REST هذه بالتوازي (اعتمادا على خيارات النقل) لإكمال التحميل الكامل.

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

إشعار

تحتوي الكائنات الثنائية كبيرة الحجم للكتلة على حد أقصى لعدد الكتل يبلغ 50,000 كتلة. الحد الأقصى لحجم الكائن الثنائي كبير الحجم للكتلة، ثم، هو 50000 مرة MaximumTransferSize.

التخزين المؤقت أثناء التحميلات

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

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

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

InitialTransferSize عند التحميل

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

اعتبارات الأداء للتنزيلات

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

التخزين المؤقت أثناء التنزيلات

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

InitialTransferSize عند التنزيل

أثناء التنزيل، تقوم مكتبات عميل التخزين بإجراء طلب نطاق تنزيل واحد باستخدام InitialTransferSize قبل القيام بأي شيء آخر. أثناء طلب التنزيل الأولي هذا، تعرف مكتبات العميل الحجم الإجمالي للمورد. إذا قام الطلب الأولي بتنزيل كل المحتوى بنجاح، تكتمل العملية. وإلا، تستمر مكتبات العميل في تقديم طلبات النطاق حتى MaximumTransferSize اكتمال التنزيل الكامل.

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