تم نشر نسخة غير منقحة من المقال في الأصل على haydenjames.io ويتم نشرها هنا بإذن من مؤلفها .
باختصار ، سأتحدث عن أفضل طريقة لتهيئة PHP-FPM لزيادة الإنتاجية وتقليل الكمون والاستخدام الأكثر استقرارًا لموارد المعالج والذاكرة. بشكل افتراضي ، تكون السلسلة PM (مدير العمليات) في PHP-FPM ديناميكية ، وإذا لم يكن لديك ذاكرة كافية ، فمن الأفضل تثبيت عند الطلب . دعنا نقارن بين خيارين من عناصر التحكم استنادًا إلى وثائق php.net ونرى كيف يختلف الساعة الثابتة المفضلة لدي عن مقدار الحركة الكبير:
pm = dynamic - تم تكوين عدد العمليات الفرعية ديناميكيًا بناءً على التوجيهات التالية: pm.max_children ، pm.start_servers ، pm.min_spare_servers ، pm.max_spare_servers .
pm = ondemand - يتم إنشاء العمليات عند الطلب (على عكس الإنشاء الديناميكي ، عند بدء تشغيل pm.start_servers عند بدء تشغيل الخدمة).
pm = ثابت - يتم تحديد عدد العمليات الفرعية وتحديدها بواسطة المعلمة pm.max_children .
راجع القائمة الكاملة لتوجيهات php-fpm.conf العالمية للحصول على التفاصيل .
أوجه التشابه بين مدير عمليات PHP-FPM وجهاز التحكم في تردد المعالج
قد يبدو هذا غير منطقي ، لكني سأقوم بربط هذا الموضوع بموضوع تهيئة PHP-FPM. من لم يقل مرة واحدة على الأقل لم يبطئ المعالج - على جهاز كمبيوتر محمول أو جهاز ظاهري أو خادم مخصص. تذكر تحجيم تردد المعالج؟ يمكن لهذه الخيارات ، المتوفرة لـ nix و Windows ، تحسين أداء النظام واستجابته عن طريق تغيير إعداد وحدة تحكم المعالج من ondemand إلى الأداء *. هذه المرة ، دعونا نقارن الأوصاف وننظر إلى أوجه التشابه:
Governor = ondemand - القياس الديناميكي لتردد المعالج اعتمادًا على الحمل الحالي. يتحول بحدة إلى الحد الأقصى للتردد ، ثم يقلله عند زيادة فترات الخمول.
المحافظ = المحافظ = قياس التردد الديناميكي حسب الحمل الحالي. يزيد وينقص التردد أكثر سلاسة من الطلب عند الطلب.
الحاكم = الأداء - التردد هو الحد الأقصى دائمًا.
راجع القائمة الكاملة لمعلمات وحدة التحكم في تردد المعالج للحصول على التفاصيل.
رؤية التشابه؟ أردت إظهار هذه المقارنة لإقناعك بأنه من الأفضل استخدام static pm لـ PHP-FPM.
بالنسبة لوحدة التحكم في المعالج ، تساعد معلمة الأداء على زيادة الأداء بأمان لأنه يعتمد كليًا تقريبًا على حد معالج الخادم. بالإضافة إلى ذلك ، بالطبع ، هناك أيضًا عوامل مثل درجة الحرارة وشحن البطارية (في الكمبيوتر المحمول) والآثار الجانبية الأخرى لتشغيل المعالج الثابت بنسبة 100٪. يوفر ضبط الأداء أسرع أداء للمعالج. اقرأ ، على سبيل المثال ، عن المعلمة force_turbo في Raspberry Pi ، والتي ستستخدم بها لوحة RPi منظم الأداء ، حيث سيكون تحسين الأداء أكثر وضوحًا بسبب انخفاض سرعة الساعة لوحدة المعالجة المركزية.
باستخدام pm ثابت لزيادة أداء الخادم
تعتمد المعلمة الثابتة PHP-FPM pm إلى حد كبير على الذاكرة الخالية على الخادم. إذا كانت الذاكرة منخفضة ، فمن الأفضل أن تختار عند الطلب أو ديناميكية . من ناحية أخرى ، إذا كان لديك ذاكرة ، فيمكنك تجنب الحمل الإضافي لمدير عملية PHP من خلال ضبط ثابت ثابت على سعة الخادم القصوى. بمعنى آخر ، إذا كان كل شيء محسوبًا جيدًا ، فأنت بحاجة إلى ضبط pm.static على الحد الأقصى لمقدار عمليات PHP-FPM التي يمكن تنفيذها دون خلق مشاكل مع ذاكرة أو ذاكرة تخزين مؤقت غير كافية. لكن ليس بهذه الدرجة من التحميل الزائد للمعالجات وتجميع مجموعة من عمليات PHP-FPM التي تنتظر التنفيذ .
في لقطة الشاشة أعلاه ، يحتوي الخادم على pm = ثابت و pm.max_children = 100 مثبت ، ويستغرق هذا حوالي 10 غيغابايت من 32 المتاحة ، مع الانتباه إلى الأعمدة المميزة ، كل شيء واضح هنا. في لقطة الشاشة هذه ، كان هناك ما يقرب من 200 مستخدم نشط (أكثر من 60 ثانية) في Google Analytics. في هذا المستوى ، لا يزال حوالي 70٪ من العمليات الفرعية لـ PHP-FPM في وضع الخمول. هذا يعني أنه يتم ضبط PHP-FPM دائمًا على الحد الأقصى لموارد الخادم ، بغض النظر عن حركة المرور الحالية. تنتظر عملية الخمول الذروة المرورية وتستجيب على الفور. ليس عليك الانتظار مساءً لإنشاء عمليات تابعة ثم إنهاءها عند انتهاء فترة pm.process_idle_timeout . لقد قمت بتعيين قيمة عالية جدًا بالنسبة إلى pm.max_requests ، لأنه خادم يعمل بدون تسرب الذاكرة في PHP. يمكنك تعيين pm.max_requests = 0 بثبات إذا كنت واثقًا تمامًا من البرامج النصية الحالية والمستقبلية لـ PHP. ولكن من الأفضل إعادة تشغيل البرامج النصية بمرور الوقت. قم بتثبيت عدد كبير من الاستعلامات ، لأننا نريد تجنب الحمل غير الضروري مساءًا. على سبيل المثال ، على الأقل pm.max_requests = 1000 - حسب عدد pm.max_children وعدد الطلبات في الثانية الواحدة.
تعرض لقطة الشاشة أمر Linux العلوي ، ويتم تصفيته بواسطة u (user) واسم مستخدم PHP-FPM. يتم عرض العمليات الخمسين الأولى فقط أو نحو ذلك (لم أحسب بالضبط) ، ولكن في الحقيقة ، يعرض الجزء العلوي الإحصائيات العليا التي يتم وضعها في نافذة المحطة الطرفية. في هذه الحالة ، يتم فرزها حسب٪ CPU (٪ CPU). لعرض جميع عمليات الـ 100 PHP-FPM ، قم بتشغيل الأمر:
top -bn1 | grep php-fpm
عند استخدام الساعة ondemand وديناميكية
إذا كنت تستخدم الديناميكي pm ، فستحصل على أخطاء مماثلة:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children
حاول تغيير المعلمة ، الخطأ لن يذهب إلى أي مكان ، كما هو موضح في هذا المنشور على Serverfault . في هذه الحالة ، كانت قيمة pm.min صغيرة جدًا ، وبما أن حركة مرور الويب تتغير كثيرًا وذات قمم عالية وقطرات عميقة ، فمن الصعب تكوين ديناميكية مساءً بشكل كاف. يستخدم هذا عادةً ondemand مساءً ، كما ينصح في نفس المنشور . ولكن هذا الأمر أسوأ ، لأن ondemand ينهي عمليات الخمول إلى الصفر عند وجود حركة مرور قليلة أو معدومة ، ونتيجة لذلك ، ستظل تعاني من التكاليف عند تغير حركة المرور. ما لم يكن ، بالطبع ، لقد حددت وقت انتظار كبير. ومن الأفضل استخدام pm.static + عدد كبير من pm.max_requests .
يمكن أن يكون تطبيق PM الديناميكي وخصوصًا عند الطلب مفيدًا إذا كان لديك عدة تجمعات PHP-FPM. على سبيل المثال ، تستضيف عدة حسابات cPanel أو مواقع ويب متعددة في تجمعات مختلفة. لدي خادم حيث ، على سبيل المثال ، أكثر من 100 حساب cpanel وحوالي 200 نطاق ، و pm.static أو حتى الديناميكي لن ينقذني. هناك حاجة فقط إلى ondemand هنا ، لأن أكثر من ثلثي مواقع الويب تتلقى حركة مرور قليلة أو معدومة على الإطلاق ، ومع ondemand ، ستنهار جميع العمليات الفرعية ، مما سيوفر لنا ذاكرة كبيرة! لحسن الحظ ، لاحظ مطورو cPanel ذلك وقاموا بتعيين القيمة الافتراضية إلى ondemand . في السابق ، عندما كانت القيمة الافتراضية ديناميكية ، لم تكن PHP-FPM مناسبة للخوادم المشتركة المشغولة على الإطلاق. استخدم الكثير من suPHP لأن الذاكرة الديناميكية المستهلكة مساءً حتى مع تجمعات الخمول وحسابات cPanel PHP-FPM. على الأرجح ، مع حركة مرور جيدة ، لن تتم استضافتك على خادم به عدد كبير من مجمعات PHP-FPM (استضافة مشتركة).
استنتاج
إذا كنت تستخدم PHP-FPM وكان لديك حركة مرور كثيفة ، فإن مديري العمليات على الطلب والديناميكي لـ PHP-FPM سيحدون من عرض النطاق الترددي بسبب تكاليفهم المتأصلة. فحص النظام الخاص بك وتكوين عمليات PHP-FPM الخاص بك لتتناسب مع الحد الأقصى لسعة الخادم الخاص بك. قم أولاً بتعيين pm.max_children بناءً على الحد الأقصى لاستخدام الساعة الديناميكية أو عند الطلب ، ثم قم بزيادة هذه القيمة إلى المستوى الذي ستعمل به الذاكرة والمعالج دون التحميل الزائد المفرط. ستلاحظ أنه مع ثابت pm ، نظرًا لأن كل شيء يتم تخزينه في الذاكرة ، ستتسبب قمم حركة المرور بمرور الوقت في تقليل عدد المعالجات إلى قمم أقل ، وستتساوى قيم تحميل الخادم والمعالج المتوسطة. يعتمد متوسط حجم عملية PHP-FPM على خادم الويب ويتطلب التكوين اليدوي ، وبالتالي فإن مديري العمليات الأوتوماتيكية - الديناميكية وعلى الطلب - أكثر شيوعًا. آمل أن المقالة كانت مفيدة.
UPD وأضاف مخطط الرسم البياني أب . إذا كانت عمليات PHP-FPM موجودة في الذاكرة ، فسيتم تحسين الأداء من خلال استهلاك الذاكرة في أماكن الجلوس والانتظار. ابحث عن الخيار الأفضل لنفسك.
