يقيس اختبار زمن استجابة Redis هذا المدة التي يستغرقها كل من HotKV وRedis وValkey وDragonfly للرد عند معدل طلبات ثابت. كانت اختباراتنا السابقة تقيس الإنتاجية، وأشار أحد القراء عن حق إلى أن الإنتاجية ليست كل شيء. لذلك أبقينا الحمل ثابتًا ورفعناه خطوة بعد خطوة، وسجّلنا الوسيط (p50) والمئين التاسع والتسعين (p99) عند كل خطوة. وقسنا أيضًا زمن تسليم pub/sub.
باختصار. في اختبار زمن استجابة Redis هذا على AWS، حافظ HotKV وDragonfly كلاهما على 1.6 مليون عملية GET في الثانية، وحافظ Redis بثمانية خيوط I/O على نحو 0.8 مليون، وValkey بثمانية خيوط I/O على نحو 0.4 مليون، وRedis وValkey بخيط واحد على نحو 0.2 مليون. من 200,000 إلى 1.6 مليون طلب في الثانية بقي p99 لـ HotKV بين 0.59 و0.76 مللي ثانية، مقابل 0.71 إلى 1.48 لـ Dragonfly. عند الحمل الخفيف تعادلت المنتجات متعددة الخيوط في p99، وكان تسليم pub/sub متعادلًا كذلك.
لماذا أجرينا اختبار زمن استجابة Redis بمعدل ثابت
يدفع اختبار الإنتاجية الخادم إلى أقصى ما يستطيع ويذكر كم خدم. وهذا لا يقول الكثير عن المدة التي ينتظرها طلب واحد. أما اختبار زمن الاستجابة فيثبّت عدد الطلبات التي يرسلها العملاء في الثانية ويقيس الزمن الذي يستغرقه كل طلب. عندها يكون الخادم تحت الحمل نفسه الذي يتحمله أي منتج آخر، فيمكن مقارنة الأزمنة.
لهذا النوع من الاختبارات مأزق. فـ memtier_benchmark أداة ذات حلقة مغلقة، أي أن العميل ينتظر الرد قبل أن يرسل الطلب التالي. إذا لم يستطع الخادم المواكبة، يرسل العميل طلبات أقل ببساطة، ويبدو زمن استجابة ما أرسله أفضل مما ينبغي. لذلك لا نعدّ الخطوة مستدامة إلا إذا كان المعدل المتحقق 97 بالمئة على الأقل من المعدل المطلوب. وتُوسم الخطوات التي تفشل في هذا الاختبار بـ «NS» (غير مستدام) في الجداول، ولا نعرض زمن استجابتها.
ما الذي اختبرناه
الأجهزة
- الخوادم ومولّد الحمل. نسخ
c8a.12xlarge(AMD EPYC 9R45، 48 نواة، بلا SMT، 96 جيبيبايت، شبكة 22.5 جيجابت/ث) في مجموعة وضع عنقودي على AWS في eu-south-2a، بنظام Ubuntu 24.04. شغّلت نسخة واحدة مولّد الحمل وشغّلت الأخرى الخادم. - منتج واحد في كل مرة. شُغّل كل منتج وحده على الخادم، فلم يتداخل شيء ولم يتشارك أي شيء الشبكة. وكانت كل عملية خادم مثبّتة على المعالجات من 0 إلى 39، مع تعطيل الاستمرارية والوضع المحمي.
المنتجات
- HotKV 0.3.0 بـ 40 خيطًا.
- Dragonfly 2.0.2 بـ 40 خيط proactor.
- Redis 8.10.3 وValkey 9.1.3، شُغّل كل منهما مرتين، مرة بالإعداد الافتراضي بخيط واحد ومرة مع
--io-threads 8.
حُفظ سطر التشغيل والمخرجات الحية لأمر CONFIG GET لكل تشغيل مع نتائجه.
الحمل والإجراء
كانت مجموعة البيانات 1,000,000 مفتاح بقيم حجمها 256 بايت، وعمق خط الأنابيب 1، فينتظر كل طلب ردّه. وكان الحمل GET فقط، ومزيجًا من كتابة واحدة لكل 10 قراءات. استغرقت كل خطوة 20 ثانية، مرتين، ونعرض متوسط التشغيلين. استخدم memtier_benchmark حدّ معدل لكل اتصال وسجّل مخطط HDR. جرّبنا عددين من الاتصالات.
- 816 اتصالًا (24 خيطًا بـ 34 اتصالًا لكل منها)، لمعدلات من 20,000 إلى 2.4 مليون طلب في الثانية.
- 48 اتصالًا (4 خيوط بـ 12 اتصالًا لكل منها)، لمعدلات تصل إلى 300,000 طلب في الثانية. وفوق ذلك لا تستطيع 48 اتصالًا بلوغ المعدل، لأن كل اتصال لا يرسل أسرع مما يتلقى من ردود.
النتائج
تأتي أولًا جداول GET، جدول لكل عدد من الاتصالات، ثم pub/sub.
عند 816 اتصالًا
تعرض كل خلية p50 / p99 بالمللي ثانية، لعملية GET. تعني «NS» غير مستدام، ويظهر بين القوسين المعدل الذي بلغه فعلًا. وتعني الشرطة أن مسح ذلك المنتج كان قد توقف.
| طلب/ث | HotKV | Dragonfly | Redis بخيط واحد | Redis بـ 8 خيوط I/O | Valkey بخيط واحد | Valkey بـ 8 خيوط I/O |
|---|---|---|---|---|---|---|
| 19,584 | 0.38 / 1.81 | 0.48 / 1.90 | 1.63 / 5.29 | 0.68 / 2.07 | 1.59 / 5.13 | 0.76 / 2.63 |
| 99,552 | 0.24 / 0.76 | 0.27 / 1.76 | 2.60 / 5.12 | 0.40 / 0.98 | 2.65 / 5.13 | 1.71 / 3.19 |
| 199,920 | 0.25 / 0.59 | 0.25 / 1.34 | 2.91 / 5.60 | 0.55 / 1.11 | 3.02 / 5.81 | 1.11 / 2.15 |
| 399,840 | 0.27 / 0.63 | 0.27 / 1.48 | NS (258k) | 0.62 / 1.23 | NS (259k) | 1.24 / 1.49 |
| 799,680 | 0.28 / 0.75 | 0.28 / 1.26 | - | 0.68 / 1.18 | - | NS (670k) |
| 1,199,520 | 0.28 / 0.67 | 0.28 / 1.05 | - | NS (1,078k) | - | - |
| 1,599,360 | 0.28 / 0.64 | 0.28 / 0.71 | - | - | - | - |
| 2,399,856 | NS (2,284k) | NS (2,281k) | - | - | - | - |
أعطى الحمل المختلط الصورة نفسها. كان p99 لـ HotKV بين 0.54 و0.75 مللي ثانية من 200,000 إلى 1.6 مليون طلب في الثانية، وكانت النقاط التي استطاع كل منتج الحفاظ عليها هي نفسها في GET. كل ذلك في مجلد النتائج.
كيف تُقرأ صفوف الخيط الواحد
الأوساط التي تتراوح بين 1.6 و3 مللي ثانية لـ Redis وValkey بخيط واحد عند 816 اتصالًا ليست زمن استجابتهما في الحالة المستقرة. فمع حدّ المعدل يجعل memtier_benchmark جميع الاتصالات الـ 816 تنطلق في اللحظة نفسها. وعلى الخادم ذي الخيط الواحد أن يعالج هذه الدفعة من 816 طلبًا واحدًا بعد الآخر، فيتضمن وسيط الطلب مكانه في الطابور. أجرينا اختبار الـ 48 اتصالًا أدناه لإزالة هذا الأثر.
عند 48 اتصالًا
للخلايا المعنى نفسه كما في الأعلى، لعملية GET فقط.
| طلب/ث | HotKV | Dragonfly | Redis بخيط واحد | Redis بـ 8 خيوط I/O | Valkey بخيط واحد | Valkey بـ 8 خيوط I/O |
|---|---|---|---|---|---|---|
| 9,984 | 0.14 / 0.54 | 0.14 / 0.37 | 0.21 / 0.89 | 0.17 / 0.92 | 0.21 / 0.91 | 0.20 / 0.81 |
| 49,968 | 0.10 / 0.28 | 0.11 / 0.28 | 0.21 / 0.41 | 0.13 / 0.28 | 0.21 / 0.43 | 0.21 / 0.44 |
| 99,984 | 0.09 / 0.28 | 0.10 / 0.28 | 0.20 / 0.40 | 0.13 / 0.28 | 0.20 / 0.38 | 0.19 / 0.35 |
| 199,968 | 0.08 / 0.27 | 0.08 / 0.27 | 0.20 / 0.35 | 0.10 / 0.27 | 0.21 / 0.36 | 0.11 / 0.28 |
| 300,000 | 0.08 / 0.27 | 0.08 / 0.27 | NS (231k) | 0.09 / 0.26 | NS (233k) | 0.09 / 0.26 |
زمن تسليم pub/sub
قسنا الزمن من النشر حتى التسليم إلى مشترك، مع 64 ناشرًا و100 مشترك وحمولة 128 بايت، باستخدام pubsub-sub-bench. ذهبت كل رسالة إلى مشترك واحد. تعرض الخلايا p50 / p99 بالمللي ثانية.
| تسليم/ث | HotKV | Dragonfly | Redis بخيط واحد | Redis بـ 8 خيوط I/O | Valkey بخيط واحد | Valkey بـ 8 خيوط I/O |
|---|---|---|---|---|---|---|
| حوالي 21,000 | 0.10 / 0.71 | 0.10 / 0.65 | 0.11 / 0.74 | 0.11 / 0.62 | 0.11 / 0.76 | 0.12 / 0.78 |
| حوالي 107,000 | 0.10 / 1.02 | 0.12 / 0.92 | 0.10 / 0.80 | 0.11 / 0.63 | 0.10 / 0.82 | 0.10 / 0.86 |
| حوالي 215,000 | 0.11 / 1.20 | 0.13 / 1.13 | 0.51 / 1.03 | 0.20 / 0.73 | 0.57 / 1.07 | 0.12 / 1.22 |
سلّمت جميع المنتجات ضمن النطاق نفسه. وعند أعلى حمل كان وسيط المنتجات ذات الخيط الواحد أعلى، 0.51 و0.57 مللي ثانية مقابل 0.11 لـ HotKV.
اضطررنا أيضًا إلى ترقيع pubsub-sub-bench. كانت الأداة تقارن زمن نشر بالمللي ثانية بزمن استلام بالميكرو ثانية. والرقعة موجودة في مجلد النتائج.
ماذا تُظهر النتائج
تُظهر الجداول تقدّمًا لـ HotKV وDragonfly عند الحمل العالي، وتعادلًا عند الحمل الخفيف، وسقفًا لـ Redis وValkey بخيط واحد.
حافظ HotKV وDragonfly على ذيل منخفض حتى 1.6 مليون طلب في الثانية
حافظ كلاهما على 1.6 مليون عملية GET في الثانية عند 816 اتصالًا، بوسيط 0.28 مللي ثانية. وكان p99 لـ HotKV بين 0.59 و0.76 مللي ثانية من 200,000 طلب في الثانية فصاعدًا. وكان لـ Dragonfly بين 0.71 و1.48، وتقارب الاثنان عند 1.6 مليون (0.64 مقابل 0.71 مللي ثانية). أما Redis وValkey بخيوط I/O فلم يعودا يحافظان على المعدل عند أحمال أقل، وRedis وValkey بخيط واحد عند نحو 260,000.
عند الحمل الخفيف تتعادل المنتجات متعددة الخيوط
عند 48 اتصالًا وحتى 300,000 طلب في الثانية، كان p99 لكل من HotKV وDragonfly وRedis بثمانية خيوط I/O نحو 0.27 مللي ثانية. وكان لـ HotKV أدنى وسيط، من 0.08 إلى 0.09 مللي ثانية من 100,000 طلب في الثانية فصاعدًا، ولـ Dragonfly من 0.08 إلى 0.10. فرق 0.01 مللي ثانية يقع ضمن ما قد تسببه أجزاء أخرى من الإعداد، لذلك لا ندّعيه تفوقًا.
بلغ Redis وValkey بخيط واحد سقفهما عند نحو 230,000 في الثانية
عند 48 اتصالًا كان وسيطهما نحو 0.2 مللي ثانية وp99 بين 0.35 و0.43، ولم يحافظا على 300,000 طلب في الثانية (نحو 231,000 و233,000). هذا هو سقف الخيط الواحد على هذه الأجهزة وبهذا الحمل. ولهذا يُشغَّل Redis وValkey عادةً كعدة عمليات أو كعنقود، كما في اختبار العنقود لدينا.
القيود
هذه قياسات أجرتها HotKV Ltd للإصدارات والإعداد المذكورين أعلاه. وهي ليست ادعاءً بشأن أي إصدار أو إعداد أو حمل آخر لهذه المنتجات.
إعداد الاختبار
- خادم واحد ومولّد حمل واحد. تكرارا الخطوة مرتان، على مجموعة واحدة من الأجهزة في تاريخ واحد. لم نقس التباين بين الأجهزة أو بين الأيام.
- إعدادات اخترناها. شُغّل Redis وValkey بإعدادهما الافتراضي بخيط واحد ومع
--io-threads 8، ولم نضبط أيًّا منهما أبعد من ذلك. قد تغيّر إعدادات أخرى أرقامهما. إذا رأيتم أن إعدادًا هنا يضر بمنتج ما، فـأخبرونا وسنتحقق ونعلن النتيجة. - أثر الدفعة في الأداة. عند 816 اتصالًا تتضخم أوساط المنتجات ذات الخيط الواحد بسبب طريقة عمل حدّ المعدل في
memtier_benchmark، كما شُرح أعلاه.
ما لم يُقَس
- البيانات. قيم أكبر أو منحازة، والذاكرة لكل مفتاح، والاستمرارية. كانت الاستمرارية معطلة على جميع الخوادم.
- الأوضاع. وضع العنقود، وpub/sub المجزأ، وTLS، والتكرار، والتحويل عند الفشل.
- التفرّع في pub/sub. رسالة واحدة إلى مشتركين كثيرين.
Redis وValkey وDragonfly علامات تجارية لأصحابها. وتُذكر فقط لتعريف البرمجيات التي قسناها، ولا يعني ذلك رعاية أو تأييدًا أو انتماءً.
أعد إجراءه بنفسك
نصوص المسح البرمجية، وسطر التشغيل والإعداد الحي لكل خادم، ورقعة pubsub-sub-bench، وجميع النتائج الخام موجودة في مستودع الاختبارات. نص زمن الاستجابة هو harness/lat_sweep.sh، ونص pub/sub هو harness/ps_sweep.sh. ويضم المجلد raw أرشيفًا لكل اختبار فيه JSON الخاص بـ memtier_benchmark ومخططات HDR واستخدام المعالج في الخادم لكل تشغيل.
جرّبه بنفسك
يشغّل HotKV Cloud خادم HotKV نيابةً عنك. ابدأ على HotKV Cloud، أو تحدث إلى المبيعات لمقارنة HotKV بحملك الخاص.
الأسئلة الشائعة
هل HotKV أسرع من Redis في زمن الاستجابة؟
تحت الحمل، وعند المعدلات التي اختبرناها، نعم. عند 816 اتصالًا و200,000 طلب في الثانية كان p99 لـ HotKV 0.59 مللي ثانية، ولـ Redis بثمانية خيوط I/O 1.11، ولـ Redis بخيط واحد 5.60. وعند الحمل الخفيف مع 48 اتصالًا تعادلت المنتجات متعددة الخيوط في p99 عند نحو 0.27 مللي ثانية.
لماذا ثبّتم معدل الطلبات؟
عند معدل ثابت يتحمل كل منتج الحمل نفسه، فيمكن مقارنة أزمنة الاستجابة. يُظهر اختبار الإنتاجية كم يخدم الخادم عند حدّه، وهذا لا يقول الكثير عن المدة التي ينتظرها طلب واحد.
ماذا تعني «غير مستدام»؟
بلغ المنتج أقل من 97 بالمئة من معدل الطلبات الذي طلبناه. memtier_benchmark أداة ذات حلقة مغلقة، فالخادم المثقل يجعل العملاء يرسلون أقل، ويبدو زمن استجابة الطلبات المتبقية أفضل مما هو عليه. لا نعرض زمن استجابة لتلك الخطوات.
كيف كانت مقارنة زمن تسليم pub/sub؟
عند الأحمال الثلاثة التي اختبرناها سلّمت جميع المنتجات ضمن النطاق نفسه، بوسيط نحو 0.1 مللي ثانية عند الحملين الأدنى. وفي الجدول أعلاه كل الأرقام.
هل يمكنني إعادة إجراء اختبار زمن استجابة Redis هذا؟
نعم. النصوص البرمجية والإعدادات وجميع النتائج الخام موجودة في مستودع الاختبارات. تحتاج إلى خادمين على الشبكة نفسها، ومولّد حمل، والمنتجات الأربعة.
تابع النقاش
التعليقات
لديك أسئلة عن المنهجية؟ حصلت على نتيجة مختلفة على عتادك؟ شارك ما توصلت إليه. تُراجَع التعليقات قبل ظهورها.