أفضل الممارسات لتحسين الأداء باستخدام مراسلة ناقل الخدمة

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

خلال هذه المقالة، يشير مصطلح "عميل" إلى أي كيان يصل إلى ناقل الخدمة. يمكن للعميل أن يؤدي دور المرسل أو المستلم. يُستخدم مصطلح "المرسل" للإشارة إلى عميل قائمة انتظار ناقل الخدمة أو لعميل موضوع يرسل رسائل إلى قائمة انتظار ناقل الخدمة أو موضوع. بينما يشير مصطلح "المستلم" إلى عميل قائمة انتظار ناقل الخدمة أو عميل اشتراك يستلم رسائل من قائمة انتظار ناقل الخدمة أو اشتراك.

تخطيط الموارد واعتباراتها

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

مستوى الأسعار

يقدم ناقل الخدمة مستويات تسعير مختلفة. يوصى باختيار المستوى المناسب لمتطلبات التطبيق الخاص بك.

• المستوى القياسي - مناسب لبيئات التطوير/الاختبار أو سيناريوهات معدل النقل المنخفض حيث تكون التطبيقات غير حساسة للتحكم بالنطاق الترددي.

• المستوى المتميز - مناسب لبيئات الإنتاج ذات متطلبات معدل النقل المتنوعة حيث يلزم زمن انتقال ومعدل نقل يمكن التنبؤ به. بالإضافة إلى ذلك، يمكن التحجيم التلقائي لمساحات الاسم المميزة لناقل الخدمة ويمكن تمكينها لاستيعاب حالات الارتفاع في معدل النقل.

إشعار

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

لا يؤدي التحكم بالنطاق الترددي إلى فقدان البيانات. يمكن للتطبيقات التي تستفيد من Service Bus SDK الاستفادة من نهج إعادة المحاولة الافتراضي لضمان قبول البيانات في نهاية المطاف من قبل ناقل خدمة Microsoft Azure.

حساب معدل النقل للمستوى المميز

يتم تسلسل البيانات المرسلة إلى ناقل الخدمة إلى ثنائي ثم إلغاء تسلسلها عندما يستلمها المستلم. ومن ثمَّ، بينما تعتبر التطبيقات الرسائل كوحدات عمل ذرية، يقيس ناقل الخدمة معدل النقل من حيث وحدات البايت (أو ميجابايت).

عند حساب متطلبات معدل النقل، خذ بعين الاعتبار البيانات التي يتم إرسالها إلى ناقل الخدمة (دخول) والبيانات التي يستلمها ناقل الخدمة (خروج).

وكما هو متوقع، يكون معدل النقل أعلى لحمولة الرسائل الأصغر التي يمكن إرسالها في دفعات معاً.

معايير

إليك عينة GitHub التي يمكنك تشغيلها لمشاهدة معدل النقل المتوقع الذي تتلقاه لمساحة اسم ناقل خدمة Microsoft Azure. في اختباراتنا المعيارية، لاحظنا ما يقرب من 4 ميجابايت/ثانية لكل وحدة مراسلة (MU) من الدخول والخروج.

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

اعتبارات الحساب

يتطلب استخدام ميزات معينة لناقل خدمة Microsoft Azure استخدام الحساب الذي يمكن أن يقلل من معدل النقل المتوقع. بعض هذه الميزات هي -

1. الجلسات.
2. التوزيع الموسع إلى اشتراكات متعددة حول موضوع واحد.
3. تشغيل العديد من عوامل التصفية على اشتراك واحد.
4. الرسائل المجدولة.
5. الرسائل المؤجلة.
6. المعاملات.
7. إلغاء التكرار ونظر إلى النافذة الزمنية للخلف.
8. إعادة التوجيه (إعادة التوجيه من كيان إلى آخر).

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

يمكنك أيضاً استخدام Azure Monitor في توسيع نطاق مساحة اسم ناقل الخدمة تلقائياً.

التقسيم عبر مساحات الاسم

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

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

البروتوكولات

يمكِّن ناقل الخدمة العملاء من إرسال الرسائل واستلامها عبر بروتوكول من ثلاثة بروتوكولات:

1. البروتوكول المتقدم لوضع الرسائل في قائمة الانتظار (AMQP)
2. بروتوكول مراسلة ناقل الخدمة (SBMP)
3. بروتوكول نقل النص التشعبي (HTTP)

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

