PHP-FPM چیست؟ آموزش بهینه‌ سازی تنظیمات PHP-FPM

بهینه‌ سازی تنظیمات PHP-FPM مبحثی مفصل و بسیار کاربردی است. هنگامی‌که کاربر آدرس وب‌سایتی را در مرورگر اینترنت خود وارد می‌کند، درواقع Request وی از مرورگر به‌سمت سرور ارسال می‌شود. حالا وب سرور وظیفه دارد تا این Request را دریافت و بررسی کند. در واقع، یکی از کارکردهای مهم‌ وب سرور تصمیم‌گیری درباره نحوه ارتباط با سرویس PHP و اجرای کدهای اسکریپت است. روش‌های مختلفی برای اجرای اسکریپت در وب سرور وجود دارد که متخصصان وب و سرور باید بر آن کاملاً مسلط باشند. به‌دلیل اهمیت این موضوع، در این مطلب از آموزش وب سرور بلاگ پارس پک قصد داریم درباره بهینه‌ سازی تنظیمات PHP-FPM با شما صحبت کنیم و روش انجام این کار را به شما آموزش دهیم؛ پس تا پایان با ما همراه باشید.

PHP-FPM چیست؟

PHP-FPM یکی از روش‌هایی است که با استفاده از آن، می‌توان پروتکل FastCGI را پیاده‌سازی کرد. این روش به‌عنوان جایگزینی شایسته برای روش‌های سنتی قبلی مانند SUPHP یا php_mod شناخته می‌شود. PHP-FTM به‌عنوان یک ماژول برای انواع وب‌سرورها مانند Apache و Nginx شناخته می‌شود و به مدیریت بهتر پردازش‌های PHP کمک زیادی می‌کند. این روش عملکرد سریع‌تری درمقایسه‌با روش‌های دیگر مانند php_mod در وب‌سرورهای مختلف مانند آپاچی دارد. درواقع، PHP-FPM مدیر فرآیند FastCGI برای زبان برنامه‌نویسی PHP است. با استفاده از PHP-FTM امکان تنظیم تعداد پردازش‌های PHP فراهم می‌شود و می‌توانید بارهای ورودی متوسط و زیاد را به‌صورت بهینه‌تر و بهتر مدیریت کنید. به‌طورکلی،‌ این روش امکان کنترل‌ دسترسی، تنظیم تعداد پردازش‌های PHP، محدودکردن منابع سیستمی و… را برای فرآیندهای PHP فراهم می‌کند. بنابراین، عملکرد وب‌سایت‌ها و برنامه‌های PHP بهبود می‌یابند و می‌توانید از منابع سرور استفاده بهینه‌تری داشته باشید.

معرفی هندلرهای PHP

هندلرهای PHP نوعی از ماژول‌های PHP هستند که وب سرور آپاچی ازطریق کتابخانه‌های موجود در آن‌ها، کدهای PHP را تفسیر و اجرا می‌کند. در ادامه، برخی از این هندلرهای مهم‌ را معرفی خواهیم کرد.

۱. هندلر PHP-CGI

از جمله روش‌هایی که برای اجرای اسکریپت در وب سرور استفاده می‌شود، «PHP-CGI» است که در آن به‌ازای هر Request، پردازشی برای اجرای اسکریپت PHP ایجاد و پس‌از‌آن حذف می‌شود. بدین‌ترتیب، بار پردازشی مضاعفی در سرور ایجاد نخواهد شد.

وب سرورها در ابتدا از این روش برای اجرای اسکریپت‌ها استفاده می‌کردند؛ اما مشکل این بود که هریک از درخواست‌های CGI باعث می‌شد که وب سرور به‌نوعی پردازشی جدید را آغاز و طی آن زمان اجرا را مقداردهی اولیه کند و اسکریپت را بارگذاری و در‌نهایت برنامه را برای تولید محتوا اجرا کند. این روند برای اسکریپت‌های ساده عالی بود؛ اما وقتی پای اپلیکیشن‌های پیچیده به‌میان می‌آمد، بار بسیار زیادی به وب سرور تحمیل یا منابع زیادی را درگیر می‌کرد.

در این روش، اسکریپت خارج از فضای وب سرور اجرا می‌شود و وب سرور درگیر اجرای اسکریپت‌ها نمی‌شود. مزیت این روش افزایش امنیت هنگام اجرای اسکریپت‌های آلوده و ایجاد بار کمتر روی وب سرور است؛ اما منابع زیادی مصرف می‌کند که به‌نوعی عیب آن محسوب می‌شود.

۲. هندلر mod_php

همان‌طورکه گفتیم، یکی از مشکلات اساسی PHP-CGI بار اضافی زیادی بود که حین استفاده از اپلیکیشن‌های پیچیده روی وب سرور اِعمال می‌شد. برای حل این مشکل، وب سرور آپاچی ماژول mod-php را معرفی کرد که با استفاده از آن، PHP در خود Apache اجرا می‌شد. این ماژول به‌ازای هر درخواست، یک فرایند (Process) ایجاد می‌کند تا به PHP متصل شود. به این روش PHP as a Module می‌گویند‌؛ به‌همین‌دلیل، این ماژول به mod_php نیز شهرت دارد.

اگرچه با این راهکار مشکل سربار Request هر‌یک از فرایندها حل شد، مشکل اساسی دیگری همچنان پابرجا بود: این روش فقط می‌توانست به‌صورت Vertical مقیاس‌بندی شود و همین مسئله باعث می‌شد که فقط در سرورهای بزرگ‌تر انجام‌شدنی باشد. علاوه‌براین، احتمالاً مشکلات امنیتی و موضوعات زمان اجرا (Runtime) و مصرف زیاد منابع به مشکلات اضافه می‌شد.

۳. هندلر PHP-FastCGI

مزایای موجود در روش PHP-CGI‌، در روش PHP-FastCGI حفظ و معایب آن نیز تا حد زیادی رفع شده است. نحوه انجام کار در این روش بدین‌ترتیب است که هر‌یک از فرایندهای ایجاد‌شده به بیشتر از یک درخواست پاسخ می‌دهد. در روش مذکور، هر‌یک از فرایندها روی یک سوکت در وب سرور اجرا می‌شود و بدین‌ترتیب، به Requestهای مرتبط پاسخ می‌دهد.

نکته مهم دیگر این است که در PHP-FastCGI اپلیکیشن به فرایندی جداگانه در خارج از وب سرور یا حتی به یک یا چند سرور مختلف هدایت و به اپلیکیشن این امکان داده می‌شود که به‌صورت افقی (Horizontal) نیز مقیاس‌پذیر شود. بدین‌ترتیب، مشکلات موجود در روش‌های متداول قبلی با استفاده از FastCGI حل شد.

در وب سرور آپاچی، برای استفاده از FastCGI به‌عنوان هندلر باید کدی شبیه به کد زیر را در فایل .htaccess قرار دهید:

<Directory /usr/local/apache/fcgi-bin/>
SetHandler fcgid-script
Options +ExecCGI
# Customize the next two directives for your requirements.
Order allow,deny
Allow from all
</Directory>

ناگفته نماند که پارامترهای مختلف دیگری را می‌توان برای FastCGI تنظیم کرد که در این لینک می‌توانید جزئیات آن‌ها را مشاهده کنید. همچنین، تنظیمات fastCGI به‌عنوان هندلر در وب سرور Nginx از قرار زیر است:

 

location ~ .php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass unix:/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

پارامترهای مختلف و جزئیات آن‌ را نیز می‌توانید در این لینک مشاهده کنید.

۴. هندلر PHP-FPM

