Octane ودورة الـ request: هل حالتك بين الطلبات معزولة؟

بعد تفعيل Octane، بيانات عميل ظهرت لحظياً في جلسة عميل آخر — singleton يحمل حالة يبقى حياً بين الطلبات.

#Laravel #Octane #Performance

// في هذا المقال

السياق

لوحة عملاء على Laravel 11. بعد تفعيل Octane لتخفيض زمن الاستجابة، ظهرت شكوى متقطعة: بيانات عميل تظهر لثوانٍ في لوحة عميل آخر. المشكلة نادرة لكن حرجة في بيانات المشتريات. السبب المشتبه: singleton يخزّن $userId بعد المصادقة ولا يُعاد ضبطه.

الإجراء

راجعت AppServiceProvider — وجدت app()->singleton(CurrentUserContext::class, ...) يخزّن المستخدم الحالي. في Octane، Worker واحد يخدم طلبين متتاليين دون reset للـ container. اختبرت ثلاثة بدائل: (1) scoped() بدل singleton() — يُعيد البناء لكل request، (2) Octane::flush(['CurrentUserContext']) في middleware، (3) حذف الخدمة وحقن المستخدم مباشرة من $request->user() في كل استدعاء. شغّلت ab -c 10 -n 200 على بيئة staging لإعادة الإنتاج.

النتيجة

scoped() حل المشكلة فوراً دون تعديل أي مكان يستخدم الخدمة. Flush في middleware أعقد وعرضة للنسيان. الحقن المباشر أنظف معمارياً لكن يتطلب إعادة هيكلة كاملة. التحقق في DevTools أثبت أن الـ container يُبنى مرة واحدة لكل Worker Process.

الدرس

كل singleton يحمل حالة مستخدم أو طلب يجب تسجيله scoped() قبل رفع المشروع لـ Octane — وإلا Worker واحد يخدم عميلين.

هل تشبه فكرتك هذا المشروع؟ باب التعاون من هنا ‹