هام

يتوفر بروتوكول SBMP فقط من أجل ‎.NET Framework. ويكون بروتوكول AMQP هو الافتراضي لـ ‎.NET Standard.

في 30 سبتمبر 2026، سنتقاعد دعم بروتوكول SBMP ناقل خدمة Azure، لذلك لن تتمكن من استخدام هذا البروتوكول بعد 30 سبتمبر 2026. قم بالترحيل إلى أحدث مكتبات SDK ناقل خدمة Azure باستخدام بروتوكول AMQP، الذي يوفر تحديثات أمان مهمة وقدرات محسنة، قبل ذلك التاريخ.

لمزيد من المعلومات، راجع إعلان إيقاف الدعم.

اختيار ‎.NET SDK المناسبة لناقل الخدمة

حزمة Azure.Messaging.ServiceBus هي أحدث ‎.NET SDK لخدمة Azure Service Bus ومتوفر من نوفمبر 2020. هناك عددان قديمان من .NET SDKs سيستمران في تلقي إصلاحات الأخطاء الهامة حتى 30 سبتمبر 2026، ولكننا نشجعك بشدة على استخدام أحدث SDK بدلا من ذلك. اقرأ دليل الترحيل للحصول على تفاصيل حول كيفية الانتقال من عِدد SDK الأقدم.

حزمة NuGet	مساحات الأسماء الأساسية	الحد الأدنى من الأنظمة الأساسية	البروتوكولات
Azure.Messaging.ServiceBus (latest)	Azure.Messaging.ServiceBus Azure.Messaging.ServiceBus.Administration	.NET Core 2.0 .NET Framework 4.6.1 Mono 5.4 النظام الأساسي العام لـ Windows‏ 10.0.16299	AMQP HTTP
Microsoft.Azure.ServiceBus	Microsoft.Azure.ServiceBus Microsoft.Azure.ServiceBus.Management	.NET Core 2.0 .NET Framework 4.6.1 Mono 5.4 النظام الأساسي العام لـ Windows‏ 10.0.16299	AMQP HTTP

لمزيد من المعلومات حول دعم الحد الأدنى للنظام الأساسي لـ ‎.NET Standard، راجع دعم تطبيق ‎.NET.

في 30 سبتمبر 2026، سنتقاعد مكتبات SDK ناقل خدمة Azure WindowsAzure.ServiceBus وMicrosoft.Azure.ServiceBus و com.microsoft.azure.servicebus، والتي لا تتوافق مع إرشادات Azure SDK. سننهي أيضا دعم بروتوكول SBMP، لذلك لن تتمكن من استخدام هذا البروتوكول بعد 30 سبتمبر 2026. قم بالترحيل إلى أحدث مكتبات Azure SDK، والتي توفر تحديثات أمان هامة وقدرات محسنة، قبل ذلك التاريخ.

على الرغم من أنه لا يزال من الممكن استخدام المكتبات القديمة بعد 30 سبتمبر 2026، إلا أنها لن تتلقى بعد ذلك الدعم والتحديثات الرسمية من Microsoft. لمزيد من المعلومات، راجع إعلان إيقاف الدعم.

إعادة استخدام المصانع والعملاء

Azure.Messaging.ServiceBus SDK

يجب تسجيل عملاء ناقل الخدمة الذين يتفاعلون مع الخدمة، مثل ServiceBusClient وServiceBusSender وServiceBusReceiver وServiceBusProcessor لحقن التبعية كقاعدة بيانات أحادية (أو إنشاء مثيل مرة واحدة ومشاركتها). يمكن تسجيل ServiceBusClient في حقن التبعيات باستخدام ServiceBusClientBuilderExtensions.

نوصي بعدم إغلاق هؤلاء العملاء أو التخلص منها بعد إرسال كل رسالة أو تلقيها. يؤدي إغلاق الكائنات الخاصة بالكيان (ServiceBusSender/Receiver/Processor) أو التخلص منها إلى قطع الارتباط بخدمة ناقل الخدمة. يؤدي التخلص من ServiceBusClient إلى قطع الاتصال بخدمة ناقل الخدمة.

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

Microsoft.Azure.ServiceBus SDK

يرجى ملاحظة أن هناك حزمة أحدث من Azure.Messaging.ServiceBus متوفرة من نوفمبر 2020. بينما ستستمر حزمة Microsoft.Azure.ServiceBus في تلقي إصلاحات الأخطاء الهامة حتى 30 سبتمبر 2026، فإننا نشجعك بشدة على الترقية. اقرأ دليل الترحيل للحصول على مزيد من التفاصيل.

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

تنطبق الملاحظة التالية على جميع عِدد SDK:

إشعار

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

العمليات المتوازية

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

يجدول العميل العمليات المتوازية عن طريق تنفيذ عمليات غير متزامنة. يتم بدء الطلب التالي قبل اكتمال الطلب السابق. القصاصة البرمجية التالية هي مثال على عملية إرسال غير متزامنة:

Azure.Messaging.ServiceBus SDK

var messageOne = new ServiceBusMessage(body);
var messageTwo = new ServiceBusMessage(body);

var sendFirstMessageTask =
    sender.SendMessageAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    sender.SendMessageAsync(messageTwo).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #2");
    });

await Task.WhenAll(sendFirstMessageTask, sendSecondMessageTask);
Console.WriteLine("All messages sent");

Microsoft.Azure.ServiceBus SDK

var messageOne = new Message(body);
var messageTwo = new Message(body);

var sendFirstMessageTask =
    queueClient.SendAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    queueClient.SendAsync(messageTwo).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #2");
    });

await Task.WhenAll(sendFirstMessageTask, sendSecondMessageTask);
Console.WriteLine("All messages sent");

التعليمات البرمجية التالية هي مثال على عملية استلام غير متزامنة.

Azure.Messaging.ServiceBus SDK

var client = new ServiceBusClient(connectionString);
var options = new ServiceBusProcessorOptions 
{

      AutoCompleteMessages = false,
      MaxConcurrentCalls = 20
};
await using ServiceBusProcessor processor = client.CreateProcessor(queueName,options);
processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

static Task ErrorHandler(ProcessErrorEventArgs args)
{
    Console.WriteLine(args.Exception);
    return Task.CompletedTask;
};

static async Task MessageHandler(ProcessMessageEventArgs args)
{
    Console.WriteLine("Handle message");
    await args.CompleteMessageAsync(args.Message);
}

await processor.StartProcessingAsync();

Microsoft.Azure.ServiceBus SDK

راجع مستودع GitHub للحصول على أمثلة على التعليمات البرمجية المصدر الكاملة.

var receiver = new MessageReceiver(connectionString, queueName, ReceiveMode.PeekLock);

static Task LogErrorAsync(Exception exception)
{
    Console.WriteLine(exception);
    return Task.CompletedTask;
};

receiver.RegisterMessageHandler(
    async (message, cancellationToken) =>
    {
        Console.WriteLine("Handle message");
        await receiver.CompleteAsync(message.SystemProperties.LockToken);
    },
    new MessageHandlerOptions(e => LogErrorAsync(e.Exception))
    {
        AutoComplete = false,
        MaxConcurrentCalls = 20
    });

يتم إنشاء مثيل للكائن MessageReceiver مع سلسلة الاتصال واسم قائمة الانتظار ووضع الاستلام "تأمين التحرير سريعاً". بعد ذلك، يتم استخدام مثيل receiver لتسجيل معالج الرسائل.

وضع الاستلام

عند إنشاء قائمة انتظار أو عميل اشتراك، يمكنك تحديد وضع استلام: تأمين التحرير سريعاً أو الاستلام والحذف. يكون وضع الاستلام الافتراضي هو PeekLock. عند التشغيل في الوضع الافتراضي، يرسل العميل طلباً لاستلام رسالة من ناقل الخدمة. بعد استلام العميل للرسالة، يرسل طلباً لإكمال الرسالة.

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

لا يدعم ناقل الخدمة المعامَلات لعمليات الاستلام والحذف. تكون دلالات تأمين التحرير سريعاً مطلوبة أيضاً لأية سيناريوهات يريد العميل فيها تأجيل أو إخماد رسالة.

الإحضار المسبق

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

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

عند استخدام انتهاء صلاحية التأمين الافتراضي لمدة 60 ثانية، تكون القيمة الجيدة ل PrefetchCount هي 20 مرة الحد الأقصى لمعدلات المعالجة لجميع أجهزة استقبال المصنع. على سبيل المثال، ينشئ المصنع ثلاثة مستلمين، ويمكن لكل مستلم معالجة ما يصل إلى 10 رسائل في الثانية. يجب ألا يتجاوز عدد عمليات الإحضار المسبق 20 × 3 × 10 = 600. بشكل افتراضي، PrefetchCount يتم تعيين إلى 0، مما يعني أنه لا يتم إحضار رسائل إضافية من الخدمة.

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

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

ولا يؤثر الإحضار المسبق على عدد عمليات المراسلة القابلة للفوترة، وهو متوفر فقط لبروتوكول عميل ناقل الخدمة. ولا يدعم بروتوكول HTTP الإحضار المسبق. حيث يتوفر الإحضار المسبق لعمليات الاستلام المتزامنة وغير المتزامنة.

Azure.Messaging.ServiceBus SDK

للحصول على مزيدٍ من المعلومات، راجع خصائص PrefetchCount التالية:

• ServiceBusReceiver.PrefetchCount
• ServiceBusProcessor.PrefetchCount

يمكنك تعيين قيم هذه الخصائص في ServiceBusReceiverOptions أو ServiceBusProcessorOptions.

Microsoft.Azure.ServiceBus SDK

للحصول على مزيدٍ من المعلومات، راجع خصائص PrefetchCount التالية:

• Microsoft.Azure.ServiceBus.QueueClient.PrefetchCount
• Microsoft.Azure.ServiceBus.SubscriptionClient.PrefetchCount

الإحضار المسبق و ReceiveMessagesAsync

في حين أن مفاهيم الإحضار المسبق لرسائل متعددة معاً لها دلالات مماثلة لمعالجة الرسائل في دفعة واحدة (ReceiveMessagesAsync)، توجد بعض الاختلافات الطفيفة التي يجب وضعها في الاعتبار عند استخدام هذه النهج معاً.

الإحضار المسبق هو تكوين (أو وضع) على ServiceBusReceiver ReceiveMessagesAsync وهو عملية (لها دلالات استجابة الطلب).

أثناء استخدام هذه النهج معاً، ضع في الاعتبار الحالات التالية -

• يجب أن يكون الإحضار المسبق أكبر من أو يساوي عدد الرسائل التي تتوقع استلامها من ReceiveMessagesAsync.
• يمكن أن يصل الإحضار المسبق إلى n/3 مرات عدد الرسائل التي تتم معالجتها في الثانية، حيث n هي مدة التأمين الافتراضية.

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

قوائم انتظار أو مواضيع متعددة

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

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

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

مساحات الأسماء المقسمة

عند استخدام مساحات أسماء الطبقة المتميزة المقسمة، تمنحك أقسام متعددة بوحدات مراسلة أقل (MU) أداء أفضل عبر قسم واحد بوحدات MUs أعلى.

السيناريوهات

توضح الأقسام التالية سيناريوهات المراسلة النموذجية وتحدد إعدادات ناقل الخدمة المفضلة. يتم تصنيف معدلات النقل على أنها صغيرة (أقل من رسالة واحدة في الثانية)، ومتوسطة (رسالة واحدة في الثانية أو أكثر لكن أقل من 100 رسالة في الثانية) وعالية (100 رسالة في الثانية أو أكثر). يتم تصنيف عدد العملاء على أنه صغير (5 أو أقل)، ومتوسط (أكثر من 5 لكن أقل من أو يساوي 20)، وكبير (أكثر من 20).

قائمة انتظار معدل النقل المرتفع

الهدف: الوصول إلى الحد الأقصى لمعدل النقل لقائمة انتظار واحدة. عدد المرسلين والمستلمين صغير.

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

تعدد قوائم انتظار معدل النقل المرتفع

الهدف: الوصول إلى الحد الأقصى لمعدل النقل الإجمالي لقوائم الانتظار المتعددة. معدل نقل قائمة انتظار فردية متوسط أو مرتفع.

للحصول على أقصى معدل نقل عبر قوائم انتظار متعددة، استخدم الإعدادات الموضحة للوصول إلى أقصى معدل نقل لقائمة انتظار واحدة. أيضاً، استخدم مصانع مختلفة لإنشاء عملاء يرسلون أو يستلمون من قوائم انتظار مختلفة.

قائمة انتظار زمن انتقال منخفض