PHP-FPM (FastCGI Process Manager) روشی برای مدیریت پردازش‌های fastCGI است که بیشتر برای وب‌سایت‌هایی با ترافیک بسیار زیاد استفاده می‌شود. در این روش، صفحات PHP با انواع وب سرور مانند Apache و Nginx پیاده‌سازی و همین امر باعث می‌شود تا اسکریپت‌های PHP با سرعت بیشتری از روش‌های سنتی مبتنی‌بر CGI مثل SUPHP یا mod_php اجرا شوند. مزیت اصلی روش PHP-FPM استفاده کمتر از منابع مانند RAM و CPU است و در‌نتیجه، باعث صرفه‌جویی در هزینه‌های شما خواهد شد.

روش کار هندلر PHP-FPM

هنگامی‌که کاربر اینترنت Request خود را ازطریق مرورگر یا هر اپلیکیشن دیگری به‌سمت سرور ارسال می‌کند، PHP نیست که مسئولیت دریافت Request را بر‌عهده دارد؛ بلکه درواقع این وظیفه بر‌عهده وب سرور است. در گام بعدی، وب سرور باید تصمیم بگیرد که چگونه با سرویس PHP ارتباط برقرار و نوع Request و داده‌ها و Headerها را به آن منتقل کند. تصویر زیر می‌تواند در درک عمیق‌تر این مفهوم به شما کمک کند:

اسکریپت‌های PHP که در بخش Find File تصویر بالا نشان داده شده، حاوی فایل اصلی اسکریپت، یعنی index.php است و سرور تمامی Requestها را به آن واگذار می‌کند. به‌طورخلاصه، در این حالت ماژول PHP درون وب سرور قرار می‌گیرد.

این مسئله سبب می‌شد که پس از دریافت هر Request، سرور فرایند جدیدی را شروع کند که به‌صورت خودکار شامل اجرای PHP نیز بود. این همان روش mod_php است که به معایب و مشکلات آن اشاره کردیم؛ ولی درنهایت روش php-fpm توانست این مشکلات را تا حد زیادی برطرف کند.

در php-fpm، فرایندهای مرتبط با برنامه PHP خارج از وب سرور است و درواقع، وب سرور اهمیتی نمی‌دهد که فایل‌های اسکریپت PHP شما در کجا قرار دارد؛ بلکه تنها موضوع مهم این است که داده‌ها چطور برای آن ارسال یا از آن دریافت می‌شود.

درادامه، نمونه‌ای از تنظیمات وب سرور آپاچی را مشاهده می‌کنید که از php-fpm به‌عنوان هندلر استفاده شده است:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/html
    <Directory /var/www/html>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Require all granted
    </Directory>
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost/"
    </FilesMatch>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

در وب سرور Nginx، تنظیمات php-fpm بدین‌ترتیب است:

server {
         listen       80;
         server_name  example.journaldev.com;
         root         /var/www/html/wordpress;


         access_log /var/log/nginx/example.journaldev.com-access.log;
         error_log  /var/log/nginx/example.journaldev.com-error.log error;
         index index.html index.htm index.php;


         location / {
                      try_files $uri $uri/ /index.php$is_args$args;
         }


         location ~ \.php$ {
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass unix:/var/run/php7.2-fpm-wordpress-site.sock;
            fastcgi_index index.php;
            include fastcgi.conf;
    }
}

به کدهای درج‌شده برای وب سرور Nginx بازمی‌گردیم و کمی روی این خط کد متمرکز می‌شویم:

astcgi_pass unix:/run/php/php7.2-fpm.sock;

این همان خطی است که تقریباً هر کاری که نیاز داریم، انجام می‌دهد؛ یعنی به Nginx می‌گوید که ازطریق سوکتی به اسم php7.2-fpm.sock با فرایند PHP ارتباط برقرار کند. بنابراین، Nginx برای هریک از Requestهای دریافت‌شده داده‌ها را ازطریق همین فایل می‌نویسد و با دریافت خروجی، آن را به مرورگر کاربر ارسال می‌کند.

اگرچه در پشت‌پرده انجام این فرایند واقعاً ممکن است پیچیده باشد، به‌نظر می‌رسد که فعلاً تا همین‌جا کافی است. برای اینکه این نکات به‌‌خوبی در ذهنتان دسته‌بندی شود، اجازه دهید آن‌ها را به‌صورت خلاصه درآوریم:

• PHP مستقیماً Requestهای ارسالی مرورگر کاربر را دریافت نمی‌کند؛ بلکه وب سرورها این درخواست‌ها را رهگیری می‌کنند.
• وب سرورها می‌دانند که چطور باید به فرایند PHP متصل شوند و تمامی داده‌های Requestها را به PHP ارسال کنند.
• هنگامی‌که PHP کار خود را به‌پایان رساند، Response مناسب را به وب سرور ارسال می‌کند و در‌نهایت این پاسخ به مرورگر کاربر یا اصولاً هر اپلیکیشنی که از آن استفاده می‌کند، برگردانده می‌شود.

تصویر زیر این مفهوم را برای وب سرور Nginx بهتر توضیح می‌دهد:

در قسمت بعدی، نحوه پیکربندی وب سرور لایت اسپید و آپاچی با PHP-FPM را آموزش می‌دهیم.

پیکربندی PHP-FPM در وب سرور و کنترل پنل‌های مختلف

حالا که به‌طورکلی با PHP-FPM آشنا شدید، نحوه پیکربندی PHP-FPM را در وب سرور و کنترل پنل‌های مختلف نیز یاد بگیرید. درادامه، روش این کار را به شما آموزش خواهیم داد.

۱. تنظیمات php.ini وب سرور لایت اسپید/آپاچی در دایرکت ادمین

اگر از کنترل پنل دایرکت ادمین استفاده کنید، برای مقداردهی PHP-FPM می‌توانید فایل php.ini را براساس نیازتان اصلاح کنید. فراموش نکنید که هر‌یک از نسخه‌های PHP فایل php.ini خاص خود را دارند. با استفاده از دستور php -i|grep php.ini، می‌توانید مسیر اصلی این فایل را پیدا کنید. نحوه استفاده از این دستور در تصویر زیر نشان داده شده است:

درصورتی‌که نسخه‌های متفاوتی از PHP روی سیستم فعال شده باشد، فایل PHP.ini آن‌ها نیز در مسیری متناظر با نسخه 7.4 قرار دارد. در این مثال، نسخه‌های فعال PHP و فایل‌های php.ini هر نسخه در مسیر زیر قرار دارند:

 

برای تغییر مقادیر php.ini در هر نسخه از PHP، باید فایل مربوط به آن نسخه را تغییر دهیم:

/usr/local/php74/lib/php.ini

/usr/local/php73/lib/php.ini

/usr/local/php81/lib/php.ini

به‌منظور تغییر مقدار memory_limit (محدودیت حافظه رم) برای اجرای اسکریپت‌ها، فایل php.ini مدنظر را با یکی از ادیتورهای متن باز می‌کنیم:

vim /usr/local/php74/lib/php.ini

سپس، در این فایل با وارد‌کردن دستور /memory_limit مقدار memory_limit را جست‌وجو می‌کنیم:

 

علاوه‌بر مقدار memory_limit، مقادیر دیگر نیز تغییر‌پذیر هستند:

post_max_size

upload_max_filesize

max_execution_time

max_input_time

بدین‌ترتیب، می‌توانیم محدودیت های php.ini را متناسب با نیازمان تغییر دهیم. پس از اِعمال تغییرات، باید وب سرور و هندلر را ری‌استارت کنیم. برای این منظور، از دستور زیر استفاده می‌کنیم:

 

 

برای اطمینان از عملکرد صحیح تغییرات اِعمال‌شده، اسکریپتی ساده را با محتوای زیر در وب‌سایت خود بارگذاری می‌کنیم:

<?php phpinfo(); ?>

حالا اگر این اسکریپت را اجرا کنیم، مقادیر تنظیم‌شده در مرحله قبلی نشان داده خواهد شد:

این نکته‌ را از خاطر نبرید که این تغییرات روی تمامی کاربران اِعمال خواهد شد. درصورتی‌که قصد دارید این تغییرات را فقط برای کاربری مشخص انجام دهید، باید این کار را ازطریق گزینه Custom Httpd Configuration و با سطح دسترسی Admin انجام دهید.

بعد از مراجعه به این قسمت، مشاهده خواهیم کرد که برای هر دامنه یک فایل پیکربندی مجزا وجود دارد. روی دامنه مدنظر خود کلیک می‌کنیم و در قسمت |CUSTOM2|، مقدار زیر را قرار می‌دهیم:

php_value[memory_limit] = 256M

درصورتی‌که تگ php_value براساس پیکربندی‌های مختلف متفاوت بود، باید یکی از مقادیر زیر را به‌جای آن قرار دهیم:

php_admin_value, php_flag, php_admin_flag

۲. پیکربندی وب سرور آپاچی با PHP-FPM در کنترل پنل Cpanel

در سی پنل می‌توان مقدار php.ini را برای هر نسخه از PHP ازطریق پنل whm (با سطح دسترسی root) تغییر داد. برای این کار، باید از پنل whmcs وارد قسمت Software > Multi PHP INI Editor شویم و مقادیر پیش‌فرض php.ini را اصلاح کنیم. مقادیری که در این قسمت وجود دارند، عبارت‌اند از:

max_execution_time

max_input_time

max_input_vars

memory_limit

post_max_size

upload_max_filesize

upload_max_filesize

این گزینه‌ها در تصویر زیر نیز نشان داده شده‌اند:

همچنین، برای هر کاربر به‌صورت مجزا می‌توان این مقادیر را تغییر داد. برای این کار، از داشبورد Cpanel خود گزینه Software > Multi PHP INI Editor را انتخاب می‌کنیم:

در این قسمت، می‌توان مقادیر PHP.ini را برای کاربر دلخواه تغییر داد. این مقادیر ازاین‌قرارند:

max_execution_time

max_input_time

max_input_vars

memory_limit

post_max_size

session.gc_maxlifetime

upload_max_filesize

در تصویر زیر، این گزینه‌ها را مشاهده می‌کنیم:

۳. نحوه پیکربندی وب سرور لایت اسپید/آپاچی با PHP-FPM در توزیع اوبونتو (بدون کنترل پنل)

درصورتی‌که از هیچ کنترل پنلی روی سرور خود استفاده نمی‌کنید، باز‌هم امکان پیکربندی وب سرور با PHP-FPM وجود دارد. درادامه این مقاله از بلاگ پارس پک، نحوه انجام این کار را برای توزیع اوبونتو توضیح داد‌ه‌ایم.

اولین نکته‌ برای پیکربندی وب سرور آپاچی با PHP-FPM این است که این وب سرور به‌صورت پیش‌فرض از mod_php استفاده می‌کند. برای پیکربندی، مراحل زیر را به‌ترتیب انجام می‌دهیم:

۱. غیرفعال‌کردن تنظیمات Apache vhost

برای شروع کار، ابتدا باید تنظیمات پیش‌فرض Apache vhost را غیرفعال کنیم. برای این منظور از دستور زیر بهره می‌بریم:

sudo a2dissite 000-default

۲. فعال‌کردن ماژول Apache Event

در این مرحله، باید تمامی ماژول‌های پیش‌فرض را برای تمامی نسخه‌های موجود PHP غیرفعال کنیم. این کار را با استفاده از دستور زیر انجام خواهیم داد:

sudo a2dismod php7.4

بعد از انجام این کار، باید ماژول Apache Prefork را با استفاده از دستور زیر غیرفعال کنیم:

sudo a2dismod mpm_prefork

سپس، مجدداً ماژول Apache Event را فعال می‌کنیم:

sudo a2enmod mpm_event proxy_fcgi setenvif

۳. فعال‌کردن پیکربندی PHP FPM

حالا با استفاده از دستور زیر، می‌توانیم پیکربندی PHP FPM را انجام دهیم:

sudo a2enconf php8.1-fpm

۴. فعال‌کردن HTTP2

درصورت نیاز به استفاده از HTTP2‌، با کمک دستور زیر می‌توانیم این کار را انجام دهیم:

sudo a2enmod http2

بدین‌ترتیب، Apache با PHP-FPM پیکربندی خواهد شد.

خلاصه‌ای درباره تنظیمات PHP-FPM

به‌طورخلاصه برای تنظیم پارامترهای PHP-FPM باید فایل پیکربندی PHP که با نام php.ini روی سرور ذخیره شده است، بیابیم و در آن، پارامترهای زیر را براساس نیاز خود اصلاح کنیم:

upload_max_filesize = 32M

post_max_size = 48M

memory_limit = 256M

max_execution_time = 600

max_input_vars = 3000

max_input_time = 1000

بعد از اتمام مراحل ویرایش فایل php.ini‌، باید PHP-FPM را مجدداً راه‌اندازی کنیم تا تغییرات اِعمال شوند. برای این منظور نیز، از دستور زیر استفاده می‌کنیم:

sudo systemctl restart httpd
sudo systemctl restart php8.1-fpm

بهینه‌ سازی تنظیمات PHP-FPM

برای راه‌اندازی وب‌سایت، استفاده بهینه از منابع و مدیریت آن بسیار اهمیت دارد؛ زیرا درصورت ایجاد محدودیت روی وب سرور برای استفاده از منابع، اگر تعداد بازدیدکنندگان از وب‌سایت زیاد شود یا بخواهیم تعداد صفحات و به‌طور‌کلی حجم اطلاعات را افزایش دهیم، ممکن است وب‌سایت با خطا مواجه شود.

افزون‌براین، اگر محدودیت‌های وب سرور بیش‌از‌حد افزایش یابد، هنگام افزایش درخواست‌ها منابع سرور برای پاسخ‌گویی به درخواست‌ها دچار کمبود و باعث از‌کار‌افتادن سرویس‌ها خواهد شد. بنابراین، براساس نوع نیاز وب‌سایت، تعداد بازدیدکنندگان، تعداد Requestهای ارسال‌شده به‌سمت سرور و…، باید محدودیت‌هایی را اِعمال کرد تا از این طریق بتوان از منابع سرور به‌صورت بهینه استفاده کرد.

برای بهینه‌سازی Apache 2، مراحل زیر را به‌ترتیب دنبال می‌کنیم:

۱. محاسبه اندازه Process

ابتدا باید به این پرسش پاسخ دهیم که امکان اجرای چند Process روی دستگاه ما وجود دارد؟ برای این منظور باید اندازه Processهای درایورهای اصلی CPU را اندازه‌گیری کنیم. برای انجام این کار، روش‌های مختلفی وجود دارد. یکی از این روش‌ها استفاده از اسکریپت پایتون زیر است که با درنظرگرفتن میزان حافظه مشترک، اندازه واقعی‌تری از اندازه ‌Process به ما ارائه می‌دهد:

cd ~
wget https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py
chmod a+x ps_mem.py
sudo python ps_mem.p

ps_mem.py خروجی‌های زیر را به ما نشان خواهد داد:

خروجی بالا به ما نشان می‌دهد که ۳۰ فرایند ‌‌Apache 2 وجود دارد که همه آن‌ها در‌مجموع ۱۳۰ مگابایت از رم را استفاده می‌کنند. بنابراین، هر‌یک از فرایندهای آپاچی حدود ۵ مگابایت و فرایند php-fpm5.6 نیز حدود ۵۰ مگابایت از رم را ازآنِ خود کرده‌اند.

