ما هو الخادم وأنواعه

بمَ يختلف الخادم عن حاسوب بيتك؟

في الجنس، لا شيء تقريبا. فلـلخادم معالج وذاكرة وقرص، وينفّذ التعليمات المألوفة نفسها. والفرق في الدور: حاسوبك ينتظرك، والخادم ينتظر بقية العالم. أنت تغلق حاسوبك ليلا؛ والخادم الذي يُغلَق لم يعد خادما.

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

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

حين يصل طلب، من الذي يجيب بالضبط؟

هنا تنقسم كلمة «خادم» إلى أشياء منفصلة، وما لم ترَ هذا الانقسام فلا مشكلة خادم قابلة للتشخيص. أولا يستقبل خادم الويب الطلب؛ وعلى هذا الجهاز يقوم بذلك nginx النسخة ١.٢٩.٤. فإن كان المطلوب ملفا جاهزا أنهاه هناك ولم يُشغَّل برنامج آخر. وإلا سلّم الطلب إلى مفسّر البرنامج، وهو هنا PHP النسخة ٨.٥.٢، الذي ينفّذ شفرة الموقع ويسأل في طريقه قاعدة البيانات والذاكرة المؤقتة.

والفارق بين المسارين قابل للقياس، ورقمه صادم. فالصفحة الأولى لهذا الموقع، حين تُجاب من ملف جاهز، تستغرق ٢٣ ميلي ثانية في أفضل الأحوال حتى يصل أول بايت منها. والصفحة نفسها، حين نُلزمها بأن تُبنى من جديد، تستغرق ١٣٩ ميلي ثانية في أفضل الأحوال. أي أن تلك الـ١١٦ ميلي ثانية الزائدة كلها لطبقة التطبيق وقاعدة البيانات، على الجهاز نفسه والشبكة نفسها والصفحة نفسها. وكون الصفحة تُبنى مسبقا أو تُبنى في كل زيارة هو أكبر قرار سرعة منفرد في موقع ووردبريس.

وطبقتان أخريان على المسار نفسه تُرَيان أقل. قاعدة البيانات، وهي هنا MariaDB النسخة ١٠.١١.١٠، وتحفظ المحتوى والإعدادات. وذاكرة مؤقتة في الرام، وهي هنا Redis، تحفظ أجوبة الاستعلامات المتكررة كي لا تقرأ قاعدة البيانات من القرص ثانية.

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

بمَ تختلف الخوادم المشتركة والافتراضية والمخصصة والسحابية؟

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

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

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

ولنذكر حدّ هذه النصيحة صراحة: كلفة الخادم الافتراضي ليست إيجاره الشهري فقط، بل وقت من يبقيه محدَّثا. فإن لم يوجد ذلك الشخص، كان الخادم الافتراضي المهمَل أخطر من الاستضافة المشتركة، لأن تحديثه لم يعد عمل أحد. واختيار الاستضافة وشراؤها ليسا موضوع هذا الدرس، وقد فُتحا في دليل اختيار الاستضافة ومقال الاستضافة المشتركة.

لماذا يتوقف خادم عن العمل؟

الظن الشائع أن المعالج يمتلئ. وعمليا لا يكون هذا أبدا تقريبا. فالذي ينفد هو سعة التزامن: عدد العمال المسموح لهم بتنفيذ شفرة الموقع في اللحظة الواحدة.

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

وثمة سقف ثانٍ يعرفه قليلون وهو مكتوب في المكان نفسه: لكل طلب ١٨٠ ثانية على الأكثر ثم يُقطع بلا رحمة. وهذه حماية جيدة، لأن طلبا معطوبا لا يستطيع أن يحتجز عاملا إلى الأبد. لكنها تعني أيضا أن الأعمال الطويلة، كأخذ نسخة احتياطية أو استيراد ملف كبير، تُقطع في منتصفها، وبلا رسالة خطأ واضحة. فإن كان عمل يفشل دائما عند نحو ثلاث دقائق، فلا تبحث عن خلل برمجي؛ لقد ارتطمت بالسقف.

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

ما الذي ليس من واجب الخادم؟

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

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

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