مشاركة عبر

الرسائل والاتصالات في خدمة Azure SignalR

  • مقالة

يستند نموذج الفوترة لخدمة Azure SignalR إلى عدد الاتصالات وعدد الرسائل الصادرة من الخدمة. تشرح هذه المقالة كيفية تعريف الرسائل والاتصالات واحصاءها للفوترة.

تنسيقات الرسائل

تدعم خدمة Azure SignalR نفس تنسيقات ASP.NET Core SignalR: JSON و MessagePack.

حجم الرسالة

تنطبق الحدود التالية على رسائل خدمة Azure SignalR:

  • رسائل العميل:
    • بالنسبة للأحداث الطويلة من جانب الخادم أو الاستقصاء، لا يمكن للعميل إرسال رسائل أكبر من 1 ميغابايت.
    • لا يوجد حد لحجم WebSocket للخدمة.
    • يمكن لخادم التطبيق تعيين حد لحجم رسالة العميل. الافتراضي هو 32 كيلوبايت. لمزيد من المعلومات، راجع اعتبارات الأمان في ASP.NET Core SignalR.
    • بالنسبة إلى بلا خادم، يكون حجم الرسالة محدودا من خلال تنفيذ المصدر، ولكن يوصى باستخدام أقل من 1 ميغابايت.
  • رسائل الخادم:
    • لا يوجد حد لحجم رسالة الخادم، ولكن يوصى باستخدام أقل من 16 ميغابايت.
    • يمكن لخادم التطبيق تعيين حد لحجم رسالة العميل. الافتراضي هو 32 كيلوبايت. لمزيد من المعلومات، راجع اعتبارات الأمان في ASP.NET Core SignalR.
    • بلا خادم:
      • Rest API: 1 ميغابايت لنص الرسالة، 16 كيلوبايت للرؤوس.
      • لا يوجد حد ل WebSocket، إدارة SDK persis وضع الخيمة، ولكن يوصى أقل من 16 ميغابايت.

بالنسبة لعملاء WebSocket، يتم تقسيم الرسائل الكبيرة إلى رسائل أصغر لا تزيد عن 2 كيلوبايت لكل منها ويتم إرسالها بشكل منفصل. تتعامل SDKs مع تقسيم الرسائل وتجميعها. لا توجد حاجة إلى جهود المطور.

تؤثر الرسائل الكبيرة سلبا على أداء المراسلة. استخدم رسائل أصغر كلما أمكن، واختبر لتحديد الحجم الأمثل للرسالة لكل سيناريو حالة استخدام.

كيفية حساب الرسائل للفوترة

الرسائل المرسلة إلى الخدمة هي رسائل واردة والرسائل المرسلة خارج الخدمة هي رسائل صادرة. يتم حساب الرسائل الصادرة فقط من خدمة Azure SignalR للفوترة. يتم تجاهل رسائل Ping بين العملاء والخوادم.

يتم حساب الرسائل التي يزيد حجمها عن 2 كيلوبايت كرسائل متعددة تبلغ 2 كيلوبايت لكل منها. يتم تحديث مخطط عدد الرسائل في مدخل Microsoft Azure كل 100 رسالة لكل مركز.

على سبيل المثال، تخيل أن لديك خادم تطبيق واحد وثلاثة عملاء:

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

  • عندما يرسل العميل A رسالة واردة 1 كيلوبايت إلى العميل B، دون المرور عبر خادم التطبيق، تكون الرسالة رسالة واردة مجانية. تتم فوترة الرسالة التي يتم توجيهها من الخدمة إلى العميل B كرسالة صادرة.

  • عندما يرسل عميل واحد رسالة 4 كيلوبايت لبث الخادم إلى جميع العملاء، وهناك ثلاثة عملاء وخادم تطبيق واحد، يكون عدد الرسائل المفوترة ثمانية:

    • رسالة واحدة من الخدمة إلى خادم التطبيق.
    • ثلاث رسائل من الخدمة إلى العملاء. يتم حساب كل رسالة كرسالتين 2 كيلوبايت.

كيفية حساب الاتصالات

تقوم خدمة Azure SignalR بإنشاء خادم التطبيق واتصالات العميل. بشكل افتراضي، يبدأ كل خادم تطبيق بخمسة اتصالات أولية لكل مركز، ولكل عميل اتصال عميل واحد.

على سبيل المثال، افترض أن لديك خادمي تطبيق وتعريف خمسة مراكز في التعليمات البرمجية. عدد اتصالات الخادم هو 50: (خادمان للتطبيق * 5 مراكز * 5 اتصالات لكل مركز).

يتضمن عدد الاتصالات الموضح في مدخل Microsoft Azure اتصالات الخادم والعميل والتشخيص والتتبع المباشر. يتم تعريف أنواع الاتصال في القائمة التالية:

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

لا يتم حساب اتصال التتبع المباشر كاتصال عميل أو كاتصال خادم.

يحسب ASP.NET SignalR اتصالات الخادم بطريقة مختلفة. يتضمن لوحة وصل افتراضية واحدة بالإضافة إلى المراكز التي تحددها. بشكل افتراضي، يحتاج كل خادم تطبيق إلى خمسة اتصالات خادم أولية أخرى. يظل عدد الاتصال الأولي للمركز الافتراضي متسقا مع المراكز الأخرى.

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