۲. محاسبه‌ و تنظیم MaxRequestWorkers در آپاچی

پیشنهاد می‌کنیم که حدود ۱۵درصد از ظرفیت رم خود را برای تمامی Processهای پیش‌بینی‌نشده دیگر کنار بگذارید. همچنین، برای گِرد‌کردن میزان حافظه موردنیاز در هر‌یک از Processهای آپاچی، از دستور زیر می‌توان استفاده کرد. در نمونه‌ای که درادامه آمده است، این میزان براساس نتیجه‌ای که از مرحله قبلی به‌دست آمد، به ۵ مگابایت گِرد شده است:

MaxRequestWorkers = (Total RAM - Memory used for Linux, DB, etc.) / process size
MaxRequestWorkers = (16384MB - 2400MB) / 5MB = 2800

۳. محاسبه و تنظیم PHP-FPM Max-Children

در این مرحله نیز، پیشنهاد می‌کنیم که حدود ۱ گیگابایت از ظرفیت رم خود را برای Processهای دیگر و نزدیک به ۵۵ مگابایت را برای هر‌یک از Processهای PHP کنار بگذارید. این کار با استفاده از کدهای زیر انجام خواهد شد:

maxclients = (Total RAM - Memory used for Linux, DB, etc.) / process size
maxclients = (16384MB - 2400MB) / 55MB = 256

۴. تنظیمات دقیق

برای اِعمال تنظیمات دقیق در این رابطه، فایل /etc/apache2/mods-enabled/mpm-event.conf یا /etc/apache2/mods-enabled/mpm-worker.conf را می‌توانیم به‌صورت زیر ویرایش کنیم:

<IfModule mpm_*_module>
 ServerLimit           (Total RAM - Memory used for Linux, DB, etc.) / process size
 StartServers          (Number of Cores)
 MinSpareThreads       25
 MaxSpareThreads       75
 ThreadLimit           64
 ThreadsPerChild       25
 MaxRequestWorkers    (Total RAM - Memory used for Linux, DB, etc.) / process size
 MaxConnectionsPerChild   1000
</IfModule>

استفاده از این روش به ما امکان خواهد داد تا حتی فاکتورهایی را تغییر دهیم که در تنظیمات پیش‌فرض نمی‌توانستیم تغییرشان دهیم. به‌عنوان نمونه، در تنظیمات پیش‌فرض امکان تنظیم فاکتور ServerLimit فراهم نبود؛ اما با استفاده از این روش آن را نیز تغییر داده‌ایم. همچنین، در فایل /etc/php/7.1/fpm/pool.d/www.conf می‌توانیم تغییرات زیر را اِعمال کنید:

pm = dynamic
pm.max_children (total RAM – (DB etc) / process size)
pm.start_servers (cpu cores * 4)
pm.min_spare_servers (cpu cores * 2)
pm.max_spare_servers (cpu cores * 4)
pm.max_requests 1000

۵. اِعمال تغییرات نهایی

فرض می‌کنیم که سرور ما ۱۶ گیگابایت رم و ۴ هسته CPU با فرکانس ۲.۴ گیگاهرتز دارد. بر همین اساس، فایل /etc/apache2/mods-available/mpm_event.conf را به‌صورت زیر تغییر می‌دهیم:

# Optimized settings for avg. apache process 15MB and AWS EC2 m4.xlarge Server
<IfModule mpm_event_module>
       ServerLimit              2800
       StartServers             4
       MinSpareThreads          25
       MaxSpareThreads          75
       ThreadLimit              64
       ThreadsPerChild          25
       MaxRequestWorkers        2800
       MaxConnectionsPerChild   1000
</IfModule>

فایل /etc/php/7.1/fpm/pool.d/www.conf را نیز به‌صورت زیر تغییر می‌دهیم:

; Optimized for php-fpm request size of 55MB on AWS EC2 m4.xlarge (4CPU cores, 16GB RAM)
pm = dynamic
pm.max_children = 256
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests = 1000

حالا باید تغییرات اِعمال‌شده را ذخیره و در‌نهایت آپاچی و PHP-FPM را مجدداً راه‌اندازی کنیم:

sudo service apache2 restart
sudo service php7.1-fpm restart

رویداد MPM در وب سرور آپاچی

در طول سال‌هایی که از رونمایی Apache HTTP می‌گذرد، این وب سرور تکامل یافته و حالا به مرحله‌ای رسیده است که می‌تواند نیازهای مختلف کاربران را کاملاً برطرف کند. باوجوداین‌، این وب سرور هنوزهم مشکلاتی دارد. برای مثال، یکی از مشکلات مهم‌ این وب سرور نحوه مدیریت فرایندهای مختلف برای ارائه Requestهای پروتکل HTTP است که همین موضوع شامل باز‌کردن سوکت، پردازش Request، فعال نگه‌داشتن کانکشن در بازه زمانی مشخص، مدیریت Eventهای جدید که کانکشن با استفاده از آن‌ها انجام می‌شود و در‌نهایت بازگرداندن محتوای تولید‌شده در برنامه‌ای که با زبانی خاص مانند Perl یا PHP یا Python ساخته شده است.

این وظایف به‌واسطه ماژولی چند‌پردازشی (MPM) انجام و کنترل می‌شود. Apache HTTP با سه MPM مختلف ارائه می‌شود. درادامه، درباره هر‌یک از آن‌ها بیشتر صحبت می‌کنیم.

۱. Pre-fork

Pre-fork یکی از ماژول‌های پردازش موازی است که با استفاده از آن برای هر کانکشن ورودی که به سرور می‌رسد، Process جدیدی ایجاد می‌شود. هر‌یک از فرایندها به‌طورکامل از فرایندهای دیگر جداسازی می‌شود و بدین‌ترتیب، هیچ حافظه‌ای بین آن‌ها به اشتراک گذاشته نمی‌شود؛ حتی اگر در نقطه‌ای از اجرا Call یکسانی انجام دهند. Pre-fork روشی ایمن برای اجرای برنامه‌هایی است که از کتابخانه‌هایی استفاده کرده‌اند که در آن‌ها از خاصیت Threading پشتیبانی نمی‌شود. بنابراین، می‌توان نتیجه گرفت که این ماژول به‌ویژه برای برنامه‌هایی مفید است که در آن‌ها از کتابخانه‌های قدیمی‌تر استفاده شده است.

۲. Worker

در این ماژول پردازش موازی، یک Process والد مسئولیت راه‌اندازی مجموعه‌ای از Processهای فرزند را بر‌عهده دارد که برخی از آن‌ها برای گوش‌دادن (Listen) به کانکشن‌های جدید و برخی دیگر برای ارائه محتواهای درخواستی استفاده می‌شوند. در این ماژول، هر‌یک از فرایندها به‌صورت چند‌رشته‌ای است و هر رشته می‌تواند یک کانکشن را ایجاد کند؛ بنابراین در ماژول Worker، هر Process می‌تواند چندین Request را هم‌زمان انجام دهد.

۳. Event

Event نیز ماژول پردازش موازی است که درواقع، می‌توان به آن پیاده‌سازی دیگری از ماژول Worker لقب داد؛ اما با یک تفاوت اساسی. در این ماژول، هر کانکشن به‌صورت پیش‌فرض به‌مدت ۵ ثانیه باز و فعال خواهد ماند و درصورتی‌که Event جدیدی اتفاق نیفتاد، به‌طورخودکار بسته خواهد شد. این زمان نیز همان زمان پیش‌فرضی است که در دستورالعمل Keep-Alive وجود دارد و رشته‌های مرتبط با آن را حفظ خواهد کرد.

