اختيار وضع تشغيل خادم الويب بناءً على التجربة الشخصية

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

حتى أولئك الذين ما زالوا يحلمون فقط بآلاف المستخدمين على موقعهم ، ربما تساءلوا: "كم عدد المستخدمين الذين سيتواجدون على موقعي إذا قاموا بتسجيل الدخول في نفس الوقت؟" أتذكر على الفور التعبير المعروف "Habraeffect" - ظاهرة فشل الموقع ، والتي تحولت إلى أنها ليست جاهزة للتحويلات الكثيرة إليها بعد ظهور الرابط على الإنترنت.

لنفترض أن الموقع موجود بالفعل (أو سيكون قريبًا): أين يمكن أن يكون موجودًا؟ هل يجب أن يكون خادم استضافة كلاسيكي أو vps؟ إذا المبادئ الطوعية ، أي واحد وكيف هو الأفضل لتكوينه؟ أو ربما لا يوجد فرق على الإطلاق وأنه من الأسهل اختيار ما هو أرخص؟ في هذه المقالة ، سننظر في العديد من الخيارات وفي الممارسة العملية تأكد من الخيار الأفضل لموقعنا.

سنختبر: ضبط أوضاع تشغيل الخادم المختلفة وقياس الأداء. سنقوم بمحاكاة الحمل على الموقع باستخدام خدمة Loaddy.com. هناك يمكنك تعيين عدد المستخدمين ، ونوع التحميل المتزايد ، وسيظهر الرسم البياني كيفية استجابة الخادم لهم. يُعتقد أن مستخدمًا واحدًا ينشئ طلبًا واحدًا تقريبًا إلى الموقع في غضون 10 ثوانٍ. كموقع اختبار ، خذ متجرًا تجريبيًا عبر الإنترنت على cms moguta. سيتم ملؤها بـ "سلع" اختبار يتم عرضها على الصفحة الرئيسية وفقًا لعدة معايير (أي عندما يتم تكوين الصفحة ، يجري العمل مع قاعدة البيانات ، وما إلى ذلك). بطريقة أو بأخرى ، سيسمح لك ذلك بمقارنة الأوضاع فيما بينها.

كموقع اختبار ، سنقوم بإنشاء خادم VPS على أوبونتو. تكوينه سيكون [1 الأساسية ، 1GB RAM]. نحن نفترض أن هذه الخوادم على مستوى الدخول هي بالضبط التي يتم إنشاؤها في معظم الحالات للمشاريع الجديدة. سيكون الإصدار التجريبي من المتجر عبر الإنترنت متاحًا على عنوان IP http://130.193.44.219/

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

نظرًا لأنه في معظم الحالات يتم تقديم لوحة تحكم مع vps ، سنقوم بإجراء التغييرات الرئيسية على الإعدادات الموجودة فيها. على خادم vps ، لدينا 3 أوضاع من التشغيل:

• اباتشي
• اباتشي في وضع CGI ؛
• Nginx + php-fpm (بدون Apache).

ولكن أولاً ، دعونا نختبر الاستضافة:

استضافة منخفضة التكلفة الكلاسيكية

النتيجة متاحة هنا .

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

يخضع موقعك لقيود على مدار الـ 24 ساعة الماضية. كانت موارد المعالج محدودة لموقعك. لقد وصلت إلى حدود عمليات الإدخال (عدد برامج PHP و CGI التي تعمل في وقت واحد ، والمهام المجدولة وجلسات وحدة التحكم) 126 مرة.

حسنا ، بالطبع ، استضافة يستضيف ، أكثر تكلفة. يمكنك بالطبع العثور على تعريفة توفر المزيد من الخيارات ، ولكن عليك أن تفكر في كل هذا ، وتكتشف بطريقة ما البيانات الدقيقة للقيود ، وكل مزود استضافة.

VPS: اباتشي

التالي هو اختبار سلاح الجو لدينا مع وضع Apache ، والذي بالمناسبة يتم تقديمه بشكل افتراضي عند تثبيت لوحة تحكم ISP.



