دليل الأداء لخدمة Azure SignalR
إحدى الفوائد الرئيسية لاستخدام خدمة Azure SignalR هي سهولة تحجيم تطبيقات SignalR. في سيناريو واسع النطاق، يعد الأداء عاملا مهما.
توضح هذه المقالة ما يلي:
- العوامل التي تؤثر على أداء تطبيق SignalR.
- الأداء النموذجي في سيناريوهات حالة الاستخدام المختلفة.
- البيئة والأدوات التي يمكنك استخدامها لإنشاء تقرير أداء.
تقييم سريع باستخدام المقاييس
يمكنك بسهولة مراقبة خدمتك في مدخل Microsoft Azure. من صفحة Metrics لمثيل SignalR الخاص بك، يمكنك تحديد مقاييس تحميل الخادم لمشاهدة "ضغط" الخدمة الخاصة بك.
يعرض المخطط ضغط الحوسبة لخدمة SignalR. يمكنك اختبار السيناريو الخاص بك والتحقق من هذا المقياس لتحديد ما إذا كنت تريد توسيع النطاق أم لا. يظل زمن الانتقال داخل خدمة SignalR منخفضا إذا كان تحميل الخادم أقل من 70٪.
إشعار
إذا كنت تستخدم الوحدة 50 أو أكبر وكان السيناريو الخاص بك يرسل بشكل أساسي إلى مجموعات صغيرة (حجم <المجموعة 20) أو اتصال واحد، تحتاج إلى التحقق من الإرسال إلى مجموعة صغيرة أو إرسال إلى الاتصال للرجوع إليها. في هذه السيناريوهات هناك تكلفة توجيه كبيرة غير مضمنة في تحميل الخادم.
تعريفات المصطلحات
الواردة: الرسالة الواردة إلى خدمة Azure SignalR.
الصادر: الرسالة الصادرة من خدمة Azure SignalR.
النطاق الترددي: الحجم الإجمالي لجميع الرسائل في ثانية 1.
الوضع الافتراضي: وضع العمل الافتراضي عند إنشاء مثيل Azure SignalR Service. تتوقع خدمة Azure SignalR أن ينشئ خادم التطبيق اتصالا به قبل أن يقبل أي اتصال عميل.
وضع بلا خادم: وضع تقبل فيه خدمة Azure SignalR اتصالات العميل فقط. لا يسمح بأي اتصال بالخادم.
نظرة عامة
تحدد خدمة Azure SignalR سبعة مستويات قياسية لقدرات الأداء المختلفة. يجيب هذا الدليل على الأسئلة التالية:
ما هو أداء Azure SignalR Service النموذجي لكل مستوى (وحدة)؟
هل تفي خدمة Azure SignalR بمتطلباتي لمعدل نقل الرسائل (على سبيل المثال، إرسال 100000 رسالة في الثانية)؟
بالنسبة للسيناريو المحدد، كيف يمكنني تحديد المستوى المناسب؟
ما نوع خادم التطبيق (حجم الجهاز الظاهري) المناسب لي؟ كم عدد هذه الملفات التي يجب توزيعها؟
للإجابة على هذه الأسئلة، يقدم هذا الدليل أولا شرحا رفيع المستوى للعوامل التي تؤثر على الأداء. ثم يوضح الحد الأقصى للرسائل الواردة والصادرة لكل مستوى لحالات الاستخدام النموذجية: الصدى والبث والإرسال إلى المجموعة والإرسال إلى الاتصال (الدردشة من نظير إلى نظير).
لا يمكن أن يغطي هذا الدليل جميع السيناريوهات (وحالات الاستخدام المختلفة وأحجام الرسائل وأنماط إرسال الرسائل وما إلى ذلك). ولكنه يوفر بعض الطرق لمساعدتك:
- تقييم متطلباتك التقريبية للرسائل الواردة أو الصادرة.
- ابحث عن المستويات المناسبة عن طريق التحقق من جدول الأداء.
نتيجة تحليلات الأداء
يصف هذا القسم منهجيات تقييم الأداء، ثم يسرد جميع العوامل التي تؤثر على الأداء. في النهاية، يوفر أساليب لمساعدتك في تقييم متطلبات الأداء.
المنهجية
معدل النقل وزمن الانتقال هما جانبان نموذجيان لفحص الأداء. بالنسبة لخدمة Azure SignalR، لكل مستوى SKU نهج التحكم في معدل النقل الخاص به. يحدد النهج الحد الأقصى المسموح به لمعدل النقل (النطاق الترددي الوارد والصادر) على أنه الحد الأقصى لمعدل النقل الذي تم تحقيقه عندما يكون لدى 99 بالمائة من الرسائل زمن انتقال أقل من ثانية.
زمن الانتقال هو الفترة الزمنية من الاتصال الذي يرسل الرسالة إلى تلقي رسالة الاستجابة من خدمة Azure SignalR. خذ صدى كمثال. يضيف كل اتصال عميل طابعا زمنيا في الرسالة. يرسل مركز خادم التطبيق الرسالة الأصلية مرة أخرى إلى العميل. لذلك يتم حساب تأخير النشر بسهولة بواسطة كل اتصال عميل. يتم إرفاق الطابع الزمني لكل رسالة في البث وإرسالها إلى المجموعة وإرسالها إلى الاتصال.
لمحاكاة الآلاف من اتصالات العميل المتزامنة، يتم إنشاء أجهزة ظاهرية متعددة في شبكة خاصة ظاهرية في Azure. تتصل جميع هذه الأجهزة الظاهرية بنفس مثيل خدمة Azure SignalR.
في الوضع الافتراضي لخدمة Azure SignalR، يتم نشر الأجهزة الظاهرية لخادم التطبيق في نفس الشبكة الظاهرية الخاصة مثل الأجهزة الظاهرية للعميل. يتم نشر جميع الأجهزة الظاهرية للعميل والأجهزة الظاهرية لخادم التطبيق في نفس الشبكة من نفس المنطقة لتجنب زمن الانتقال عبر المنطقة.
عوامل الأداء
تؤثر العوامل التالية على أداء SignalR.
- طبقة SKU (وحدة المعالجة المركزية/الذاكرة)
- الحد الأقصى لعدد الاتصالات
- حجم الرسالة
- معدل إرسال الرسالة
- نوع النقل (WebSocket أو Server-Sent-Event أو Long-Polling)
- سيناريو حالة الاستخدام (تكلفة التوجيه)
- خادم التطبيق واتصالات الخدمة (في وضع الخادم)
موارد الكمبيوتر
نظريا، سعة خدمة Azure SignalR محدودة من خلال موارد الحوسبة: وحدة المعالجة المركزية والذاكرة والشبكة. على سبيل المثال، تتسبب المزيد من الاتصالات بخدمة Azure SignalR في استخدام الخدمة لذاكرة أكبر. بالنسبة لحركة مرور الرسائل الأكبر (على سبيل المثال، كل رسالة أكبر من 2048 بايت)، تحتاج خدمة Azure SignalR إلى قضاء المزيد من دورات وحدة المعالجة المركزية لمعالجة نسبة استخدام الشبكة. وفي الوقت نفسه، يفرض النطاق الترددي لشبكة Azure أيضا حدا لحركة المرور القصوى.
نوع النقل
نوع النقل هو عامل آخر يؤثر على الأداء. الأنواع الثلاثة هي:
- WebSocket: WebSocket هو بروتوكول اتصال ثنائي الاتجاه وثنائي الاتجاه عبر اتصال TCP واحد.
- Server-Sent-Event: Server-Sent-Event هو بروتوكول أحادي الاتجاه لدفع الرسائل من الخادم إلى العميل.
- الاستقصاء الطويل: يتطلب الاستقصاء الطويل من العملاء استقصاء المعلومات بشكل دوري من الخادم من خلال طلب HTTP.
بالنسبة لنفس واجهة برمجة التطبيقات في ظل نفس الظروف، يتمتع WebSocket بأفضل أداء، وServer-Sent-Event أبطأ، و Long-Polling هو الأبطأ. توصي خدمة Azure SignalR ب WebSocket بشكل افتراضي.
تكلفة توجيه الرسائل
كما تحد تكلفة توجيه الرسائل من الأداء. تلعب خدمة Azure SignalR دورا كموجه رسالة، والذي يوجه الرسالة من مجموعة من العملاء أو الخوادم إلى عملاء أو خوادم أخرى. يتطلب سيناريو أو واجهة برمجة تطبيقات مختلفة نهج توجيه مختلف.
بالنسبة إلى echo، يرسل العميل رسالة إلى نفسه، ووجهة التوجيه هي نفسها أيضا. يحتوي هذا النمط على أقل تكلفة للتوجيه. ولكن للبث والإرسال إلى المجموعة والإرسال إلى الاتصال، تحتاج خدمة Azure SignalR إلى البحث عن الاتصالات الهدف من خلال بنية البيانات الموزعة الداخلية. تستخدم هذه المعالجة الإضافية المزيد من وحدة المعالجة المركزية والذاكرة وعرض النطاق الترددي للشبكة. ونتيجة لذلك، يكون الأداء أبطأ.
في الوضع الافتراضي، قد يصبح خادم التطبيق أيضا ازدحاما لسيناريوهات معينة. يجب على Azure SignalR SDK استدعاء المركز، بينما يحافظ على اتصال مباشر مع كل عميل من خلال إشارات كشف أخطاء الاتصال.
في وضع بلا خادم، يرسل العميل رسالة عن طريق منشور HTTP، وهو ليس فعالا مثل WebSocket.
بروتوكول
عامل آخر هو البروتوكول: JSON و MessagePack. MessagePack أصغر حجما ويتم تسليمها بشكل أسرع من JSON. على الرغم من ذلك، قد لا تعمل MessagePack على تحسين الأداء. أداء خدمة Azure SignalR غير حساس للبروتوكولات لأنها لا تقوم بفك تشفير حمولة الرسالة أثناء إعادة توجيه الرسائل من العملاء إلى الخوادم أو العكس.
العثور على SKU مناسب
كيف يمكنك تقييم السعة الواردة/الصادرة أو العثور على المستوى المناسب لحالة استخدام معينة؟
افترض أن خادم التطبيق قوي بما يكفي وليس ازدحام الأداء. ثم تحقق من الحد الأقصى للنطاق الترددي الوارد والصادر لكل مستوى.
تقييم سريع
لإجراء تقييم سريع، افترض الإعدادات الافتراضية التالية:
- نوع النقل هو WebSocket.
- حجم الرسالة هو 2048 بايت.
- يتم إرسال رسالة كل ثانية.
- خدمة Azure SignalR في الوضع الافتراضي.
كل مستوى له الحد الأقصى للنطاق الترددي الوارد والنطاق الترددي الصادر. لا يتم ضمان تجربة مستخدم سلسة بعد تجاوز الاتصال الوارد أو الصادر الحد.
يمنح Echo الحد الأقصى للنطاق الترددي الوارد لأنه يحتوي على أقل تكلفة للتوجيه. يحدد البث الحد الأقصى لعرض النطاق الترددي للرسالة الصادرة.
لا تتجاوز القيم المميزة في الجدولين التاليين.
| صدي | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| النطاق الترددي الوارد | 2 ميغابت في الثانية | 4 ميغابت في الثانية | 20 ميغابت في الثانية | 100 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 1000 ميغابت في الثانية | 2000 ميغابت في الثانية |
| النطاق الترددي الصادر | 2 ميغابت في الثانية | 4 ميغابت في الثانية | 20 ميغابت في الثانية | 100 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 1,000 ميغابت في الثانية | 2,000 ميغابت في الثانية |
| البث | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| النطاق الترددي الوارد | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps |
| النطاق الترددي الصادر | 4 ميغابت في الثانية | 8 ميغابت في الثانية | 40 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 800 ميغابت في الثانية | 2000 ميغابت في الثانية | 4000 ميغابت في الثانية |
النطاق الترددي الوارد والنطاق الترددي الصادر هما إجمالي حجم الرسالة في الثانية. فيما يلي الصيغ الخاصة بها:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
الواردة الاتصال: عدد الاتصالات التي ترسل الرسالة.
الصادر الاتصال: عدد الاتصالات التي تتلقى الرسالة.
messageSize: حجم رسالة واحدة (متوسط القيمة). رسالة صغيرة أقل من 1024 بايت لها تأثير على الأداء مشابه لرسالة 1024 بايت.
sendInterval: وقت إرسال رسالة واحدة. عادة ما تكون ثانية واحدة لكل رسالة، ما يعني إرسال رسالة واحدة كل ثانية. يعني الفاصل الزمني الأصغر إرسال المزيد من الرسائل في فترة زمنية. على سبيل المثال، تعني 0.5 ثانية لكل رسالة إرسال رسالتين كل ثانية.
الاتصال: الحد الأقصى الملتزم به لخدمة Azure SignalR لكل مستوى. إذا تم زيادة رقم الاتصال بشكل أكبر، فإنه يعاني من تقييد الاتصال.
تقييم حالات الاستخدام المعقدة
حجم رسالة أكبر أو معدل إرسال مختلف
حالة الاستخدام الحقيقية أكثر تعقيدا. قد يرسل رسالة أكبر من 2048 بايت، أو أن معدل إرسال الرسالة ليس رسالة واحدة في الثانية. لنأخذ بث الوحدة 100 كمثال للعثور على كيفية تقييم أدائها.
يعرض الجدول التالي حالة استخدام حقيقية للبث. ولكن حجم الرسالة وعدد الاتصالات ومعدل إرسال الرسائل تختلف عما افترضناه في القسم السابق. السؤال هو كيف يمكننا استنتاج أي من هذه العناصر (حجم الرسالة أو عدد الاتصالات أو معدل إرسال الرسائل) إذا كنا نعرف اثنين منها فقط.
| البث | حجم الرسالة | الرسائل الواردة المتزامنة | الاتصالات | إرسال فواصل زمنية |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100,000 | 5 ثوانٍ |
| 2 | 256 كيلوبايت | 1 | 8000 | 5 ثوانٍ |
من السهل استنتاج الصيغة التالية استنادا إلى الصيغة السابقة:
outboundConnections = outboundBandwidth * sendInterval / messageSize
بالنسبة للوحدة 100، يبلغ الحد الأقصى للنطاق الترددي الصادر 400 ميغابايت من الجدول السابق. بالنسبة لحجم الرسالة 20 كيلوبايت، يجب أن يكون الحد الأقصى للاتصالات الصادرة 400 ميغابايت * 5 / 20 كيلوبايت = 100000، والذي يطابق القيمة الحقيقية.
حالات الاستخدام المختلط
عادة ما تخلط حالة الاستخدام الحقيقية حالات الاستخدام الأساسية الأربع معا: الصدى والبث والإرسال إلى المجموعة والإرسال إلى الاتصال. المنهجية التي تستخدمها لتقييم السعة هي:
- قسم حالات الاستخدام المختلط إلى أربع حالات استخدام أساسية.
- حساب الحد الأقصى للنطاق الترددي للرسالة الواردة والصادرة باستخدام الصيغ السابقة بشكل منفصل.
- جمع حسابات النطاق الترددي للحصول على الحد الأقصى الإجمالي للنطاق الترددي الوارد/الصادر.
ثم التقط المستوى المناسب من الحد الأقصى لجداول النطاق الترددي الواردة/الصادرة.
إشعار
لإرسال رسالة إلى مئات أو آلاف المجموعات الصغيرة، أو لآلاف العملاء الذين يرسلون رسالة إلى بعضهم البعض، ستصبح تكلفة التوجيه مهيمنة. خذ هذا التأثير في الاعتبار.
بالنسبة لحالة استخدام إرسال رسالة إلى العملاء، تأكد من أن خادم التطبيق ليس هو الازدحام. يقدم قسم "دراسة الحالة" التالي إرشادات حول عدد خوادم التطبيقات التي تحتاجها وعدد اتصالات الخادم التي يجب تكوينها.
دراسة حالة
تمر الأقسام التالية بأربع حالات استخدام نموذجية لنقل WebSocket: echo و broadcast و send to group و send to connection. لكل سيناريو، يسرد القسم السعة الواردة والصادرة الحالية لخدمة Azure SignalR. كما يشرح العوامل الرئيسية التي تؤثر على الأداء.
في الوضع الافتراضي، ينشئ خادم التطبيق خمسة اتصالات خادم باستخدام Azure SignalR Service. يستخدم خادم التطبيق Azure SignalR Service SDK بشكل افتراضي. في نتائج اختبار الأداء التالية، تتم زيادة اتصالات الخادم إلى 15 (أو أكثر للبث وإرسال رسالة إلى مجموعة كبيرة).
حالات الاستخدام المختلفة لها متطلبات مختلفة لخوادم التطبيقات. يحتاج البث إلى عدد صغير من خوادم التطبيقات. يحتاج Echo أو send to connection إلى العديد من خوادم التطبيقات.
في جميع حالات الاستخدام، يكون حجم الرسالة الافتراضي 2048 بايت، والفاصل الزمني لإرسال الرسالة هو ثانية واحدة.
الوضع الافتراضي
يشارك العملاء وخوادم تطبيقات الويب وخدمة Azure SignalR في الوضع الافتراضي. كل عميل يرمز إلى اتصال واحد.
صدي
أولا، يتصل تطبيق ويب بخدمة Azure SignalR. ثانيا، يتصل العديد من العملاء بتطبيق الويب، الذي يعيد توجيه العملاء إلى خدمة Azure SignalR باستخدام رمز الوصول ونقطة النهاية. ثم يقوم العملاء بإنشاء اتصالات WebSocket مع خدمة Azure SignalR.
بعد أن يقوم جميع العملاء بإنشاء اتصالات، يبدأون في إرسال رسالة تحتوي على طابع زمني إلى المركز المحدد كل ثانية. يردد المركز الرسالة مرة أخرى إلى عميله الأصلي. يحسب كل عميل زمن الانتقال عندما يتلقى رسالة الصدى مرة أخرى.
في الرسم التخطيطي التالي، من 5 إلى 8 (حركة مرور مميزة باللون الأحمر) في حلقة. يتم تشغيل التكرار الحلقي لمدة افتراضية (5 دقائق) ويحصل على إحصائية كل زمن انتقال الرسالة.
يحدد سلوك echo أن الحد الأقصى للنطاق الترددي الوارد يساوي الحد الأقصى للنطاق الترددي الصادر. للحصول على التفاصيل، راجع الجدول التالي.
| صدي | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| الرسائل الواردة/الصادرة في الثانية | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| النطاق الترددي الوارد/الصادر | 2 ميغابت في الثانية | 4 ميغابت في الثانية | 20 ميغابت في الثانية | 100 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 1,000 ميغابت في الثانية | 2,000 ميغابت في الثانية |
في حالة الاستخدام هذه، يستدعي كل عميل المركز المحدد في خادم التطبيق. يستدعي المركز فقط الأسلوب المحدد في جانب العميل الأصلي. هذا المركز هو المركز الأكثر خفة للصدى.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
حتى بالنسبة لهذا المركز البسيط، يكون ضغط نسبة استخدام الشبكة على خادم التطبيق بارزا مع زيادة حمل الرسائل الواردة الصدى . يتطلب ضغط حركة المرور هذا العديد من خوادم التطبيقات لمستويات SKU الكبيرة. يسرد الجدول التالي عدد خوادم التطبيقات لكل مستوى.
| صدي | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| عدد خوادم التطبيقات | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
إشعار
يؤثر رقم اتصال العميل وحجم الرسالة ومعدل إرسال الرسائل وطبقة SKU وCPU/الذاكرة لخادم التطبيق على الأداء العام للارتداد.
البث
للبث، عندما يتلقى تطبيق الويب الرسالة، فإنه يبث إلى جميع العملاء. كلما زاد عدد العملاء الذين سيتم بثهم، زادت نسبة استخدام الرسائل إلى جميع العملاء. اطلع على الرسم التخطيطي التالي.
وهناك عدد قليل من العملاء يبثون. النطاق الترددي للرسالة الواردة صغير، ولكن النطاق الترددي الصادر كبير. يزداد النطاق الترددي للرسالة الصادرة مع زيادة اتصال العميل أو معدل البث.
يلخص الجدول التالي الحد الأقصى لاتصالات العميل وعدد الرسائل الواردة/الصادرة وعرض النطاق الترددي.
| البث | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| الرسائل الواردة في الثانية | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| الرسائل الصادرة في الثانية | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| النطاق الترددي الوارد | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps |
| النطاق الترددي الصادر | 4 ميغابت في الثانية | 8 ميغابت في الثانية | 40 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 800 ميغابت في الثانية | 2,000 ميغابت في الثانية | 4000 ميغابت في الثانية |
لا يزيد عملاء البث الذين يبثون الرسائل عن أربعة. وهي تحتاج إلى عدد أقل من خوادم التطبيقات مقارنة بالصدى لأن كمية الرسالة الواردة صغيرة. خادمان للتطبيق يكفيان لكل من اتفاقية مستوى الخدمة واعتبارات الأداء. ولكن يجب زيادة اتصالات الخادم الافتراضية لتجنب عدم التوازن، خاصة بالنسبة للوحدة الأكبر من 50.
| البث | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| عدد خوادم التطبيقات | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
إشعار
قم بزيادة اتصالات الخادم الافتراضية من 5 إلى 40 على كل خادم تطبيق لتجنب اتصالات الخادم غير المتوازنة المحتملة بخدمة Azure SignalR.
يؤثر رقم اتصال العميل وحجم الرسالة ومعدل إرسال الرسائل وطبقة SKU على الأداء العام للبث.
إرسال إلى المجموعة
حالة استخدام الإرسال إلى المجموعة لها نمط حركة مرور مشابه للبث. الفرق هو أنه بعد قيام العملاء بإنشاء اتصالات WebSocket مع خدمة Azure SignalR، يجب عليهم الانضمام إلى المجموعات قبل أن يتمكنوا من إرسال رسالة إلى مجموعة معينة. يوضح الرسم التخطيطي التالي تدفق نسبة استخدام الشبكة.
عدد أعضاء المجموعة والمجموعة هما عاملان يؤثران على الأداء. لتبسيط التحليل، نحدد نوعين من المجموعات:
مجموعة صغيرة: كل مجموعة لديها 10 اتصالات. رقم المجموعة يساوي (الحد الأقصى لعدد الاتصالات) / 10. على سبيل المثال، بالنسبة للوحدة 1، إذا كان هناك 1000 عدد اتصال، فسيكون لدينا 1000 / 10 = 100 مجموعة.
المجموعة الكبيرة: رقم المجموعة هو دائما 10. عدد أعضاء المجموعة يساوي (الحد الأقصى لعدد الاتصالات) / 10. على سبيل المثال، بالنسبة للوحدة 1، إذا كان هناك 1000 عدد اتصال، فسيكون لكل مجموعة 1000 / 10 = 100 عضو.
يؤدي الإرسال إلى المجموعة إلى إحضار تكلفة التوجيه إلى خدمة Azure SignalR لأنه يجب عليها العثور على الاتصالات الهدف من خلال بنية بيانات موزعة. مع زيادة اتصالات الإرسال، تزداد التكلفة.
مجموعة صغيرة
تكلفة التوجيه كبيرة لإرسال رسالة إلى العديد من المجموعات الصغيرة. حاليا، يصل تنفيذ خدمة Azure SignalR إلى حد تكلفة التوجيه عند الوحدة 50. إضافة المزيد من وحدة المعالجة المركزية والذاكرة لا يساعد، لذلك لا يمكن أن تتحسن الوحدة 100 بشكل أكبر حسب التصميم. إذا كنت بحاجة إلى المزيد من النطاق الترددي الوارد، فاتصل بدعم العملاء.
| إرسال إلى مجموعة صغيرة | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| عدد أعضاء المجموعة | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| عدد المجموعات | 100 | 200 | 1,000 | 5,000 | 10,000 | 20,000 | 50,000 | 100,000 |
| الرسائل الواردة في الثانية | 200 | 400 | 2,000 | 10,000 | 10,000 | 20,000 | 50,000 | 100,000 |
| النطاق الترددي الوارد | 400 كيلوبايت في الثانية | 800 كيلوبايت في الثانية | 4 ميغابت في الثانية | 20 ميغابت في الثانية | 20 ميغابت في الثانية | 40 ميغابت في الثانية | 100 ميغابت في الثانية | 200 ميغابت في الثانية |
| الرسائل الصادرة في الثانية | 2,000 | 4,000 | 20,000 | 100,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| النطاق الترددي الصادر | 4 ميغابت في الثانية | 8 ميغابت في الثانية | 40 ميغابت في الثانية | 200 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 1,000 ميغابت في الثانية | 2,000 ميغابت في الثانية |
تتصل العديد من اتصالات العميل بالمركز، لذا فإن رقم خادم التطبيق مهم أيضا للأداء. يسرد الجدول التالي عدد خوادم التطبيقات المقترحة.
| إرسال إلى مجموعة صغيرة | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| عدد خوادم التطبيقات | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
إشعار
يؤثر رقم اتصال العميل وحجم الرسالة ومعدل إرسال الرسائل وتكلفة التوجيه وطبقة SKU وCPU/الذاكرة لخادم التطبيق على الأداء العام للإرسال إلى مجموعة صغيرة.
عدد المجموعات، عدد أعضاء المجموعة المدرجة في الجدول ليست حدودا صعبة. يتم تحديد قيم المعلمات هذه لإنشاء سيناريو معيار ثابت. على سبيل المثال، لا بأس من تعيين كل conneciton إلى مجموعة مميزة. ضمن هذا التكوين، يكون الأداء قريبا من الإرسال إلى الاتصال.
مجموعة كبيرة
للإرسال إلى مجموعة كبيرة، يصبح النطاق الترددي الصادر هو الازدحام قبل الوصول إلى حد تكلفة التوجيه. يسرد الجدول التالي الحد الأقصى للنطاق الترددي الصادر، وهو تقريبا نفس النطاق الترددي للبث.
| إرسال إلى مجموعة كبيرة | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| عدد أعضاء المجموعة | 100 | 200 | 500 | 1,000 | 2,000 | 5,000 | 10,000 | 20,000 |
| عدد المجموعات | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| الرسائل الواردة في الثانية | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| النطاق الترددي الوارد | 40 كيلوبايت في الثانية | 40 كيلوبايت في الثانية | 40 كيلوبايت في الثانية | 40 كيلوبايت في الثانية | 40 كيلوبايت في الثانية | 40 كيلوبايت في الثانية | 40 كيلوبايت في الثانية | 40 كيلوبايت في الثانية |
| الرسائل الصادرة في الثانية | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| النطاق الترددي الصادر | 4 ميغابت في الثانية | 8 ميغابت في الثانية | 40 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 800 ميغابت في الثانية | 2,000 ميغابت في الثانية | 4000 ميغابت في الثانية |
لا يزيد عدد الاتصالات المرسلة عن 40. العبء على خادم التطبيق صغير، لذا فإن العدد المقترح لتطبيقات الويب صغير.
| إرسال إلى مجموعة كبيرة | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| عدد خوادم التطبيقات | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
إشعار
قم بزيادة اتصالات الخادم الافتراضية من 5 إلى 40 على كل خادم تطبيق لتجنب اتصالات الخادم غير المتوازنة المحتملة بخدمة Azure SignalR.
يؤثر رقم اتصال العميل وحجم الرسالة ومعدل إرسال الرسائل وتكلفة التوجيه وطبقة SKU على الأداء العام للإرسال إلى مجموعة كبيرة.
إرسال إلى الاتصال
في حالة استخدام الإرسال إلى الاتصال ، عندما يقوم العملاء بإنشاء الاتصالات بخدمة Azure SignalR، يستدعي كل عميل مركز خاص للحصول على معرف الاتصال الخاص بهم. يجمع معيار الأداء جميع معرفات الاتصال، ويخلطها، ويعيد تعيينها لجميع العملاء كهدف إرسال. يستمر العملاء في إرسال الرسالة إلى الاتصال الهدف حتى ينتهي اختبار الأداء.
تكلفة توجيه الإرسال إلى الاتصال مشابهة لتكلفة الإرسال إلى مجموعة صغيرة.
مع زيادة عدد الاتصالات، تصبح تكلفة التوجيه عاملا حاسما يحد من الأداء العام. وبشكل ملحوظ، تشير الوحدة 20 إلى الحد الذي تصل فيه الخدمة إلى ازدحام التوجيه. لا تؤدي الزيادات الإضافية في عدد الوحدات إلى تحسينات في الأداء ما لم يكن هناك تحول إلى Premium_P2 (الوحدة >=100)، ما يعزز قدرات التوجيه.
الجدول التالي هو ملخص إحصائي بعد العديد من جولات تشغيل معيار الإرسال إلى الاتصال .
| إرسال إلى الاتصال | الوحدة 1 | الوحدة 2 | الوحدة 20 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 20,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| الرسائل الواردة/الصادرة في الثانية | 1,000 | 2,000 | 20,000 | 20,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| النطاق الترددي الوارد/الصادر | 2 ميغابت في الثانية | 4 ميغابت في الثانية | 40 ميغابت في الثانية | 40 ميغابت في الثانية | 40 ميغابت في الثانية | 80 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية |
إشعار
على الرغم من الركود في الرسائل الواردة/الصادرة في الثانية بعد الوحدة 20، لا تزال القدرة على المزيد من الاتصالات تنمو. في سيناريوهات الأعمال الحقيقية، غالبا ما يكون عدد الاتصالات، وليس نشاط إرسال الرسائل المتزامن، هو الذي يشكل الازدحام. من غير المألوف أن ترسل جميع الاتصالات رسائل بنشاط على ترددات عالية مثل اختبار المعيار.
تتطلب حالة الاستخدام هذه تحميلا عاليا على جانب خادم التطبيق. راجع عدد خوادم التطبيقات المقترحة في الجدول التالي.
| إرسال إلى الاتصال | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| عدد خوادم التطبيقات | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
إشعار
يؤثر رقم اتصال العميل وحجم الرسالة ومعدل إرسال الرسائل وتكلفة التوجيه وطبقة SKU وCPU/الذاكرة لخادم التطبيق على الأداء العام للإرسال إلى الاتصال.
ASP.NET SignalR
توفر خدمة Azure SignalR نفس سعة الأداء ASP.NET SignalR.
وضع بلا خادم
يشارك العملاء وخدمة Azure SignalR في وضع بلا خادم. كل عميل يرمز إلى اتصال واحد. يرسل العميل رسائل من خلال واجهة برمجة تطبيقات REST إلى عميل آخر أو يبث الرسائل إلى الجميع.
إرسال رسائل عالية الكثافة من خلال واجهة برمجة تطبيقات REST ليس فعالا مثل استخدام WebSocket. يتطلب منك إنشاء اتصال HTTP جديد في كل مرة، وهي تكلفة إضافية في الوضع بلا خادم.
البث من خلال واجهة برمجة تطبيقات REST
ينشئ جميع العملاء اتصالات WebSocket مع خدمة Azure SignalR. ثم يبدأ بعض العملاء في البث من خلال واجهة برمجة تطبيقات REST. يتم إرسال الرسالة (الواردة) من خلال HTTP Post، وهو أمر غير فعال مقارنة ب WebSocket.
| البث من خلال واجهة برمجة تطبيقات REST | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| الرسائل الواردة في الثانية | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| الرسائل الصادرة في الثانية | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| النطاق الترددي الوارد | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps | 4 كيلوبايت ps |
| النطاق الترددي الصادر | 4 ميغابت في الثانية | 8 ميغابت في الثانية | 40 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية | 800 ميغابت في الثانية | 2000 ميغابت في الثانية | 4000 ميغابت في الثانية |
إرسال إلى المستخدم من خلال واجهة برمجة تطبيقات REST
يعين المعيار أسماء المستخدمين لجميع العملاء قبل أن يبدأوا في الاتصال بخدمة Azure SignalR. بعد قيام العملاء بإنشاء اتصالات WebSocket مع خدمة Azure SignalR، يبدأون في إرسال الرسائل إلى الآخرين من خلال HTTP Post.
| إرسال إلى المستخدم من خلال واجهة برمجة تطبيقات REST | الوحدة 1 | الوحدة 2 | الوحدة 10 | الوحدة 50 | الوحدة 100 | الوحدة 200 | الوحدة 500 | الوحدة 1000 |
|---|---|---|---|---|---|---|---|---|
| الاتصالات | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| الرسائل الواردة/الصادرة في الثانية | 200 | 400 | 2,000 | 10,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| النطاق الترددي الوارد/الصادر | 400 كيلوبايت في الثانية | 800 كيلوبايت في الثانية | 4 ميغابت في الثانية | 20 ميغابت في الثانية | 40 ميغابت في الثانية | 80 ميغابت في الثانية | 200 ميغابت في الثانية | 400 ميغابت في الثانية |
بيئات اختبار الأداء
بالنسبة لجميع حالات الاستخدام المذكورة أعلاه، أجرينا اختبارات الأداء في بيئة Azure. على الأكثر، استخدمنا 200 جهاز ظاهري للعميل و100 جهاز ظاهري لخادم التطبيق. فيما يلي بعض التفاصيل:
حجم الجهاز الظاهري للعميل: StandardDS2V2 (2 vCPU، ذاكرة 7G)
حجم الجهاز الظاهري لخادم التطبيقات: StandardF4sV2 (4 vCPU، ذاكرة 8G)
اتصالات خادم Azure SignalR SDK: 15
أدوات الأداء
يمكنك العثور على أدوات الأداء لخدمة Azure SignalR على GitHub.
الخطوات التالية
في هذه المقالة، حصلت على نظرة عامة على أداء خدمة Azure SignalR في سيناريوهات حالة الاستخدام النموذجية.
للحصول على تفاصيل حول الأقسام الداخلية للخدمة وتغيير حجمها، اقرأ الدلائل التالية: