اختبار الأداء باستخدام Azure Managed Redis

يمكن أن يكون اختبار أداء مثيل Redis مهمة معقدة. يمكن أن يختلف أداء مثيل Redis استنادا إلى معلمات مثل عدد العملاء وحجم قيم البيانات وما إذا كان يتم استخدام الأنابيب. يمكن أن يكون هناك أيضا مقايضة بين تحسين معدل النقل أو زمن الانتقال.

لحسن الحظ، توجد العديد من الأدوات لجعل قياس Redis أسهل. اثنتان من أكثر الأدوات شيوعا هما redis-benchmark و memtier-benchmark . تركز هذه المقالة على memtier_benchmark، وغالبا ما تسمى memtier.

كيفية استخدام الأداة المساعدة memtier_benchmark

1. تثبيت memtier على الأجهزة الظاهرية للعميل (VMs) التي يمكنك استخدامها للاختبار. اتبع وثائق Memtier للحصول على إرشادات حول كيفية تثبيت صورة مصدر مفتوح.

2. يجب أن يكون الجهاز الظاهري للعميل (VM) المستخدم للاختبار في نفس المنطقة مثل مثيل Azure Managed Redis (AMR).

3. تأكد من أن الجهاز الظاهري للعميل الذي تستخدمه يحتوي على أقل قدر من الحوسبة والنطاق الترددي مثل مثيل ذاكرة التخزين المؤقت الذي يتم اختباره.

4. قم بتكوين عزل الشبكة وإعدادات جدار حماية الجهاز الظاهري للتأكد من أن الجهاز الظاهري للعميل قادر على الوصول إلى مثيل Azure Managed Redis.

5. إذا كنت تستخدم TLS/SSL على مثيل ذاكرة التخزين المؤقت، فستحتاج إلى إضافة --tls المعلمتين و --tls-skip-verify إلى أمر memtier_benchmark.

6. memtier_benchmark يستخدم المنفذ 6379 بشكل افتراضي. استخدم المعلمة -p 10000 لتجاوز هذا الإعداد، حيث يستخدم AMR المنفذ 10000 بدلا من ذلك.

7. بالنسبة لجميع مثيلات Azure Managed Redis باستخدام نهج نظام مجموعة OSS، تحتاج إلى إضافة المعلمة --cluster-mode إلى أمر memtier الخاص بك. يمكن التعامل مع مثيلات AMR التي تستخدم نهج مجموعة المؤسسة كذاكرة تخزين مؤقت غير متفاوتة المسافات ولا تحتاج إلى هذا الإعداد.

8. ابدأ من memtier_benchmark CLI أو shell للجهاز الظاهري. للحصول على إرشادات حول كيفية تكوين الأداة وتشغيلها، راجع وثائق Memtier.

توصيات قياس الأداء

• إذا كنت لا تحصل على الأداء الذي تحتاجه، فحاول التوسع إلى مستوى أكثر تقدما. عادة ما تحتوي الطبقة المتوازنة على ضعف عدد وحدات المعالجة المركزية الظاهرية مثل الطبقة المحسنة للذاكرة، وعادة ما تحتوي طبقة الحوسبة المحسنة على ضعف عدد وحدات vCPUs مثل الطبقة المتوازنة. نظرا لأن Azure Managed Redis مبني على Redis Enterprise بدلا من Redis المجتمعي، فإن عملية Redis الأساسية قادرة على استخدام وحدات vCPUs متعددة. ونتيجة لذلك، تتمتع المثيلات التي تحتوي على المزيد من وحدات المعالجة المركزية الظاهرية بأداء معدل نقل أفضل بكثير.

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

• قد يكون قياس مستوى Flash Optimized صعبا لأنه يتم تخزين بعض المفاتيح على DRAM بينما يتم تخزين بعضها على قرص محمول NVMe. المفاتيح على معيار DRAM تقريبا بنفس سرعة مثيلات Azure Managed Redis الأخرى، ولكن المفاتيح الموجودة على القرص الفلاش NVMe أبطأ. نظرا لأن طبقة Flash Optimized تضع المفاتيح الأكثر استخداما بذكاء في DRAM، فتأكد من أن تكوين المعيار الخاص بك يطابق الاستخدام الفعلي الذي تتوقعه.

• يؤدي استخدام TLS/SSL إلى تقليل أداء معدل النقل، ولكن يوصى به بشدة كأفضل ممارسة للإنتاج.

• من الضروري أولا تعبئة مثيل Redis بالبيانات قبل قياس الأداء. ينتج عن قياس الأداء على ذاكرة التخزين المؤقت الفارغة نتائج أفضل بكثير مما قد تراه في الممارسة العملية.

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

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

أمثلة memtier_benchmark

ملاحظة

يوضح هذا المثال القياس على مثيل Compute Optimized X3 باستخدام نهج نظام مجموعة OSS وTLS.

إعداد ما قبل الاختبار: قم بإعداد مثيل ذاكرة التخزين المؤقت بالبيانات المطلوبة للاختبار. يضمن تحميل المثيل بالبيانات أن النتائج تعكس ظروف العالم الحقيقي بشكل أكثر دقة. {number-of-keys} يجب تحديد المعلمة حسب حجم مثيل AMR وحجم كل مفتاح. قاعدة الإبهام الجيدة هي ملء المثيل بالكامل بنسبة 75٪ تقريبا، مما يمثل المخازن المؤقتة. يمكنك استخدام هذه الصيغة: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). على سبيل المثال، إذا كنت تقوم بالمعيار على مثيل Compute Optimized X3، باستخدام أحجام مفاتيح 1024 بايت، كما هو موضح سابقا، فإن ذلك يعني {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). تساوي النتيجة حوالي 1,699,396 مفتاحا.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 --clients=50 --threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 --data-size=1024 --tls --cluster-mode

ملاحظة

يستخدم --tls--tls-skip-verifyهذا المثال العلامات و و--cluster-mode. لا تحتاج إلى هذه إذا كنت تستخدم Azure Managed Redis في وضع غير TLS أو إذا كنت تستخدم نهج مجموعة المؤسسة، على التوالي.

لاختبار معدل النقل: يختبر هذا الأمر طلبات GET ذات الحمولة 1k. استخدم هذا الأمر لاختبار مقدار معدل نقل القراءة المتوقع من مثيل ذاكرة التخزين المؤقت. يفترض هذا المثال أنك تستخدم TLS ونهج نظام مجموعة OSS. --key-pattern=R:R تضمن المعلمة الوصول العشوائي إلى المفاتيح، ما يزيد من واقعية المعيار. يعمل هذا الاختبار لمدة خمس دقائق.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 --clients=50 --threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

مثال على بيانات معيار الأداء

يوضح الجدول أدناه الإنتاجية المثلى التي لاحظناها أثناء اختبار أحجام مختلفة من مثيلات Azure Managed Redis مع حمل عمل لجميع أوامر القراءة وحمولة 1 كيلوبايت. حمل العمل هو نفسه عبر جميع وحدات SKU، باستثناء عدد الاتصال (أي مؤشر ترابط مختلف وعدد العملاء كما هو مطلوب من قبل memtier_benchmark). يتم اختيار عدد الاتصال لكل SKU للاستفادة من مثيل Azure Managed Redis على النحو الأمثل. استخدمنا memtier_benchmark من IaaS Azure VM مقابل نقطة نهاية Azure Managed Redis، باستخدام أوامر memtier الموضحة في قسم أمثلة memtier_benchmark. أرقام معدل النقل مخصصة لأوامر GET فقط. عادة ما يكون لأوامر SET معدل نقل أقل. يختلف أداء العالم الحقيقي استنادا إلى تكوين Redis والأوامر. يتم توفير هذه الأرقام كنقطة مرجعية، وليس ضمانا.

تنبيه

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

مهم

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

يوفر Azure Managed Redis خيارا لنهج نظام المجموعة: Enterprise وOSS. نهج مجموعة المؤسسات هو تكوين أبسط لا يتطلب من العميل دعم التجميع. من ناحية أخرى، يستخدم نهج نظام مجموعة OSS بروتوكول نظام مجموعة Redis لدعم معدل نقل أعلى. نوصي باستخدام نهج نظام مجموعة OSS في معظم الحالات، خاصة عندما تحتاج إلى أداء عال. لمزيد من المعلومات، راجع تكوين أنظمة المجموعات.

الحجم بالجيجابايت	طلبات GET في الثانية للذاكرة المحسنة	طلبات GET في الثانية للمتوازن	طلبات GET في الثانية للحوسبة المحسنة
0.5	-	120,000	-
1	-	120,000	-
3	-	230,000	480,000
6	-	230,000	480,000
12	230,000	480,000	810,000
24	480,000	810,000	1,600,000
60	810,000	1,500,000	2,000,000
120	1,500,000	2,000,000	2,900,000

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

الحجم بالجيجابايت	العملاء/مؤشرات الترابط/عدد الاتصالات للذاكرة المحسنة	العملاء/مؤشرات الترابط/عدد الاتصالات لتحقيق التوازن	العملاء/مؤشرات الترابط/عدد الاتصالات للحوسبة المحسنة
0.5	-	10/4/40	-
1	-	10/4/40	-
3	-	10/4/40	10/8/80
6	-	10/4/40	10/8/80
12	10/4/40	10/8/80	10/16/160
24	10/8/80	10/16/160	20/16/320
60	10/16/160	20/16/320	20/32/640
120	20/16/320	20/32/640	20/64/1280

الخطوات التالية

• التطوير
• الأسئلة المتداولة حول تطوير Azure Cache for Redis
• تجاوز الفشل والتصحيح لـ Azure Cache لـ Redis