النتيجة متاحة هنا .

تبدأ المشاكل عندما يتجاوز عدد المستخدمين 90. إذا انتقلنا إلى خادمنا عبر ssh ونظرنا إلى تلك اللحظة في قائمة العمليات باستخدام الأمر العلوي ، مصنفة باستخدام Shift + M (حسب مقدار الذاكرة المستهلكة) ، سنرى شيئًا مثل هذا:



نرى أن عملية apache2 قد تطورت إلى العديد من الشركات التابعة وأنها أكلت ذاكرة الوصول العشوائي بالكامل لخادم vps الخاص بنا.

هنا تحتاج إلى تقديم ملاحظة صغيرة. والحقيقة هي أنه من الناحية النظرية ، يوجد وضع لخادم Apache يسمح بدلاً من هذا العدد الكبير من العمليات الفرعية لكل اتصال بإنشاء عدة مؤشرات متعددة تسمى كل منها ، والتي يخدم كل منها عدة اتصالات. يسمى هذا الوضع العامل ، على عكس ما قبل الإعداد الافتراضي. لكن ليس من السهل تثبيته ، من المستحيل القيام بذلك في لوحات مثل ISP ، وإذا شعرت بالحيرة ومحاولة القيام بذلك عبر ssh ، فقد تبين أن إيقاف التشغيل المسبق وتشغيل العامل ليس كافيًا ، فلا تزال بحاجة إلى إصدار آمن من سلاسل عمليات php. وإذا تم استخدام وحدات مثل Zend أو IonCube ، فيجب أن تكون آمنة أيضًا. على أي حال ، لا ينصح موقع PHP الرسمي بتعيين هذا الوضع.

VPS: CGI

دعونا نرى ما يحدث عند استخدام وضع CGI. للقيام بذلك ، تحتاج إلى السماح باستخدام PHP في وضع CGI في لوحة تحكم ISP ، ويتم ذلك في قسم "الحسابات - المستخدمون - إعدادات المستخدم".



النتيجة متاحة هنا .

تحولت صورة قاتمة. يرفض الخادم إعطاء محتوى بالفعل مع أكثر من 55 زائرًا ، حيث يتم تناول ذاكرة الوصول العشوائي (RAM) جميعها عن طريق عمليات "php". التالي هو محاولة لاستعادة الوظيفة ، ولكن لا يزال ينتهي في فشل 100٪ تقريبًا.

VPS: Nginx + PHP-FPM

لقد حان الوقت لوضع لا يستخدم فيه خادم Apache على الإطلاق ، ويعمل Nginx بدلاً من ذلك ، وتتم معالجة php بواسطة وحدة php-fpm. إذا كنت تستخدم لوحة تحكم ISP ، فيجب عليك تمكين هذا الوضع للمستخدم. يتم ذلك أيضًا في قسم "الحسابات - المستخدمون - إعدادات المستخدم". أيضًا ، يجب أن يكون هذا الوضع متاحًا في قسم "الإعدادات - الميزات - خادم الويب (www)".



النتيجة متاحة هنا .

ما تحتاجه! توفر 100 ٪ ، في حين أن سرعة التنزيل ووقت استجابة الخادم في مستويات مقبولة ، على الرغم من أنها تزيد مع زيادة الحمل. ومع ذلك ، فإن الخادم هو التعامل!

دعنا ننظر إلى جدول العملية في وقت الحمل الأقصى على الخادم:



نرى أنه لا يزال لدينا امدادات من ذاكرة الوصول العشوائي المتاحة. ولا تنمو العمليات التابعة لـ php-fpm7.0 بأعداد كبيرة ، ولكنها تقتصر على 5 حالات ، كل واحدة منها تقدم عدة خيوط.

حسنًا ، يبدو أنه يتم تعريف "وضع الفوز". دعنا نتعرف على عدد الزوار المتزامنين الذين يمكن لخادمنا أن يخدمهم في هذا الوضع. لكن قبل ذلك نقوم ببعض "الضبط". أولاً ، نظرًا لعدم استخدام apache لعملية الخادم هذه ، يمكن تعطيله تمامًا. سنفعل ذلك في لوحة تحكم مزود خدمة الإنترنت في قسم "النظام - الخدمات". ثانياً ، نغير قليلاً مبدأ بدء عمليات php-fpm. بشكل افتراضي ، إنه ديناميكي. هذا يعني أن العمليات الفرعية ستعلق في الذاكرة حتى عندما لا تكون هناك حاجة إليها. في الوقت نفسه ، لا يتم تحرير الذاكرة ، وبمرور الوقت ، يمكن أن تنمو هذه العمليات أكثر مما نود. لذلك ، يُقترح ضبط وضع "ondemand" - عند الطلب. وضبط عدد العمليات التابعة والمهلة الزمنية لهم.

للقيام بذلك ، ستحتاج إلى الانتقال إلى الخادم عبر ssh وتسجيل هذه الإعدادات في ملف تكوين php. يتم ذلك في الملف للمستخدم الذي تم إنشاء المجال له في ISP.

عادة ما يكون موجود في /etc/php/7.0/fpm/pool.d

لذلك:

sudo nano /etc/php/7.0/fpm/pool.d/www-root.conf 

نرى هناك افتراضيا الإعدادات التالية:

 [www-root] pm = dynamic pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_children = 5 pm.max_spare_servers = 5 

لتمكين وضع ondemand ، تحتاج إلى استبدال هذا بـ:

 pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s 

وأعد تشغيل php-fpm باستخدام الأمر

 sudo service php7.0-fpm restart 

بعد ذلك ، سيتم إنشاء عمليات php-fpm7.0 عند الطلب (إذا كان هناك حمولة) ، سيكون الحد الأقصى لعددها = 5 ، وبعد 10 ثوانٍ من وقت التوقف عن العمل ، سيتم قتل العملية ، وتحرير ذاكرة الوصول العشوائي.

في حالة حدوث ذلك ، سنجري اختبارنا مرة أخرى للتأكد من أن كل نشاط الهواة هذا لم يؤثر على أداء الموقع بشكل سيئ:



النتيجة متاحة هنا .

دعنا الآن تشغيل Loaddy مع الكثير من الزوار لفهم عدد الاتصالات التي يمكن لخادمنا التعامل معها:



النتيجة متاحة هنا .

والخبر السار هو أن جميع الطلبات تمت معالجتها ، وإن كان ذلك مع تأخير كبير ، مع عدد كبير منها في الثانية الواحدة. يقترب وقت استجابة الخادم من 10 ثوانٍ مع 190 زيارة ، ولكن دعنا نتذكر الرسم البياني لوضع apache ، حيث حصلنا على 4 ثوانٍ من استجابة الخادم بالفعل مع أكثر من 80 مستخدمًا ، بينما في وضع php-fpm ، لوحظت حالات تأخير مماثلة مع 130 طلبًا قمنا بتخصيصها المؤشر على الرسم البياني أعلاه.
ولكن هذا هو نفس المبادئ الطوعية.

جدول العمليات العليا في نهاية الاختبار (مع 200 مستخدم):



لاحظ أنه بعد الاختبار ، يتم تحرير الذاكرة المستخدمة بواسطة pfp-fpm:



لذلك خادمنا جاهز للتحميلات الجديدة.

يجب أن نتذكر أن الموقع يعمل في وضع nginx + php-fpm ، مما يعني أن apache2 لا يستخدم في العمل ، ونتيجة لذلك ، لا يتم استخدام .htaccess. قد لا يبدو هذا مناسبًا ، لكنه أسرع خيار ممكن ، ومحركات البحث تصنف المواقع التي تعمل بشكل سريع.

الخاتمة

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

إذا كنت ترغب في اختبار الموقع بشكل مستقل باستخدام Loaddy أو طرق أخرى ، فهو متوفر على http://130.193.44.219/