با استفاده از Event MPM خواهید توانست فرایندها را مدیریت کنید؛ بدین‌ترتیب که برخی از رشته‌ها برای مدیریت کانکشن‌های ورودی جدید آزاد باقی خواهند ماند و برخی دیگر در‌اختیار کانکشن‌های جاری قرار خواهند گرفت.

PHP-FPM نیز درواقع برای مدیریت فرایندهای FastCGI در PHP به‌کار گرفته می‌شود. پروتکل FastCGI مبتنی‌بر واسط دروازه مشترک (CGI) است که به‌عنوان پروتکل بین وب‌سایت و وب سرورهایی مانند Apache HTTP شناسایی می‌شود.

استفاده از این پروتکل به توسعه‌دهندگان امکان می‌دهد تا وب‌سایت‌ها و اپلیکیشن‌های خود را به‌صورت جداگانه از رفتارهای وب سرور توسعه دهند. با ترکیب Event MPM در Apache HTTP با PHP-FPM، سرعت لود وب‌سایت بیشتر و کانکشن‌های بیشتری با استفاده از منابع کمتر سرور برقرار خواهد شد.

مقایسه عملکرد MPM Pre-fork و MPM Worker

همان‌طورکه گفتیم، Pre-fork و Worker هر دو از ماژول‌هایی هستند که بر‌پایه PHP طراحی شده‌اند و هر‌یک مزایا و معایب خود را دارند. به‌عنوان مثال، MPM Prefork از امنیت بیشتری برخوردار است؛ اما این دو تفاوت‌های دیگری هم دارند. درادامه، این تفاوت‌ها را بررسی خواهیم کرد.

۱. تفاوت MPM Pre-fork و MPM Worker ازنظر استفاده از منابع

به‌طور‌کلی، MPM Worker ازنظر استفاده از منابع کارایی بیشتری دارد. به‌عبارت‌دیگر، این ماژول درمقایسه‌با MPM Worker از منابع کمتری استفاده می‌کند و دلیل این موضوع هم استفاده از رشته‌ها به‌جای Processهای جداگانه است.

۲. تفاوت MPM Pre-fork و MPM Worker ازنظر عملکرد

اگر بخواهیم این دو ماژول را ازنظر عملکرد با‌هم مقایسه کنیم، باز‌هم کفه ترازو به‌سمت MPM Worker سنگینی خواهد کرد. درواقع، این ماژول برای استفاده در وب‌سایت‌هایی با ترافیک فراوان طراحی شده است؛ به‌همین‌دلیل، درمقایسه‌با MPM Pre-fork عملکرد بهتری دارد.

۳. تفاوت MPM Pre-fork و MPM Worker ازنظر سازگاری

وقتی می‌خواهیم دو ماژول را ازنظر سازگاری با یکدیگر مقایسه کنیم، باید ببینیم که چه انتظاری از ماژول داریم. MPM Pre-fork با اپلیکیشن‌های طراحی‌شده با PHP سازگاری بیشتری دارد؛ اما MPM Worker برای وب‌سایت‌ها و وب‌اپلیکیشن‌هایی مناسب‌تر است که از فناوری‌ mod_perl و مانند آن استفاده کرده باشند.

۴. تفاوت MPM Pre-fork و MPM Worker ازنظر پایداری

آخرین معیار موجود برای مقایسه این دو ماژول پایداری است. ازنظر پایداری، ماژول MPM Pre-fork به‌دلیل سادگی بیشتر در میدان رقابت با MPM Worker برنده میدان است. اگر می‌خواهید د‌راین‌باره اطلاعات بیشتری به‌دست آورید، می‌توانید از این لینک‌ها استفاده کنید:

httpd.apache.org/mpm

httpd.apache.org/mod/prefork

تنظیمات Worker-MPM در پنل لایت اسپید

با‌توجه‌به اینکه استفاده از MPM Worker در بسیاری از مواقع مزیت‌های بیشتری از MPM Pre-fork دارد و منابع کمتری هم برای تنظیمات آن در‌دسترس است، درادامه قصد داریم تنظیمات این ماژول را در پنل لایت اسپید برای شما توضیح دهیم.

برای استفاده از حالت ProcessGroup، در قدم اول باید گزینه Start By Server روی Yes تنظیم شده باشد. برای انجام این کار، مسیر WebAdmin Console > Configuration > External App > your_external_application را انتخاب و سپس ازطریق CGI Daemon یا Daemon Async، مقدار Start By Server را روی Yes تنظیم می‌کنید. در محیط LiteSpeed Web Server (حالت Native)، می‌توانید حالت ProcessGroup را با قراردادن Instances روی عدد ۱ و LSAPI_CHILDREN روی عددی بیشتر از ۱ فعال کنید.

همچنین، اگر از محیط کنترل پنل استفاده می‌کنید، حالت ProcessGroup را با قرار‌دادن گزینه LSPHP_ProcessGroup روی directive در فایل httpd.conf می‌توانید فعال کنید. توجه کنید که اگر این کار در سطح Server انجام شود، تمامی هاست‌های مجازی که از سرور منشعب شده‌اند، از حالت ProcessGroup استفاده خواهند کرد. بااین‌حال، اگر این کار در سطح Virtual Host انجام شود، فقط همان هاست مجازی از این حالت استفاده خواهد کرد.

درادامه، پیکربندی نمونه برای محیط کنترل پنل نشان داده شده است:

<IfModule LiteSpeed>
LSPHP_ProcessGroup on
LSPHP_Workers 15
</IfModule>

انواع پارامترهای کاربردی در Worker MPM عبارت‌اند از:

# worker MPM

# StartServers: initial number of server processes to start

# MaxClients: maximum number of simultaneous client connections

# MinSpareThreads: minimum number of worker threads which are kept spare

# MaxSpareThreads: maximum number of worker threads which are kept spare

# ThreadsPerChild: constant number of worker threads in each server process

# MaxRequestsPerChild: maximum number of requests a server process serves

در‌نهایت، نحوه مقداردهی این پارامترها در وب سرور لایت اسپید و آپاچی به‌صورت زیر خواهد بود:

<IfModule worker.c>  
StartServers         2  
MaxClients         150  
MinSpareThreads     25  
MaxSpareThreads     75  
ThreadsPerChild     25  
MaxRequestsPerChild  0  
</IfModule> 

تنظیمات MPM-Prefork در پنل لایت اسپید

درادامه مطلب، نحوه تنظیم MPM-Prefork در پنل لایت اسپید را توضیح خواهیم داد. برای این کار، ابتدا با انواع پارامترهای MPM-Prefork باید آشنا شوید:

# prefork MPM

# StartServers: number of server processes to start

# MinSpareServers: minimum number of server processes which are kept spare

# MaxSpareServers: maximum number of server processes which are kept spare

# ServerLimit: maximum value for MaxClients for the lifetime of the server

# MaxClients: maximum number of server processes allowed to start

# MaxRequestsPerChild: maximum number of requests a server process serves

نحوه مقداردهی این پارامترها در وب سرور لایت اسپید و آپاچی بدین‌ترتیب است:

<IfModule prefork.c>  
StartServers       8  
MinSpareServers    5  
MaxSpareServers   20  
ServerLimit      256  
MaxClients       256  
MaxRequestsPerChild  4000  
</IfModule> 

 بررسی وضعیت و تغییر MPM

گاهی اوقات ممکن است بخواهید بدانید که در حال استفاده از کدام‌یک از ماژول‌های چند‌پردازشی (MPM) هستید. ساده‌ترین راه برای رسیدن به پاسخ، این است که همه ماژول‌های در حال اجرا را حذف و سپس MPM را انتخاب کنید. بدین‌ترتیب، خواهید فهمید که چه ماژولی در حال اجراست. برای انجام این کار، دو روش متداول وجود دارد:

۱. بررسی وضعیت MPM: استفاده از دستور apachectl -M

در این روش، باید از دستور زیر استفاده کنید:

# apachectl -M | grep mpm

پس از اجرای این دستور، نتیجه در خروجی به شما نشان داده خواهد شد:

mpm_worker_module (shared)

۲. بررسی وضعیت MPM: استفاده از دستور httpd -V

در این روش، از دستور زیر برای بررسی وضعیت MPM استفاده‌شده بهره ببرید:

# httpd -V | grep MPM

خروجی این دستور نیز مشابه با خط زیر است که در آن نوع MPM به‌وضوح گزارش شده است:

نحوه تغییر MPM

بعد از اینکه به این نتیجه رسیدید که از کدام نوع MPM استفاده می‌کنید، ممکن است بخواهید آن را تغییر دهید. نحوه انجام این کار به نوع توزیعی بستگی دارد که از آن استفاده می‌کنید. به‌عنوان مثال، درصورتی‌که از توزیع CentOS استفاده کنید، این کار در فایلی انجام خواهد شد که از مسیر /etc/httpd/conf.modules.d/00-mpm.conf دردسترس است.

به‌عنوان مثال، فرض کنید می‌خواهید Prefork MPM را به Worker MPM تغییر دهید. برای این منظور، مراحل زیر را به‌ترتیب انجام دهید:

گام اول: غیرفعال‌کردن ماژول Prefork

باتوجه‌به اینکه فرض کرده‌ایم در حال استفاده از ماژول Prefork هستیم، اولین قدم این است که ماژول یادشده را غیرفعال کنیم. برای انجام این کار، فایل 00-mpm.conf را با استفاده از دستور زیر در ویرایشگر متن باز می‌کنیم:

$ sudo nano /etc/httpd/conf.modules.d/00-mpm.conf

سپس، MPM فعال را با قرار‌دادن علامت # در ابتدای خط به‌ حالت کامنت درمی‌آوریم:

#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

گام دوم: فعال‌کردن Worker MPM

حالا باید ماژول Worker MPM را فعال و خط مدنظر را از حالت کامنت خارج کنیم:

LoadModule mpm_worker_module modules/mod_mpm_worker.so

حالا فایل پیکربندی ما باید مشابه با تصویر زیر باشد:

گام سوم: ذخیره تغییرات و راه‌اندازی مجدد وب سرور

در گام پایانی، باید تغییرات را ذخیره و وب سرور آپاچی را مجدداً راه‌اندازی کنیم تا تغییرات روی وب سرور اِعمال شود. برای این منظور، می‌توانیم از دستور زیر استفاده کنیم:

$ sudo systemctl restart httpd

تفاوت Process Modeها در وب سرور لایت اسپید

همان‌طورکه می‌دانید، وب سرور لایت اسپید حالت‌های مختلفی از فرایندهای PHP را برای برآورده‌کردن نیازهای شرکت‌های هاستینگ ارائه می‌کند؛ ازجمله ProcessGroup و Daemon و Worker. جدول زیر به شما کمک می‌کند تا با تفاوت‌های مهم این Modeها آشنا شوید:

Worker	Daemon	ProcessGroup
خیر	بله	بله	فورک‌کردن Processها به‌جای ایجاد Process جدید
۰	۱	۱ برای هر Process گروهی (هر کاربر)	تعداد Processهای والد
بله	بله	بله	امکان سفارشی‌سازی تعداد Processهای هر اکانت
خیر	خیر	بله	امکان فعال‌سازی فقط روی هاست مجازی خاص
بله	خیر	بله	پشتیبانی از php.ini سفارشی‌سازی شده (به‌عنوان نمونه CageFS سفارشی)
خیر	در کل سرور به‌اشتراک گذاشته می‌شود	اختصاصی برای هر کاربر	Opcode Caching

معرفی Workerها و نحوه فعال‌کردن آن‌ها در کنترل پنل‌های مختلف

درادامه، قصد داریم باتوجه‌به اهمیت ویژه Workerها در‌این‌باره بیشتر با شما صحبت کنیم و نحوه فعال‌سازی آن را در کنترل پنل‌های مختلف توضیح دهیم. فراموش نکنید که برای به‌دست‌آوردن عملکرد حداکثری در وب‌سایت، تنظیم مقادیر Worker باید براساس نیازهای وب‌سایت و منابع سرور و تعداد بازدیدهای وب‌سایت انجام شود.

Worker چیست؟

همان‌طورکه گفتیم، تمامی Requestهای PHP را PHP-FPM دریافت می‌کند و سپس در فرایندهای PHP که Worker نامیده می‌شوند، توزیع خواهد شد. با استفاده از این راهکار، به تمامی Requestها به‌صورت موازی پاسخ داده خواهد شد. توجه کنید که FPM تنها می‌تواند Requestهای جدید را به Workerهایی ارسال کند که در وضعیت idle قرار داشته باشند؛ یعنی در‌حال‌حاضر Request فعالی ندارند. اگر هیچ Worker آزادی وجود نداشته باشد، ارسال Request تا زمان آزاد‌شدن Worker به‌تعویق خواهد افتاد.

از همین قسمت می‌توان به نتیجه‌‌ای منطقی رسید: هدف نهایی ما برای عملکرد بهینه وب‌سایت یا وب‌اپلیکیشن این است که در هر زمان Worker آزادی وجود داشته باشد تا بتواند به Request جدید احتمالی پاسخ دهد. واضح است که اگر تعداد Workerها نتواند این شرط را تأمین کند، عملکرد وب‌سایت دچار اختلال خواهد شد. همچنین، اگر تعداد Workerهای آزاد زیادتر از حد طبیعی باشد، یعنی منابع بیشتر از نیازمان انتخاب شده است.

جدول زیر به شما کمک می‌کند تا بتوانید تعداد Workerها و میزان حافظه سرور را براساس تعداد بازدیدکنندگان وب‌سایت به‌صورت سرانگشتی محاسبه کنید:

تنظیمات پیشنهادی	حافظه آزاد	تعداد بازدید از وب‌سایت
۱۰ ورکر با زمان‌بندی درخواستی	۲ تا ۴ گیگابایت	وب‌سایت با بازدید پراکنده
۱۵ تا ۳۰ ورکر با زمان‌بندی درخواستی	۴ تا ۱۰ گیگابایت	وب‌سایت با تعداد بازدیدکننده کم
۲۰ تا ۴۰  ورکر با زمان‌بندی داینامیک	۸ تا ۱۵ گیگابایت	وب‌سایت با بازدید منظم روزانه
۴۰ تا ۶۰ ورکر با زمان‌بندی داینامیک	بیش از ۱۵ گیگابایت	وب‌سایت با بازدید فراوان
پیشنهاد می‌کنیم برای این وب‌سایت‌ها با تیم پشتیبانی شرکت هاستینگ خود تماس بگیرید و با آن‌ها مشورت کنید.		وب‌سایت‌های برگزار‌کننده کمپین‌های بزرگ تبلیغاتی با بازدیدکنندگان بسیار زیاد و رو‌به‌رشد

نحوه فعال‌سازی Worker در کنترل پنل‌های مختلف

اگر‌چه برای فعال‌سازی Worker در کنترل پنل‌های مختلف مسیر تقریباً یکسانی وجود دارد، درادامه مراحل گام‌به‌گام انجام این کار را در کنترل پنل‌های سی پنل و دایرکت ادمین توضیح خواهیم داد. همچنین، برای آن دسته از افرادی که از کنترل پنل روی سرور خود استفاده نمی‌کنند، روش دستی انجام این کار را ذکر خواهیم کرد.