الهدف: الوصول إلى الحد الأدنى لزمن انتقال قائمة انتظار أو موضوع. عدد المرسلين والمستلمين صغير. معدل النقل لقائمة الانتظار صغير أو متوسط.

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

قائمة انتظار بعدد كبير من المرسلين

الهدف: الوصول إلى الحد الأقصى لمعدل نقل قائمة الانتظار أو الموضوع بعدد كبير من المرسلين. يرسل كل مرسل رسائل بمعدل متوسط. عدد المستلمين صغير.

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

لتحقيق أقصى معدل نقل، اتبع الخطوات التالية:

• إذا كان كل مرسل في عملية مختلفة، فاستخدم مصنعاً واحداً فقط لكل عملية.
• استخدم عمليات غير متزامنة للاستفادة من الإرسال في دفعات من جانب العميل.
• اترك الوصول إلى المخزن المُرسَل في دفعات ممكَّناً. يزيد هذا الوصول المعدل الإجمالي الذي يمكن كتابة الرسائل في قائمة الانتظار أو الموضوع به.
• عيِّن عدد عمليات الإحضار المسبق على 20 مرة الحد الأقصى لمعدلات المعالجة لجميع المستلمين في المصنع. يقلل هذا العدد عدد عمليات إرسال بروتوكول عميل ناقل الخدمة.

قائمة انتظار بعدد كبير من المستلمين

الهدف: الوصول إلى الحد الأقصى لمعدل الاستلام لقائمة الانتظار أو الاشتراك بعدد كبير من المستلمين. يستلم كل مستلم الرسائل بمعدل متوسط. عدد المرسلين صغير.

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

لتحقيق أقصى معدل نقل، اتبع الإرشادات التالية:

• إذا كان كل مستلم في عملية مختلفة، فاستخدم مصنعاً واحداً فقط لكل عملية.
• يمكن أن يستخدم المستلمون عمليات متزامنة أو غير متزامنة. نظرا لمعدل الاستلام المتوسط لمستلم فردي، لا يؤثر الإرسال في دفعات من جانب العميل لطلب كامل على معدل النقل للمستلم.
• اترك الوصول إلى المخزن المُرسَل في دفعات ممكَّناً. يقلل هذا الوصول من الحمل الإجمالي للكيان. كما أنه يزيد من المعدل الإجمالي الذي يمكن من خلاله كتابة الرسائل في قائمة الانتظار أو الموضوع.
• عيِّن عدد عمليات الإحضار المسبق على قيمة صغيرة (على سبيل المثال، PrefetchCount‏ = 10). يمنع هذا العدد خمول المستلمين بينما يكون لدى المستلمين الآخرين أعداد كبيرة من الرسائل المخزنة مؤقتاً.

الموضوع بعدد قليل من الاشتراكات

الهدف: الوصول إلى الحد الأقصى لمعدل النقل لموضوع بعدد قليل من الاشتراكات. يتم استلام رسالة من قِبل العديد من الاشتراكات، مما يعني أن معدل الاستلام المجمَّع عبر جميع الاشتراكات أكبر من معدل الإرسال. عدد المرسلين صغير. عدد المستلمين لكل اشتراك صغير.

لتحقيق أقصى معدل نقل، اتبع الإرشادات التالية:

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

موضوع بعدد كبير من الاشتراكات

الهدف: الوصول إلى الحد الأقصى لمعدل النقل لموضوع بعدد كبير من الاشتراكات. يتم استلام رسالة من قِبل العديد من الاشتراكات، مما يعني أن معدل الاستلام المجمَّع عبر جميع الاشتراكات أكبر من معدل الإرسال. عدد المرسلين صغير. عدد المستلمين لكل اشتراك صغير.

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

لتحقيق أقصى معدل نقل، حاول اتباع الخطوات التالية:

• استخدم عمليات غير متزامنة للاستفادة من الإرسال في دفعات من جانب العميل.
• اترك الوصول إلى المخزن المُرسَل في دفعات ممكَّناً. يزيد هذا الوصول المعدل الإجمالي الذي يمكن كتابة الرسائل في الموضوع به.
• قم بتعيين عدد الجلب المسبق إلى 20 مرة المعدل المتوقع الذي يتم استلام الرسائل عنده. يقلل هذا العدد عدد عمليات إرسال بروتوكول عميل ناقل الخدمة.