توفر هذه المقالة إجابات على الأسئلة الشائعة حول كيفية إدارة Azure Managed Redis.
متى يجب أن أقوم بتمكين منفذ غير TLS / SSL للاتصال بـ Redis؟
يوصى باستخدام TLS كأفضل ممارسة عبر جميع حالات استخدام Redis تقريبا. يتم تضمين خيار الاتصال بدون TLS لأغراض التوافق مع الإصدارات السابقة.
ما هي بعض أفضل ممارسات الإنتاج؟
أفضل ممارسات StackExchange.Redis
- اضبط
AbortConnectعلى خطأ، ثم دع ConnectionMultiplexer يعيد الاتصال تلقائيًا. - استخدم مثيلاً واحداً طويل المدة
ConnectionMultiplexerبدلاً من إنشاء اتصال جديد لكل طلب. - يعمل Redis بشكل أفضل مع القيم الأصغر، لذا ضع في اعتبارك تقطيع البيانات الأكبر إلى مفاتيح متعددة. في مناقشة Redis، تعتبر 100 كيلوبايت كبيرة. لمزيد من المعلومات، راجع تطوير أفضل الممارسات.
- قم بتكوين إعدادات ThreadPool لتجنب المهلات.
- استخدم مهلة الاتصال الافتراضية التي تبلغ 5 ثوانٍ على الأقل. يمنح هذا الفاصل الزمني StackExchange.ed وقتًا كافيًا لإعادة إنشاء الاتصال إذا كان هناك إشارة ضوئية للشبكة.
- كن على دراية بتكاليف الأداء المرتبطة بالعمليات المختلفة التي تقوم بتشغيلها. على سبيل المثال، الأمر
KEYSهو عملية O (n) ويجب تجنبه. يحتوي موقع redis.io على تفاصيل حول التعقيد الزمني لكل عملية يدعمها. حدد كل أمر لمعرفة مدى تعقيد كل عملية.
التكوين والمفاهيم
- تذكَّر أن Redis عبارة عن مخزن بيانات مضمّن في الذاكرة. لمزيد من المعلومات، راجع استكشاف أخطاء فقدان البيانات وإصلاحها في Azure Managed Redis بحيث تكون على دراية بالسيناريوهات التي يمكن أن يحدث فيها فقدان البيانات.
- طوِّر نظامك بحيث يمكنه التعامل مع الإشارات الضوئية للاتصال الناتجة عن التصحيح وتجاوز الفشل.
اختبار الأداء
- راجع اختبار الأداء باستخدام Azure Managed Redis للحصول على أمثلة على معايير وإرشادات لتشغيل اختبارات الأداء الخاصة بك على Azure Managed Redis.
ما هي بعض الاعتبارات عند استخدام أوامر Redis الشائعة؟
- تجنب استخدام أوامر Redis معينة تستغرق وقتًا طويلاً لإكمالها، إلا إذا كنت تفهم تمامًا نتيجة هذه الأوامر. على سبيل المثال، لا تقم بتشغيل الأمر KEYS في الإنتاج. اعتمادًا على عدد المفاتيح، قد يستغرق الأمر وقتًا طويلاً للعودة. كل جزء Redis عبارة عن جزء مترابط واحد، ويعالج الأوامر واحدا تلو الآخر. إذا كانت لديك أوامر أخرى تم إصدارها بعد KEYS، فلن تتم معالجتها حتى يعالج Redis الأمر KEYS. يحتوي موقع redis.io على تفاصيل حول التعقيد الزمني لكل عملية يدعمها. حدد كل أمر لمعرفة مدى تعقيد كل عملية.
- أحجام المفاتيح - هل يجب أن أستخدم مفاتيح / قيمًا صغيرة أم مفتاحًا / قيمًا كبيرة؟ ذلك يعتمد على السيناريو. إذا كان السيناريو الخاص بك يتطلب مفاتيح أكبر، فيمكنك ضبط ConnectionTimeout، ثم إعادة محاولة القيم وضبط منطق إعادة المحاولة. من منظور خادم Redis، تعطي القيم الأصغر أداءً أفضل.
- لا تعني هذه الاعتبارات أنه لا يمكنك تخزين قيم أكبر في Redis، يجب أن تكون على دراية بالاعتبارات التالية. زمن الانتقال أعلى. إذا كان لديك مجموعة واحدة من البيانات أكبر وأخرى أصغر، يمكنك استخدام مثيلات ConnectionMultiplexer متعددة. قم بتكوين كل منها بمجموعة مختلفة من قيم المهلة وإعادة المحاولة، كما هو موضح في القسم السابق ماذا يفعل خيارات تكوين StackExchange.Redis .
كيف يمكنني قياس أداء ذاكرة التخزين المؤقت واختبارها؟
- قم بتمكين تشخيصات ذاكرة التخزين المؤقت حتى تتمكن من مراقبة صحة ذاكرة التخزين المؤقت الخاصة بك. يمكنك عرض المقاييس في مدخل Microsoft Azure ويمكنك أيضًا تنزيلها ومراجعتها باستخدام الأدوات التي تختارها.
- راجع اختبار الأداء باستخدام Azure Managed Redis للحصول على أمثلة على معايير وإرشادات لتشغيل اختبارات الأداء الخاصة بك على Azure Managed Redis.
تفاصيل مهمة حول نمو ThreadPool
يحتوي CLR ThreadPool على نوعين من مؤشرات الترابط - مؤشرات ترابط منفذ إكمال الإدخال/الإخراجللعامل (IOCP).
- يتم استخدام مؤشرات ترابط العامل لأشياء مثل معالجة طرق
Task.Run(…)أوThreadPool.QueueUserWorkItem(…). يتم استخدام مؤشرات الترابط هذه أيضًا بواسطة مكونات مختلفة في CLR عندما يحتاج العمل إلى أن يحدث على مؤشر ترابط في الخلفية. - يتم استخدام مؤشرات ترابط IOCP عند حدوث IO غير المتزامن، على سبيل المثال، عند القراءة من الشبكة.
يوفر تجمع مؤشرات الترابط مؤشرات ترابط جديدة أو مؤشرات ترابط عمليات إكمال الإدخال/الإخراج عند الطلب (بدون أي تقييد) حتى يصل إلى إعداد "الحد الأدنى" لكل نوع من أنواع مؤشرات الترابط. بشكل افتراضي، يتم تعيين الحد الأدنى لعدد مؤشرات الترابط على عدد المعالجات على النظام.
بمجرد أن يصل عدد مؤشرات الترابط الموجودة (المشغولة) إلى العدد "الأدنى" من مؤشرات الترابط، يخنق ThreadPool المعدل الذي يقوم فيه بإدخال مؤشرات ترابط جديدة إلى مؤشر ترابط واحد لكل 500 مللي ثانية. عادة، إذا حصل النظام الخاص بك على اندفاع من العمل الذي يحتاج إلى مؤشر ترابط IOCP، فإنه يعالج التي تعمل بسرعة. ومع ذلك، إذا كان الاندفاع أكبر من إعداد "الحد الأدنى" الذي تم تكوينه، فهناك بعض التأخير في معالجة بعض الأعمال حيث ينتظر ThreadPool أحد الاحتمالين:
- يصبح مؤشر الترابط الموجود حرًا في معالجة العمل.
- لا يوجد موضوع موجود يصبح مجانيًا لمدة 500 مللي ثانية ويتم إنشاء موضوع جديد.
بشكل أساسي، عندما يكون عدد مؤشرات الترابط مشغول أكبر من مؤشرات ترابط الحد الأدنى، فمن المحتمل أن تدفع تأخيرا قدره 500 مللي ثانية قبل أن يعالج التطبيق نسبة استخدام الشبكة. أيضا، عندما يبقى مؤشر ترابط موجود الخاما لأكثر من 15 ثانية، يتم تنظيفه ويمكن تكرار دورة النمو والانكماش هذه.
إذا نظرنا إلى مثال لرسالة خطأ من StackExchange.Redis (الإصدار 1.0.450 أو أحدث)، فإننا نرى أنه يطبع الآن إحصائيات ThreadPool. راجع تفاصيل IOCP والعامل لاحقا في المقالة.
System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)
كما هو موضح في المثال، ترى أنه بالنسبة لمؤشر ترابط IOCP هناك ستة مؤشرات ترابط مشغولة ويتم تكوين النظام للسماح بأربعة مؤشرات ترابط دنيا. في هذه الحالة، سيرى العميل تأخيرين 500 مللي ثانية، لأن 6 > 4.
ملاحظة
يمكن أن يصل StackExchange.Redis إلى المهلات إذا تم اختناق نمو مؤشرات ترابط IOCP أو العامل.
التوصية
نوصي العملاء بتعيين الحد الأدنى لقيمة التكوين لمؤشرات ترابط IOCP و WORKER إلى شيء أكبر من القيمة الافتراضية. لا يمكننا إعطاء إرشادات واحدة تناسب الجميع حول هذه القيمة لأن القيمة الصحيحة لتطبيق واحد يمكن أن تكون عالية جدا أو منخفضة لتطبيق آخر. يمكن أن يؤثر هذا الإعداد أيضا على أداء الأجزاء الأخرى من التطبيقات المعقدة. يحتاج كل عميل إلى ضبط هذا الإعداد لاحتياجاته المحددة. نقطة البداية الجيدة هي 200 أو 300، ثم اختبرها وعدّلها حسب الحاجة.
كيفية تكوين هذا الإعداد:
نوصي بتغيير هذا الإعداد برمجيا باستخدام أسلوب ThreadPool.SetMinThreads (...) في تطبيقات .NET Framework و.NET Core.
على سبيل المثال، في NET Framework، يمكنك تعيينه في Global.asax.csApplication_Start الأسلوب :
```csharp
private readonly int minThreads = 200;
void Application_Start(object sender, EventArgs e)
{
// Code that runs on application startup
AreaRegistration.RegisterAllAreas();
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
ThreadPool.SetMinThreads(minThreads, minThreads);
}
```
إذا كنت تستخدم .NET Core، يمكنك تعيينه في Program.cs، قبل الاستدعاء إلى WebApplication.CreateBuilder():
```csharp
const int minThreads = 200
ThreadPool.SetMinThreads(minThreads, minThreads);
var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```
ملاحظة
القيمة المحددة بواسطة هذه الطريقة هي إعداد عام، تؤثر على AppDomain بالكامل. على سبيل المثال، إذا كان لديك جهاز بأربعة ذاكرات أساسية وتريد تعيين minWorkerThreads و minIoThreads إلى 50 لكل وحدة معالجة مركزية أثناء وقت التشغيل، فاستخدم ThreadPool.SetMinThreads(200, 200).
من الممكن أيضا تحديد إعداد الحد الأدنى من مؤشرات الترابط باستخدام minIoThreadsminWorkerThreads أو ضمن <processModel> عنصر التكوين في Machine.config. يقع Machine.configعادةً في%SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\.
لا يوصى بتعيين عدد الحد الأدنى لمؤشرات الترابط بهذه الطريقة لأنه إعداد على مستوى النظام. إذا قمت بتعيينه بهذه الطريقة، يجب إعادة تشغيل تجمع التطبيقات.
ملاحظة
القيمة المحددة في عنصر التكوين هذا هي إعداد لكل نواة. على سبيل المثال، إذا كان لديك أربعة جهاز أساسي وتريد أن minIoThreads يكون الإعداد 200 في وقت التشغيل، فاستخدم <processModel minIoThreads="50">.
تمكين خادم GC للحصول على المزيد من معدل النقل على العميل عند استخدام StackExchange.Redis
يمكن أن يؤدي تمكين GC للخادم إلى تحسين العميل وتوفير أداء ومعدل النقل أفضل عند استخدام StackExchange.Redis. لمزيد من المعلومات حول الخادم GC وكيفية تمكينه، راجع المقالات التالية:
اعتبارات الأداء حول الاتصالات
قد يكون لوحدات SKU المختلفة حدود مختلفة لاتصالات العميل والذاكرة وعرض النطاق الترددي. بينما يسمح كل حجم من ذاكرة التخزين المؤقت بعدد يصل إلى بعض الاتصالات، فإن كل اتصال ب Redis له حمل مقترن به. مثال على هذا الحمل هو استخدام وحدة المعالجة المركزية والذاكرة بسبب تشفير TLS / SSL. يفترض حد الاتصال الأقصى لحجم ذاكرة التخزين المؤقت المحدد وجود ذاكرة تخزين مؤقت محملة بشكل خفيف. إذا تجاوز التحميل من حمل الاتصال بالإضافة إلى التحميل من عمليات العميل سعة النظام، يمكن أن تواجه ذاكرة التخزين المؤقت مشكلات في السعة حتى إذا لم تتجاوز حد الاتصال لحجم ذاكرة التخزين المؤقت الحالية.
لمزيد من المعلومات حول حدود الاتصالات المختلفة لكل مستوى، راجع تسعير Azure Managed Redis.
المحتوى ذو الصلة
- تعرف على الأسئلة المتداولة الأخرى حول Azure Managed Redis.