۱. فعال‌کردن worker در Cpanel

برای فعال‌سازی Worker در کنترل پنل cPanel، ابتدا ازطریق داشبورد WHM وارد بخش EasyApache می‌شویم و پس‌از‌آن گزینه Customize را انتخاب می‌کنی. نحوه دسترسی به این گزینه در تصویر زیر نشان داده شده است:

بعد از انتخاب این گزینه، قابلیت mod_mpm_worker در صفحه جدید به ما نشان داده خواهد شد که به‌راحتی می‌توانیم آن را فعال یا غیرفعال کنیم:

همچنین، درصورت بروز هر‌گونه تداخل با پکیج‌های دیگر‌ پیغام خطایی به ما نشان داده خواهد شد و cPanel به‌طورخودکار آن‌ها را حذف خواهد کرد. بعد از انجام این کار، cPanel از ما می‌خواهد تا فعال‌سازی Worker را تأیید کنیم:

پس از تأیید آن، ماژول mod_mpm_prefork غیرفعال و نصب آغاز می‌شود. بعد از اتمام عملیات، به‌منظور بررسی نصب صحیح mod_mpm_worker کافی است دستور زیر را در سرور اجرا کنیم:

apachectl -M|grep 'mpm'

درصورتی‌که خروجی معادل عبارت نشان‌داده‌شده در زیر باشد، نصب mod_mpm_worker به‌درستی انجام شده است:

 mpm_worker_module (shared)

۲. فعال‌کردن Workers در کنترل پنل Directadmin

براساس داکیونت‌های دایرکت ادمین، اگر از حالت دیگری غیر از mod_php استفاده شود، حالت PHP-MPM به‌صورت خودکار به‌عنوان Loader فعال می‌شود. برای تنظیم به‌صورت پیش‌فرض، عبارت زیر را در فایل directadmin.conf وارد می‌کنیم:

php_fpm_max_children_default=10

سپس، از دستور زیر استفاده می‌کنیم:

cd /usr/local/directadmin/custombuild
./build rewrite_confs

در قسمت Custom از فایل Custom HTTP Confits، تنظیمات زیر را قرار می‌دهیم:

If you need to increase this on a per-domain basis, go to:
Admin Level -> Custom Httpd Config -> domain.com : click "php-fpm" for this domain.
Add this to the |CUSTOM1| token textarea:
|?MAX_CHILDREN=20|
|?MAX_REQUESTS=50|

این مقادیر تا عدد ۱۰۰ می‌توانند افزایش یابند:

|?MAX_CHILDREN=100|

درادامه، دستور زیر را اجرا می‌کنیم:

cd /usr/local/directadmin/custombuild
./build rewrite_confs

۳. فعال‌کردن Workers به‌صورت دستی (بدون کنترل پنل)

درصورتی‌که از هیچ کنترل پنلی روی سرور خود استفاده نمی‌کنید، برای فعال‌کردن Workers باید به‌صورت دستی اقدام کنید. ناگفته نماند که انجام این کار ممکن است محدودیت‌هایی هم به‌دنبال داشته باشد.

محدودیت‌ها

۱. مود ProcessGroup علاوه‌بر تمامی Processهای فرزند، همواره یک Process را هم در‌کنار آن‌ها در حالت اجرا نگه خواهد داشت. این موضوع Processهایی اضافی ایجاد می‌کند که در حالت‌های LiteSpeed Worker یا Daemon نخواهید داشت. ناگفته نماند که مشکل مذکور با تنظیم Max Idle Time تا حدی رفع‌شدنی است. تنظیم این فاکتور به LiteSpeed نشان می‌دهد فرایندهای والد ProcessGroup را که به‌مدت طولانی‌تر از زمان تعیین‌شده آزاد هستند، می‌توان از بین ببرد.

۲. کش شخصی Opcode باید نسبتاً زیاد باشد تا بتوان انتظار استفاده مدنظر را از آن داشت. این موضوع تقریباً بدین‌معنی است که با رم اضافی‌ کنارگذاشته‌شده برای ذخیره‌‌کردن کد رمز باید خداحافظی کنید. این در حالی است که این اتفاق در حالت Daemon رخ نخواهد افتاد. این موضوع استفاده از ProcessGroup را به هاست‌هایی محدود خواهد کرد که از رم اضافی خود برای بهبود عملکرد و نه ذخیره‌سازی کد رمز استفاده می‌کنند. همچنین، باید توجه کنید که نباید مقدار زیادی از رم خود را برای کش هر کاربر اختصاص دهید؛ زیرا در این‌ صورت با کمبود رم مواجه خواهید شد.

فعال‌سازی

برای استفاده از حالت ProcessGroup‌، باید گزینه Start By Server را روی Yes قرار دهیم. این گزینه را می‌توان از مسیر WebAdmin Console > Configuration > External App > your_external_application پیدا و سپس مقدار Start By Server را ازطریق CGI Daemon یا Daemon Async، روی Yes تنظیم کرد.

همچنین، فراموش نکنید که در محیط LiteSpeed Web Server این امکان برایتان فراهم است که حالت ProcessGroup را با تنظیم‌کردن فاکتور Instances روی عدد ۱ و LSAPI_CHILDREN روی عددی بیشتر از ۱۰ فعال کنید.

نکته دیگر اینکه اگر از محیط کنترل پنل استفاده می‌کنید، خواهید توانست که حالت ProcessGroup را با تنظیم‌کردن فاکتور LSPHP_ProcessGroup روی Directive در فایل httpd.config فعال کنید. این موضوع را نیز مدنظر قرار دهید که اگر این کار را در سطح Server انجام دهید، تغییرات روی تمامی هاست‌های مجازی که از سرور اصلی انشعاب گرفته شده‌اند، اِعمال خواهد شد و تمامی آن‌ها از ProcessGroup استفاده خواهند کرد. باوجوداین، درصورتی‌که این کار را فقط در سطح Virtual Host انجام دهید، طبیعتاً تغییرات فقط روی همان هاست مجازی اِعمال خواهد شد.

درادامه، نمونه پیکربندی برای محیط کنترل پنل نشان داده شده است:

<IfModule LiteSpeed>
LSPHP_ProcessGroup on
LSPHP_Workers 15
</IfModule>

بهبود عملکرد وردپرس با استفاده از Workers

۱. تعداد Workerهای بهینه برای هر وب‌سایت به عوامل مختلفی بستگی دارد که مهم‌ترین آن‌ها تعداد کاربران فعال لحظه‌ای وب‌سایت است.

۲. پیدا‌کردن عدد مناسب برای تعداد Workerها ممکن است به اندکی آزمون‌و‌خطا نیاز داشته باشد. بااین‌حال، برای یافتن تعداد اولیه می‌توانید از جدولی استفاده کنید که برای همین منظور در قسمت‌های قبلی این مطلب ارائه شده است.

۳. استفاده از Workerهای اضافی از یک طرف می‌تواند هزینه بیشتری به شما تحمیل کند و از طرف دیگر، اگر از تعداد کمتر Worker استفاده کنید، عملکرد وب‌سایت شما کاهش می‌یابد و با خطای ۵۰۲ مواجه شوید.

۴. باید توجه کنید که تمام تلاش شما باید به یافتن تعداد بهینه Workerها معطوف باشد تا هم عملکرد وب‌سایت خود را در بهترین سطح ممکن نگه دارید و هم از ایجاد هزینه اضافه برای سرور وب‌سایت خود جلوگیری کنید.

ابزار مانیتورینگ وب سرور آپاچی

برای بررسی  بار وب سرور و Requestهای دریافت‌شده، می‌توانید از ماژول mod_status استفاده کنید. درادامه، قصد داریم نحوه انجام این کار را آموزش دهیم.

