دليل الأداء لخدمة Azure Web PubSub
إحدى الفوائد الرئيسية لاستخدام خدمة Azure Web PubSub هي سهولة التحجيم. في سيناريو واسع النطاق، يعد الأداء عاملا مهما.
في هذا الدليل، نقدم العوامل التي تؤثر على أداء خدمة Web PubSub. نصف الأداء النموذجي في سيناريوهات حالة الاستخدام المختلفة.
تقييم سريع باستخدام المقاييس
قبل المرور بالعوامل التي تؤثر على الأداء، دعنا أولا نقدم طريقة سهلة لمراقبة ضغط خدمتك. هناك مقياس يسمى تحميل الخادم على المدخل.
يظهر ضغط الحوسبة لخدمة Azure Web PubSub. يمكنك الاختبار على السيناريو الخاص بك والتحقق من هذا المقياس لتحديد ما إذا كنت تريد توسيع النطاق أم لا. سيبقى زمن الانتقال داخل خدمة Azure Web PubSub منخفضا إذا كان تحميل الخادم أقل من 70٪.
إشعار
إذا كنت تستخدم الوحدة 50 أو أكبر وكان السيناريو الخاص بك يرسل بشكل أساسي إلى مجموعات صغيرة (حجم <المجموعة 20)، فستحتاج إلى التحقق من الإرسال إلى مجموعة صغيرة للرجوع إليها. في هذه السيناريوهات هناك تكلفة توجيه كبيرة غير مضمنة في تحميل الخادم.
فيما يلي مفاهيم مفصلة لتقييم الأداء.
تعريفات المصطلحات
الواردة: الرسالة الواردة إلى خدمة Azure Web PubSub.
الصادر: الرسالة الصادرة من خدمة Azure Web PubSub.
النطاق الترددي: الحجم الإجمالي لجميع الرسائل في ثانية 1.
نظرة عامة
يجيب هذا الدليل على الأسئلة التالية:
ما هو أداء خدمة Azure Web PubSub النموذجية لكل حجم وحدة؟
هل تفي خدمة Azure Web PubSub بمتطلباتي لمعدل نقل الرسائل (على سبيل المثال، إرسال 100000 رسالة في الثانية)؟
بالنسبة للسيناريو المحدد، كيف يمكنني تحديد حجم الوحدة المناسب؟
للإجابة على هذه الأسئلة، يقدم هذا الدليل أولا شرحا رفيع المستوى للعوامل التي تؤثر على الأداء. ثم يوضح الحد الأقصى للرسائل الواردة والصادرة لحالات الاستخدام النموذجية: إرسال إلى المجموعات من خلال Web PubSub subprotocol وoutstream و rest api .
لا يمكن أن يغطي هذا الدليل جميع السيناريوهات (وحالات الاستخدام المختلفة وأحجام الرسائل وأنماط إرسال الرسائل وما إلى ذلك). ولكنه يوفر بعض المعلومات الأساسية لفهم قيود الأداء.
نتيجة تحليلات الأداء
يصف هذا القسم منهجيات تقييم الأداء، ثم يسرد جميع العوامل التي تؤثر على الأداء. في النهاية، يوفر أساليب لمساعدتك في تقييم متطلبات الأداء.
المنهجية
معدل النقل وزمن الانتقال هما جانبان نموذجيان لفحص الأداء. يتم تعريف الحد الأقصى لمعدل النقل (النطاق الترددي الوارد والصادر) على أنه الحد الأقصى لمعدل النقل المحقق عندما يكون لدى 99 بالمائة من الرسائل زمن انتقال أقل من ثانية. إنه ليس حدا صعبا.
عوامل الأداء
نظريا، سعة خدمة Azure Web PubSub محدودة بموارد الحساب: وحدة المعالجة المركزية والذاكرة والشبكة. على سبيل المثال، تتسبب المزيد من الاتصالات بخدمة Azure Web PubSub في استخدام الخدمة لذاكرة أكبر. بالنسبة لنسبة استخدام الرسائل الأكبر (على سبيل المثال، أكبر من 2048 بايت لكل رسالة)، تحتاج خدمة Azure Web PubSub إلى إنفاق المزيد من دورات وحدة المعالجة المركزية لمعالجة نسبة استخدام الشبكة.
كما تحد تكلفة توجيه الرسائل من الأداء. تلعب خدمة Azure Web PubSub دورا كوسيط رسائل، والذي يوجه الرسالة بين مجموعة من العملاء. يتطلب سيناريو أو واجهة برمجة تطبيقات مختلفة نهج توجيه مختلف.
بالنسبة إلى echo، يرسل العميل رسالة إلى المصدر، ويعيد المصدر صدى الرسالة مرة أخرى إلى العميل. يحتوي هذا النمط على أقل تكلفة للتوجيه. ولكن للبث والإرسال إلى المجموعة والإرسال إلى الاتصال، تحتاج خدمة Azure Web PubSub إلى البحث عن الاتصالات الهدف من خلال بنية البيانات الموزعة الداخلية. تستخدم هذه المعالجة الإضافية المزيد من وحدة المعالجة المركزية والذاكرة وعرض النطاق الترددي للشبكة. ونتيجة لذلك، يكون الأداء أبطأ.
باختصار، تؤثر العوامل التالية على السعة الواردة والصادرة:
حجم الوحدة (وحدة المعالجة المركزية/الذاكرة)
الحد الأقصى لعدد الاتصالات
حجم الرسالة
معدل إرسال الرسالة
سيناريو حالة الاستخدام (تكلفة التوجيه)
العثور على حجم وحدة مناسب
كيف يمكنك تقييم السعة الواردة/الصادرة أو العثور على حجم الوحدة المناسب لحالة استخدام معينة؟
يحتوي كل حجم وحدة على الحد الأقصى للنطاق الترددي الوارد والنطاق الترددي الصادر. لا يتم ضمان تجربة مستخدم سلسة بعد تجاوز نسبة استخدام الشبكة الواردة أو الصادرة الحد.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- الواردة الاتصال: عدد الاتصالات التي ترسل الرسالة.
- الصادر الاتصال: عدد الاتصالات التي تتلقى الرسالة.
- messageSize: حجم رسالة واحدة (متوسط القيمة). رسالة صغيرة أقل من 1024 بايت لها تأثير على الأداء مشابه لرسالة 1024 بايت.
- sendInterval: الفاصل الزمني لإرسال الرسائل. على سبيل المثال، تعني ثانية واحدة إرسال رسالة واحدة كل ثانية. يعني الفاصل الزمني الأصغر إرسال المزيد من الرسائل في فترة زمنية. على سبيل المثال، تعني 0.5 ثانية إرسال رسالتين كل ثانية.
- الاتصال: الحد الأقصى الملتزم به لخدمة Azure Web PubSub لكل حجم وحدة. يتم تقييد الاتصال التي تتجاوز الحد.
افترض أن المصدر قوي بما فيه الكفاية وليس ازدحام الأداء. ثم تحقق من الحد الأقصى للنطاق الترددي الوارد والصادر لكل حجم وحدة.
دراسة حالة
تمر الأقسام التالية بثلاث حالات استخدام نموذجية: إرسال إلى المجموعات من خلال Web PubSub subprotocol، وتشغيل CloudEvent، استدعاء rest api. لكل سيناريو، يسرد القسم السعة الواردة والصادرة الحالية لخدمة Azure Web PubSub. كما يشرح العوامل الرئيسية التي تؤثر على الأداء.
في جميع حالات الاستخدام، يكون حجم الرسالة الافتراضي 2048 بايت، والفاصل الزمني لإرسال الرسالة هو ثانية واحدة.
إرسال إلى المجموعات من خلال البروتوكول الفرعي Web PubSub
تدعم الخدمة البروتوكول الفرعي المحدد المسمى json.webpubsub.azure.v1، والذي يمكن العملاء من النشر/ الاشتراك مباشرة بدلا من رحلة ذهابا وإيابا إلى الخادم المصدر. هذا السيناريو فعال حيث لا يتم تضمين أي خادم وتنتقل جميع نسبة استخدام الشبكة عبر اتصال WebSocket لخدمة العميل.
عدد أعضاء المجموعة والمجموعة هما عاملان يؤثران على الأداء. لتبسيط التحليل، نحدد نوعين من المجموعات:
- المجموعة الكبيرة: رقم المجموعة هو دائما 10. عدد أعضاء المجموعة يساوي (الحد الأقصى لعدد الاتصالات) / 10. على سبيل المثال، بالنسبة للوحدة 1، إذا كان هناك 1000 عدد اتصال، فسيكون لكل مجموعة 1000 / 10 = 100 عضو.
- مجموعة صغيرة: كل مجموعة لديها 10 اتصالات. رقم المجموعة يساوي (الحد الأقصى لعدد الاتصالات) / 10. على سبيل المثال، بالنسبة للوحدة 1، إذا كان هناك 1000 عدد اتصال، فسيكون لدينا 1000 / 10 = 100 مجموعة.
يوفر الإرسال إلى المجموعة تكلفة توجيه إلى خدمة Azure Web PubSub لأنه يجب عليه العثور على الاتصالات الهدف من خلال بنية بيانات موزعة. مع زيادة اتصالات الإرسال، تزداد التكلفة.
مجموعة كبيرة
للإرسال إلى مجموعة كبيرة، يصبح النطاق الترددي الصادر هو الازدحام قبل الوصول إلى حد تكلفة التوجيه. يسرد الجدول التالي الحد الأقصى للنطاق الترددي الصادر.
| إرسال إلى مجموعة كبيرة | الوحدة 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 | 1,000 | 5,000 | 10,000 | 5,000 | 10,000 | 20,000 |
| عدد المجموعات | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| الرسائل الواردة في الثانية | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| النطاق الترددي الوارد | 60 كيلوبايت الثانية | 60 كيلوبايت الثانية | 60 كيلوبايت الثانية | 60 كيلوبايت الثانية | 60 كيلوبايت الثانية | 60 كيلوبايت الثانية | 60 كيلوبايت الثانية | 60 كيلوبايت الثانية |
| الرسائل الصادرة في الثانية | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| النطاق الترددي الصادر | 6 ميغابت في الثانية | 12 ميغابت في الثانية | 60 ميغابت في الثانية | 300 ميغابت في الثانية | 600 ميغابت في الثانية | 1200 ميغابت في الثانية | 3000 ميغابت في الثانية | 6000 ميغابت في الثانية |
مجموعة صغيرة
تكلفة التوجيه كبيرة لإرسال رسالة إلى العديد من المجموعات الصغيرة. حاليا، يصل تنفيذ خدمة Azure Web PubSub إلى حد تكلفة التوجيه عند الوحدة 50. إضافة المزيد من وحدة المعالجة المركزية والذاكرة لا يساعد، لذلك لا يمكن أن تتحسن الوحدة 100 بشكل أكبر حسب التصميم. إذا كنت بحاجة إلى المزيد من النطاق الترددي الوارد، فاحتاج إلى التوسع لاستخدام Premium_P2 (الوحدة >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 ميغابت في الثانية | 1000 ميغابت في الثانية | 2000 ميغابت في الثانية |
إشعار
عدد المجموعات، عدد أعضاء المجموعة المدرجة في الجدول ليست حدودا صعبة. يتم تحديد قيم المعلمات هذه لإنشاء سيناريو معيار ثابت.
تشغيل حدث السحابة
تقدم الخدمة أحداث العميل إلى خطاف الويب المصدر باستخدام بروتوكول CloudEvents HTTP.
لكل حدث، يقوم بصياغة طلب HTTP POST إلى المصدر المسجل ويتوقع استجابة HTTP.
إشعار
يدعم Web PubSub أيضا HTTP 2.0 للأحداث الأولية التي تقدم. يتم اختبار النتيجة أدناه باستخدام HTTP 1.1. إذا كان خادم التطبيق يدعم HTTP 2.0، فسيكون الأداء أفضل.
صدي
في هذه الحالة، يقوم خادم التطبيق بإعادة كتابة الرسالة الأصلية مرة أخرى في استجابة http. يحدد سلوك 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 |
| الرسائل الواردة/الصادرة في الثانية | 500 | 1,000 | 5,000 | 25,000 | 50,000 | 100,000 | 250,000 | 500,000 |
| النطاق الترددي الوارد/الصادر | 1 ميغابت في الثانية | 2 ميغابت في الثانية | 10 ميغابت في الثانية | 50 ميغابت في الثانية | 100 ميغابت في الثانية | 200 ميغابت في الثانية | 500 ميغابت في الثانية | 1000 ميغابت في الثانية |
واجهة برمجة تطبيقات REST
يوفر Azure Web PubSub واجهات برمجة تطبيقات قوية لإدارة العملاء وتقديم رسائل في الوقت الحقيقي.
إرسال إلى المستخدم من خلال واجهة برمجة تطبيقات REST
يعين المعيار أسماء المستخدمين لجميع العملاء قبل أن يبدأوا في الاتصال بخدمة Azure Web PubSub.
| إرسال إلى المستخدم من خلال واجهة برمجة تطبيقات 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 |
| الرسائل الواردة/الصادرة في الثانية | 180 | 360 | 1800 | 9,000 | 18,000 | 36000 | 90,000 | 180,000 |
| النطاق الترددي الوارد/الصادر | 360 كيلوبايت في الثانية | 720 كيلوبايت في الثانية | 3.6 ميغابت في الثانية | 18 ميغابت في الثانية | 36 ميغابت في الثانية | 72 ميغابت في الثانية | 180 ميغابت في الثانية | 360 ميغابت في الثانية |
البث من خلال واجهة برمجة تطبيقات REST
النطاق الترددي هو نفس النطاق الترددي للإرسال إلى مجموعة كبيرة.
| البث من خلال واجهة برمجة تطبيقات 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 |
| الرسائل الواردة في الثانية | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| الرسائل الصادرة في الثانية | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| النطاق الترددي الوارد | 6 كيلوبايت ps | 6 كيلوبايت ps | 6 كيلوبايت ps | 6 كيلوبايت ps | 6 كيلوبايت ps | 6 كيلوبايت ps | 6 كيلوبايت ps | 6 كيلوبايت ps |
| النطاق الترددي الصادر | 6 ميغابت في الثانية | 12 ميغابت في الثانية | 60 ميغابت في الثانية | 300 ميغابت في الثانية | 600 ميغابت في الثانية | 1200 ميغابت في الثانية | 3000 ميغابايت | 6000 ميغابايت |
الخطوات التالية
استخدم هذه الموارد لبدء إنشاء التطبيق الخاص بك: