مراقبة واختبار الـ Cache في أنظمة إدارة المحتوى: من HIT Ratio إلى Load Testing

بعد تصميم طبقات الـ Cache وتحديد قواعد الـ TTL والـ invalidation، يبقى السؤال الأهم: كيف تعرف أن الاستراتيجية تعمل فعلًا في الإنتاج؟

وجود Redis وCDN لا يعني تلقائيًا أن النظام أصبح أسرع. قد يكون لديك cache hit ratio منخفض، أو مفاتيح تُطرد باستمرار من الذاكرة، أو صفحات تظل قديمة بعد النشر، أو CDN لا يخزن HTML أصلًا بسبب Header واحد غير مقصود.

هذا الدليل يضع خطة عملية لمراقبة واختبار الـ Cache في أنظمة إدارة المحتوى، من مستوى التطبيق حتى Redis والـ CDN، مع اختبارات يمكن تحويلها مباشرة إلى automated tests أو monitoring dashboards.

1. ابدأ من مؤشرات واضحة، لا من الشعور بأن الموقع «أسرع»

لكل طبقة Cache مجموعة Metrics مختلفة. الحد الأدنى الذي يستحق المتابعة:

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

2. احسب Cache Hit Ratio في Redis

Redis يعرض من خلال INFO stats عدادين مهمين:

• keyspace_hits: عدد المرات التي وُجد فيها المفتاح المطلوب.
• keyspace_misses: عدد المرات التي لم يوجد فيها المفتاح.

ويمكن حساب النسبة كالتالي:

hit_ratio = keyspace_hits / (keyspace_hits + keyspace_misses) * 100

مثال:

keyspace_hits:900000
keyspace_misses:100000

hit_ratio = 90%

لكن النسبة الإجمالية قد تخدعك. الأفضل أن تجمع Metrics أيضًا على مستوى نوع الـ cache داخل التطبيق: مقالات، قوائم، إعدادات، widgets، قوائم navigation وغيرها. قد يكون المتوسط 90% بينما cache الصفحة الرئيسية يعمل بنسبة 30% فقط.

3. راقب evicted_keys: أخطر Metric تُتجاهل كثيرًا

إذا وصل Redis إلى maxmemory وبدأت سياسة الـ eviction في حذف مفاتيح، يزيد عدد evicted_keys. ارتفاع هذا الرقم باستمرار قد يعني:

• أن الذاكرة أصغر من working set الحقيقي؛
• أن TTL طويل أكثر من اللازم؛
• أنك تخزن بيانات منخفضة القيمة على حساب بيانات ساخنة؛
• أن eviction policy لا تناسب نمط الاستخدام.

لا تكتفِ بإنذار على «Redis memory > 90%». راقب العلاقة بين الذاكرة وevicted_keys وhit ratio وزمن استجابة الـ origin.

4. اجمع Metrics من Application Cache نفسه

Redis يعرف أن المفتاح كان HIT أو MISS، لكنه لا يعرف أن المفتاح يمثل «صفحة تصنيف» أو «إعدادات الموقع». هذه المعلومة موجودة في التطبيق.

في Laravel مثلًا توجد Cache Events مثل:

• CacheHit
• CacheMissed
• KeyWritten
• KeyForgotten
• KeyWriteFailed

يمكن الاستماع لهذه الأحداث وتحويلها إلى Metrics، لكن تجنب إرسال Log كامل لكل عملية Cache في الإنتاج؛ لأنك قد تستبدل مشكلة الأداء بمشكلة Logging. الأفضل استخدام counters مجمعة أو sampling.

// Conceptual example
CacheHit      -> increment("cms_cache_hits_total", ["group" => "article"])
CacheMissed   -> increment("cms_cache_misses_total", ["group" => "article"])
KeyWriteFailed-> increment("cms_cache_write_failures_total")

5. لا تسجل الـ Cache Key كاملًا كـ Metric Label

إذا كان المفتاح:

cms:site-1:ar:article:20782

فلا تحول 20782 إلى Label مستقل في Prometheus أو أي نظام time-series مشابه. هذا يؤدي إلى high cardinality وقد يجعل نظام المراقبة نفسه مكلفًا.

استخدم مجموعات منخفضة التنوع:

cache_group="article"
locale="ar"
store="redis"

واجعل المفتاح الكامل متاحًا فقط في logs التشخيصية أو traces عند الحاجة.

6. قياس CDN Cache باستخدام Headers

عند استخدام Cloudflare، أول أداة تشخيص ليست لوحة التحكم، بل Response Headers.

نفّذ:

curl -I https://example.com/ar/article/example

ثم راقب:

CF-Cache-Status: HIT
Age: 37
Cache-Control: public, max-age=60, s-maxage=300

وفق توثيق Cloudflare:

• HIT: النسخة جاءت من cache.
• MISS: المورد قابل للتخزين لكنه لم يكن موجودًا وقت الطلب.
• BYPASS: كان يمكن التعامل معه كـ cacheable، لكن إعداد أو response header أدى إلى تجاوز cache.
• DYNAMIC: الطلب لم يُعتبر مؤهلًا للـ cache أساسًا.
• STALE: تم تقديم نسخة قديمة وفق قواعد تسمح بذلك.
• REVALIDATED: تم التحقق من النسخة مع الـ origin وإعادة استخدامها.
• UPDATING: يتم تحديث نسخة قديمة بينما تُستخدم مؤقتًا لخدمة الطلبات.

كما أن Header Age يوضح عدد الثواني منذ دخول الاستجابة إلى cache أو آخر revalidation وفق سلوك Cloudflare.

7. اختبار CDN الصحيح يحتاج أكثر من Request واحد

طلب واحد لا يكفي للحكم على caching. استخدم سيناريو بسيطًا:

curl -I https://example.com/page
sleep 2
curl -I https://example.com/page
sleep 2
curl -I https://example.com/page

إذا كانت الصفحة يفترض أن تكون cacheable، فتوقع غالبًا انتقالًا من MISS إلى HIT، مع ارتفاع قيمة Age في الطلبات التالية. إذا رأيت BYPASS أو DYNAMIC باستمرار، افحص:

• Cache-Control
• Set-Cookie
• Authorization
• Vary
• Cloudflare Cache Rules
• Development Mode

8. أهم اختبار في CMS: Publish Freshness Test

المستخدم لا يهتم بالـ hit ratio إذا نشر مقالًا ولم يظهر في الصفحة الرئيسية. لذلك يجب أن يكون لديك اختبار يقيس freshness بعد تغيير المحتوى.

سيناريو عملي:

1. اطلب صفحة المقال والصفحة الرئيسية حتى تصبحا HIT.
2. عدّل عنوان المقال أو انشر نسخة جديدة.
3. سجل وقت نجاح عملية النشر: T0.
4. ابدأ بطلب URL المقال والصفحات المشتقة منه.
5. سجل أول وقت ظهرت فيه النسخة الجديدة: T1.
6. احسب T1 - T0.

حوّل النتيجة إلى SLO، مثل:

95% of published content becomes visible on public pages within 5 seconds.

هذه Metric أكثر أهمية في CMS من مجرد «متوسط response time» لأنها تقيس صحة الـ invalidation فعليًا.

9. اختبر Dependency Invalidation وليس صفحة المقال فقط

عند تحديث مقال، قد تتأثر عدة صفحات:

• صفحة المقال.
• الصفحة الرئيسية.
• صفحة التصنيف.
• صفحة الكاتب.
• صفحة الوسم.
• Widgets مثل «الأحدث» و«الأكثر قراءة».
• RSS أو API response.

أنشئ invalidation matrix توضح كل Event وما يجب أن يتغير بعده:

ثم اجعل هذه المصفوفة أساس integration tests، لا مجرد وثيقة.

10. اختبر الـ Cache تحت Load حقيقي

أدوات مثل Grafana k6 تسمح بإنشاء load profiles تحاكي عددًا من المستخدمين الافتراضيين. لكن اختبار cache يحتاج سيناريوهات مختلفة عن load test تقليدي.

Warm Cache Test

قم بتسخين cache أولًا ثم ابدأ الحمل. هذا يقيس قدرة النظام عندما يعمل cache في أفضل حالاته.

Cold Cache Test

ابدأ بعد purge أو flush محسوب في بيئة الاختبار. هذا يكشف تكلفة إعادة البناء الحقيقية.

Mixed Traffic Test

لا تطلب URL واحدًا آلاف المرات. استخدم مجموعة كبيرة من المقالات والتصنيفات بحيث تعكس توزيع الزيارات الحقيقي.

Hot Key Test

خصص نسبة كبيرة من الحمل لمقال أو صفحة واحدة، كما يحدث مع خبر عاجل أو موضوع تريند.

11. اختبار Cache Stampede

هذا الاختبار مهم جدًا للـ CMS الإخباري.

السيناريو:

1. اختر مفتاحًا مكلفًا مثل homepage feed.
2. اجعل TTL قصيرًا في بيئة الاختبار.
3. أرسل حملًا متزامنًا قبل انتهاء TTL.
4. راقب ما يحدث لحظة الانتهاء.

إذا كان لديك 500 request متزامن وقام 500 منها بإعادة تنفيذ نفس DB query الثقيلة، فالـ cache نفسه أصبح سببًا للضغط.

راقب:

• عدد rebuild operations.
• DB query rate.
• CPU spike.
• p95 وp99 latency.
• عدد الـ locks المكتسبة والفاشلة.

النجاح ليس أن تظل latency ثابتة فقط؛ بل أن يحدث rebuild واحد أو عدد محدود جدًا بدل إعادة بناء جماعية.

12. قارن Warm وCold Performance

سجل أرقامًا منفصلة:

إذا كان الفرق بين warm وcold هائلًا جدًا، فالنظام قد يكون هشًا أمام purge واسع أو Redis restart.

13. اختبر فشل Redis نفسه

اسأل: ماذا يحدث إذا أصبح Redis غير متاح؟

في بيئة اختبار، أوقف الاتصال مؤقتًا أو استخدم fault injection، ثم تحقق من:

• هل التطبيق يرجع 500 لكل المستخدمين؟
• هل توجد fallback strategy؟
• هل DB يستطيع تحمل الحمل الإضافي؟
• هل يتم تسجيل الخطأ بشكل يمكن تتبعه؟
• هل توجد retry storm تزيد المشكلة؟

الـ cache يجب ألا يتحول إلى single point of catastrophic failure دون قرار معماري واعٍ.

14. ضع Cache Metrics في Dashboard واحد

Dashboard مفيد للـ CMS يمكن أن يحتوي:

• Application cache hit ratio حسب المجموعة.
• Redis keyspace hit ratio.
• Redis memory usage.
• Redis evicted_keys rate.
• CDN HIT/MISS/BYPASS ratios.
• Origin request rate.
• DB queries/sec.
• p95 وp99 response time.
• Content freshness lag بعد publish.
• Cache rebuild duration.

الهدف هو أن تستطيع النظر إلى نفس الشاشة والإجابة: هل الزيادة في origin traffic سببها purge؟ أم Redis eviction؟ أم BYPASS من CDN؟ أم deployment؟

15. Alerts تستحق الإنشاء

بدل alert عام على CPU فقط، أنشئ قواعد مرتبطة بسلوك الـ cache:

• انخفاض hit ratio عن baseline لفترة مستمرة.
• ارتفاع مفاجئ في evicted_keys.
• ارتفاع BYPASS أو DYNAMIC لمجموعة صفحات يفترض أن تكون cacheable.
• ارتفاع origin request rate بدون زيادة مماثلة في traffic.
• ارتفاع freshness lag بعد publish.
• زيادة cache rebuild duration.
• ارتفاع cache write failures.

استخدم baseline خاص بنظامك بدل أرقام عامة. 80% hit ratio قد يكون ممتازًا لتطبيق، وسيئًا جدًا لتطبيق آخر.

16. Checklist قبل اعتماد أي تغيير Cache

• هل اختبرنا HIT وMISS؟
• هل اختبرنا انتهاء TTL؟
• هل اختبرنا publish/update/unpublish؟
• هل اختبرنا الصفحات التابعة للمحتوى؟
• هل اختبرنا purge من CDN؟
• هل اختبرنا cold cache؟
• هل اختبرنا hot key تحت concurrency؟
• هل اختبرنا Redis failure؟
• هل نستطيع رؤية hit ratio وevictions في monitoring؟
• هل لدينا freshness SLO واضح؟

الخلاصة

أفضل استراتيجية Cache ليست التي تخزن أكبر قدر من البيانات، بل التي يمكن قياسها وتشخيصها والتأكد من اتساقها. في أنظمة إدارة المحتوى، الاختبار الحقيقي يبدأ عندما يتغير المحتوى: هل ظهرت النسخة الجديدة بسرعة؟ هل أُبطلت جميع النسخ المشتقة؟ وهل يستطيع النظام التعامل مع انتهاء cache أو فشله دون انهيار؟

إذا لم تكن لديك Metrics واختبارات لهذه السيناريوهات، فأنت لا تدير Cache؛ أنت فقط تأمل أن يعمل.

مراجع موثوقة

• Cloudflare — Cache responses وCF-Cache-Status
• Cloudflare — Investigate uncached responses
• Redis — INFO command
• Redis — Key eviction وقياس hit ratio
• Laravel 13 API — Cache Events
• Grafana k6 — Load testing websites
• Grafana k6 — HTTP requests