پس از استفاده از ماژول mod_status، با صفحه ساده HTML مواجه خواهید شد که حاوی اطلاعات مهمی درباره آمار وب سرور است. این اطلاعات عبارت‌اند از:

• تعداد کل Requestهای دریافتی
• تعداد کل بایت‌ها و تعداد کل سرور
• میزان استفاده وب سرور از CPU
• بار سرور
• مدت‌زمان فعال‌بودن (آپتایم) سرور
• میزان کل ترافیک
• تعداد Workerهای غیرفعال
• PID با مشتریان مرتبط

۱. نحوه فعال‌کردن ماژول mod_status در وب سرور آپاچی

ماژول mod_status به‌طورپیش‌فرض با نصب Apache فعال می‌شود؛ اما اگر همچنان این ماژول برای شما غیرفعال است، با استفاده از دستور زیر مطمئن شوید که آن را در فایل پیکربندی آپاچی فعال کرده‌اید:

[root@tecmint ~]# vi /etc/httpd/conf/httpd.conf

بعد از استفاده از این دستور، عبارت mod_status را در نتیجه نمایش‌داده‌شده جست‌وجو کنید. همچنین، نتایج را می‌توانید به پایین اسکرول کنید تا خطی را بیابید که این عبارت در آن درج شده است:

اگر در ابتدای این خط مانند آنچه در خط بالا نشان داده شده است، کاراکتر # را مشاهده کردید، بدین‌معنی است که ماژول mod_status غیرفعال است. برای فعال‌کردن آن، کافی است کاراکتر # را حذف کنید تا به‌صورت زیر درآید:

۲. پیکربندی ماژول mod_status

بعد از فعال‌کردن ماژول mod_status‌، براساس نیاز خود باید پیکربندی آن را نیز انجام دهید. برای این منظور، این بار کلمه Location را جست‌وجو کنید تا به بخش زیر برسید:

# Allow server status reports generated by mod_status,

# with the URL of http://servername/server-status

# Change the ".example.com" to match your domain to enable.

#

#<Location /server-status>

#    SetHandler server-status

#    Order deny,allow

#    Deny from all

#    Allow from .example.com

#</Location>

در بخش بالایی این قسمت، براساس نیازتان می‌توانید خطوط مربوط به SetHandler و Location Directive و محدودیت‌های دایرکتوری را بردارید. به‌طور‌کلی، برای انجام تنظیمات مدنظر خود در این قسمت می‌توانید از Order Allow و Deny و Allowed for All استفاده کنید:

<Location /server-status>

   SetHandler server-status

   Order allow,deny

   Deny from all

   Allow from all 

</Location>

نکته: پیکربندی بالا درواقع نحوه پیکربندی برای وب‌سایت پیش‌فرض آپاچی (تک‌وب‌سایت) است؛ بنابراین اگر یک یا چند هاست مجازی نیز ایجاد کرده‌اید، پیکربندی بالا کار نخواهد کرد و اساساً برای هر هاست مجازی و هر دامنه پیکربندی‌شده در آپاچی، باید پیکربندی یکسانی تعریف کنید. به‌عنوان نمونه، پیکربندی هاست مجازی برای mod_status به‌صورت زیر خواهد بود:

<VirtualHost *:80>

    ServerAdmin [email protected]

    DocumentRoot /var/www/html/example.com

    ServerName example.com

    ErrorLog logs/example.com-error_log

    CustomLog logs/example.com-access_log common

<Location /server-status>

   SetHandler server-status

   Order allow,deny

   Deny from all

   Allow from example.com 

</Location>

</VirtualHost>

۳. فعال‌کردن تنظیمات ExtendedStatus

تنظیمات ExtendedStatus اطلاعات بیشتری به صفحه آمار اضافه می‌کند. به‌عنوان مثال، درصورتی‌که بخواهید آمار استفاده از CPU را نیز مشاهده کنید، باید این تنظیمات را نیز فعال کنید. برای انجام این کار، فایل httpd.config را با استفاده از ویرایشگر متن باز  و کلمه Extended را در آن جست‌وجو کنید. سپس، این خط را از حالت کامنت خارج و ExtendedStatus را روی On تنظیم کنید. درادامه، نحوه انجام این کار نیز آورده شده است:

# ExtendedStatus controls whether Apache will generate "full" status

# information (ExtendedStatus On) or just basic information (ExtendedStatus

# Off) when the "server-status" handler is called. The default is Off.

#

ExtendedStatus On

۴. راه‌اندازی مجدد وب سرور آپاچی

مطمئن شوید که صفحه server-status آپاچی را به‌درستی پیکربندی و فعال کرده‌اید. برای مشاهده خطاهای پیکربندی، می‌توانید از دستور زیر استفاده کنید:

[root@tecmint ~]# httpd -t
Syntax OK

درصورتی‌که عبارت Syntax OK برای شما به‌نمایش درآمد، یعنی خطایی در پیکربندی وجود ندارد و حالا می‌توانید سرویس httpd خود را برای اِعمال تغییرات ری‌استارت کنید:

[root@tecmint ~]# service httpd restart

OR

[root@tecmint ~]# systemctl restart httpd

Stopping httpd:                                          [  OK  ]

Starting httpd:                                          [  OK  ]

۵. دسترسی به صفحه mod_status

صفحه mod_status ازطریق آدرس yourdomain.com/server-status دردسترس است:

http://serveripaddress/server-status
OR
http://serev-hostname/server-status

 بعد از اینکه این آدرس را در مرورگر خود وارد کردید، صفحه‌ای مشابه با تصویر زیر برای شما به نمایش درخواهد آمد:

همان‌طورکه ملاحظه می‌کنید، تمامی اطلاعات موردنیاز شما در این صفحه گزارش داده شده است.

جمع‌بندی

بهینه‌ سازی تنظیمات PHP-FPM به‌منظور استفاده بهینه از منابع سرور اهمیت دارد. FastCGI پروتکلی باینری است که از آن برای ارتباط اپلیکیشن‌های داینامیک با وب سرور استفاده می‌شود. برای پیاده‌سازی این پروتکل، روش‌های متفاوتی وجود دارد که یکی از به‌روزترین و کارآمدترین آن‌ها PHP-FPM است و به‌خصوص در وب‌سایت‌ها و اپلیکیشن‌های با ترافیک بسیار زیاد استفاده می‌شود. ناگفته نماند که برای استفاده بهتر و مؤثرتر از این روش، باید تنظیماتی را روی فایل PHP خود انجام دهید. در این مقاله از آموزش برنامه‌نویسی بلاگ پارس پک، نحوه اِعمال این تنظیمات را به‌صورت کامل توضیح دادیم.

استفاده بهینه از منابع سرور چقدر برای شما اهمیت دارد؟‌ صرفه‌جویی در هزینه‌ای که برای سرور خود می‌کنید، برایتان مهم است؟ این مطلب را بخوانید تا با بهینه‌‌کردن تنظیمات وب سرور خود هم از منابع سرور به بهترین شکل استفاده کنید و هم هزینه کمتری برای آن بپردازید!

سؤالات متداول

۱. FastCGI چیست؟

FastCGI پروتکلی است که براساس آن، اپلیکیشن‌ها و وب‌سایت‌های دارای محتوای پویا با وب سرور ارتباط برقرار می‌کنند.

۲. PHP-FPM مخفف چیست؟

FPM مخفف عبارت FastCGI Process Manager است.

۳. چطور می‌توان PHP-FPM را بهینه‌سازی کرد؟

برای این منظور، باید تغییراتی در برخی از متغیرهای فایل php.ini خود اِعمال کنید.