أداء المزامنة ومراعاة الخادم
تصف هذه الصفحة محرك المزامنة المُقدَّم في WCPOS 1.10.0. ولمعرفة كيف يعمل المحرك آليًا، ابدأ من كيف يعمل محرك المزامنة.
تعمل معظم متاجر WCPOS على استضافة PHP مشتركة: حفنة من عمّال PHP، وتشغيل كامل لـ WordPress مع كل طلب REST، وإضافات أمان تحدّ من معدل الدفعات. والطلبات التي يعاملها العميل على أنها مجانية تُضعف أداء المتجر الإلكتروني، وتُفعّل محدِّدات المعدل، وتزاحم حركة أمين الصندوق نفسه — مضروبةً في كل صندوق وكل علامة تبويب متصفح تشغّلها.
ويعامل محرك المزامنة في الإصدار 1.10.0 ذلك بوصفه قيدًا تصميميًا لا فكرة لاحقة: حماية استضافة التاجر جزء من مهمة محرك المزامنة. وتشرح هذه الصفحة القواعد التي يتّبعها المحرك والقياسات التي تقف خلفها.
القواعد الأربع الثابتة
يحكم أربعة ثوابت كل سلوك مزامنة مجدول في المحرك:
- تتناسب الكلفة مع ما تغيّر، لا مع حجم الكتالوج أبدًا. إذ يسبق دائمًا فحصٌ رخيص أو موجزٌ مختصر أي جلب بالجملة. فمتجر فيه 50,000 منتج لم يتغيّر يكلّف إبقاؤه متزامنًا تقريبًا ما يكلّفه متجر فيه 500 منتج لم يتغيّر.
- لا تفرّع غير محدود. فكل مسار خلفي يعلن سقفًا لعدد الطلبات في كل تشغيلة، تفرضه اختبارات آلية. أما المهام الأكبر فتُنفَّذ على شكل دفعات محدودة بمؤشرات قابلة للاستئناف — فتنتشر الجولة على مدى جدولها بدلًا من الاندفاع دفعةً واحدة.
- الصيانة لا تعترض طريق أمين الصندوق أبدًا. فالطلبات التي تجعل الصندوق جاهزًا للبيع تعمل أولًا؛ وتدقيقات السلامة والتحضيرات الخلفية تعمل بعد ذلك، في أوقات الخمول.
- تحت الضغط، تتراجع الصيانة أولًا. فحين يشير خادمك إلى ضائقة، يبطّئ المحرك عمله الخلفي قبل المساس بأي شيء يواجه أمين الصندوق.
ما الذي تكلّفه المزامنة خادمك
تحدَّد كلفة الحالة المستقرة عبر الإعداد المسبق للمزامنة، المُختار لكل جهاز من صحة المتجر → الأداء:
| الإعداد المسبق | فترة الفحص | السجلات لكل طلب | الفحوص الاسمية يوميًا |
|---|---|---|---|
| اقتصادي | 5 دقائق | 25 | 288 |
| متوازن (الافتراضي) | 60 ثانية | 50 | 1,440 |
| الزمن الفعلي | 10 ثوانٍ | 75 | 8,640 |
وكلا المقبضين مهم، ووزن الصفحة هو ما يكلّف الاستضافة المشتركة فعليًا في العادة — فصفحة سجلات ثقيلة تستهلك وقت خادم حقيقيًا، والفترة لا تفعل سوى مضاعفة ذلك. ولا يشحن أي إعداد مسبق الحد الأقصى البالغ 100 سجل في الصفحة؛ فذلك لا يمكن بلوغه إلا عبر مؤشرات التمرير المخصصة (فترة من 5 ثوانٍ إلى 5 دقائق، ومن 10 إلى 100 سجل).
وإضافةً إلى الإعداد المسبق:
- الفحص أثناء الخمول منخفض الكلفة. إذ يرسل المحرك طلبات شرطية، فيُجاب فحصٌ بلا تغيير باستجابة واحدة بلا محتوى
304 Not Modified— وهي طلب واحد فعلًا، لكن بلا حمولة وبأدنى عمل من الخادم. - تُوزَّع الفحوص عشوائيًا بنسبة ±20%، فينشر أسطول من الصناديق طلباته بدلًا من أن تتزامن في دفعات.
- تتباطأ الصناديق الخاملة إلى وتيرة أبطأ بعد 10 دقائق دون تفاعل، وتعود فورًا عند أي نشاط، بما في ذلك مسح الباركود.
- صيانة الخلفية محدودة بسقف. ففحص السلامة الخالي من الانحراف يكلّف على الأكثر بضع صفحات تجميعية رخيصة وصفرًا من عمليات جلب التفاصيل — إذ تُتخطّى الحاويات التي يثبت تطابقها مع الخادم تخطيًا تامًا. وحين يُكتشف انحراف، تُحدَّد عمليات التعمّق بسقف اثنتين لكل تشغيلة، وتُستأنف عبر مؤشر محفوظ بدلًا من الاندفاع. أما تدقيق الحذف الكامل فمحدود بـ 11 طلبًا لكل تشغيلة، وتحضير الموجز بـ 5 قطع لكل تشغيلة. وهذه السقوف معلَنة في الشفرة ومفروضة عبر CI.
تشتق صحة المتجر تقديرها ~N طلبًا يوميًا من الفترة المضبوطة. عامِله على أنه معدل فحص اسمي، لا سقف ولا تنبؤ: فالتوزيع العشوائي بنسبة ±20% يحرّك العدد الفعلي في أي من الاتجاهين، والاستجابة 304 تُحتسب طلبًا أيضًا. أما تباطؤ الخمول فلا يخفض العدد إلا للإعدادات المسبقة الأسرع من حدّه الأدنى البالغ 60 ثانية؛ فهو لا يبطّئ الإعداد المسبق المتوازن الافتراضي أكثر من ذلك.
التراجع حين يتعثّر خادمك
كل استجابة يتلقّاها المحرك تغذّي مراقب ضغط لكل متجر. وهو يتفاعل مع:
- حالة HTTP رقم
429(فورًا)، - أخطاء
5xxالمتكررة أو إخفاقات النقل (ثلاثة خلال دقيقة متحركة)، - البطء المستمر (زمن استجابة وسيط يتجاوز ثانيتين)،
- ترويسة
Retry-After، التي تصبح حدًّا أدنى صارمًا للفحص التالي.
وحين يُفعَّل أيٌّ من هذه، يضاعف المحرك فترة فحص التغييرات خطوةً واحدة في كل مرة، وتتخطّى مسارات الصيانة تشغيلاتها بالكامل. أما الطلبات التي يقودها أمين الصندوق — عمليات البحث، وعمليات البحث بالباركود، وإتمام الدفع — فلا تُخنق أبدًا؛ إذ الهدف هو التخلص من الحمل القابل للتأجيل، لا إبطاء البيع.
والتعافي غير متماثل عن قصد: فالتراجع فوري، لكن الفترة لا تعود خطوةً إلى الأسفل إلا بعد عشر استجابات سليمة متتالية، كي لا يتأرجح خادم غير مستقر بين وتيرتين سريعة وبطيئة. كما تبقى حالة الضغط قائمة حتى لو اختار التاجر إعدادًا مسبقًا أسرع — فالحماية تعمل أسفل أي مستوى مضبوط، ولا سبيل إلى تعطيلها بالإعدادات.
البقاء سريع الاستجابة على الجهاز
النصف الآخر من الأداء هو الصندوق نفسه — فالمزامنة الخلفية يجب ألا تجعل الواجهة تتلعثم أبدًا.
- التدقيقات تفسح المجال لحلقة الأحداث. إذ يقسّم تدقيق السلامة عمله إلى قطع ويفسح المجال بينها، مبقيًا أطول كتلة متواصلة لديه عند نحو 30 مللي ثانية — أي دون عتبة الـ 100 مللي ثانية تقريبًا التي يدرك عندها البشر التأخر. وبالقياس عند 10,000 منتج محلي، تكلّف جولة تدقيق كاملة نحو 68 مللي ثانية من الحوسبة موزعة على أكثر من 17 إفساحًا؛ وعند 50,000 منتج، أقل من 300 مللي ثانية.
- النتيجة الأولى تبقى سريعة تحت الحمل. فعقود زمن الوصول إلى النتيجة الأولى مثبَّتة في CI حتى أثناء تشغيل تطبيق بالجملة أو تدقيق كامل بالتوازي — أي مللي ثوانٍ من خانة واحدة عند أحجام الكتالوج المعتادة في بيئة القياس.
- لا يعبر إلى التطبيق سوى الصفحة المرئية. فعمل الاستعلام (التصفية والترتيب وترقيم الصفحات) يُنفَّذ داخل طبقة التخزين، فيحرّك تحديث الشاشة عشرة صفوف لا عشرة آلاف.
وهذه الأرقام مستقاة من مجموعة عقود الأداء المثبَّتة الخاصة بالمحرك، والتي تعمل معزولة في CI بميزانيات مضبوطة أعلى بنحو رتبة عشرية من الحالة المستقرة المقيسة — مصمَّمة لالتقاط التراجعات بمقدار رتبة عشرية، لا للفشل على مشغّل بطيء.
مُتحقَّق منه على متجر حي
قواعد مراعاة الخادم ليست مختبَرة بوحدات الاختبار فحسب. فثمة فحص حي من طرف إلى طرف مقابل متجر WordPress حقيقي يتحقق من الثوابت الأهم على استضافة حقيقية:
- صفر طلبات صيانة (حركة سلامة أو موجز) قبل عرض كتالوج المنتجات عند فتح المتجر.
- وبعد فترة التمهّل التالية للفتح، بضع صفحات تجميعية رخيصة على الأكثر، وما لا يزيد عن عمليتَي تعمّق في التفاصيل.
وقد بُني هذا السيناريو انطلاقًا من تراجع حقيقي: إذ كانت نسخة تطوير سابقة من التدقيق تصدر نحو 41 طلبًا (1.2 ميغابايت) عند كل فتح للمتجر، لكل جهاز. أما التصميم المحكوم بالموجز الذي حل محلها فيقلّص التدقيق الخالي من الانحراف إلى صفحاته التجميعية ولا شيء غيرها — وصار هذا الصنف من العيوب محروسًا بسقوف معلَنة في CI، لا بيقظة المراجعة.
ما الذي لا ندّعيه
ثمة أمور قليلة لا تقولها هذه الصفحة عن قصد، لأننا لا نملك أرقامًا يمكن الدفاع عنها بشأنها (بعد):
- لا رقم شاملًا من طرف إلى طرف مثل «تستغرق المزامنة الأولية X دقيقة». فزمن التنزيل الأولي يعتمد بصورة طاغية على أزمنة استجابة خادمك وحجم الكتالوج. أما الكلفة على جانب الجهاز لتطبيق السجلات فصغيرة (تطبيق 10,000 منتج بالجملة يُقاس بأقل من 10 مللي ثانية من الحوسبة)؛ والشبكة والخادم هما المهيمنان.
- لا ادّعاء بأنه «أسرع بنسبة X% من الإصدار 1.9». فالبنيتان مختلفتان بما يكفي لأن يضلّل رقم مقارن واحد أكثر مما يفيد. أما الفروق البنيوية فمعروضة في ما الذي تغيّر في الإصدار 1.10.0.
- أرقام القياس أعلاه مستقاة من بيئة اختبار المحرك (تخزين في الذاكرة، ومشغّل معزول). والأجهزة الحقيقية والمتاجر الحقيقية تتفاوت؛ ولهذا السبب بالضبط تعرض صحة المتجر → الأداء أعداد الطلبات المقيسة لصندوقك وزمن الاستجابة المعتاد خلال آخر 24 ساعة بدلًا من التوقعات. ورقم حجم البيانات فيها حدّ أدنى، لأن الاستجابات التي لا تعلن حجمًا تسهم بصفر.
ولضبط جانب الخادم — متطلبات الاستضافة، وHPOS، والتخزين المؤقت، وتشخيص الاستجابات البطيئة — راجع أداء الخادم.