PHP-FPM مدیر پردازش‌های PHP است: درخواست‌های dynamic را از وب‌سرور می‌گیرد، آن‌ها را میان workerها توزیع می‌کند و چرخه عمر پردازش‌ها را کنترل می‌کند. اگر همه workerها مشغول باشند، درخواست تازه در صف می‌ماند؛ اگر تعداد آن‌ها بدون توجه به RAM زیاد شود، swap یا OOM می‌تواند کل سرویس را ناپایدار کند.
پاسخ کوتاه: PHP-FPM کد یا Query کند را سریع نمی‌کند، اما ظرفیت اجرای هم‌زمان و نحوه صف‌شدن درخواست‌ها را تعیین می‌کند. تنظیم درست از اندازه‌گیری مدت request، حافظه واقعی هر worker، ترافیک هم‌زمان و حاشیه امن سیستم شروع می‌شود؛ نه از کپی کردن مقدار pm.max_children یک سرور دیگر.
درخواست وردپرس از کجا عبور می‌کند؟
وب‌سرور فایل‌های static را مستقیماً می‌فرستد و درخواست PHP را معمولاً از FastCGI به pool مربوط تحویل می‌دهد. worker وردپرس را bootstrap می‌کند، به دیتابیس و سرویس‌های بیرونی دسترسی می‌زند و پاسخ را برمی‌گرداند. بنابراین TTFB می‌تواند شامل انتظار در صف FPM، اجرای PHP، Query دیتابیس و API خارجی باشد. مشاهده TTFB بالا به‌تنهایی محل مشکل را مشخص نمی‌کند.
Pool و Worker یعنی چه؟
هر pool مجموعه‌ای از تنظیمات، socket، user و پردازش‌های PHP دارد. جداسازی poolها می‌تواند مرز دسترسی و ظرفیت ایجاد کند، ولی تعداد کل workerهای همه poolها باید در بودجه RAM جا شود. یک سایت پرترافیک می‌تواند workerهای سایت دیگری را از منابع محروم کند؛ pool جدا فقط وقتی مفید است که محدودیت‌ها و مانیتورینگ نیز جدا باشند.
حالت‌های Process Manager
| حالت | رفتار کلی | کاربرد و ملاحظه |
|---|---|---|
static | تعداد ثابت worker | رفتار قابل‌پیش‌بینی؛ حافظه رزروشده بیشتر |
dynamic | افزایش و کاهش در محدوده تعیین‌شده | تعادل رایج برای بار متغیر؛ پارامترهای idle/start مهم‌اند |
ondemand | ساخت worker هنگام نیاز | حافظه idle کمتر؛ هزینه spawn و رفتار burst باید سنجیده شود |
هیچ حالت واحدی برای همه سرورها برتر نیست. الگوی ترافیک، latency شروع پردازش، حافظه و تعداد poolها تصمیم را تعیین می‌کند.
نشانه‌های کمبود Worker
- رشد request queue هم‌زمان با ترافیک
- ثبت پیام رسیدن به سقف children در log
- کند شدن درخواست‌های dynamic در حالی که فایل static سریع است
- بهبود موقت بعد از پایان job یا burst
- workerهای کاملاً مشغول با CPU هنوز آزاد، به‌خصوص هنگام انتظار I/O
اگر CPU اشباع، MySQL قفل یا API خارجی کند است، افزایش worker می‌تواند تعداد درخواست‌های منتظر آن bottleneck را بیشتر کند.
نشانه‌های Worker بیش از ظرفیت
- افت available memory و استفاده مداوم از swap
- رویداد OOM و بسته شدن PHP-FPM یا MySQL
- افزایش load و context switch بدون افزایش throughput
- latency شدید هنگام burst یا اجرای cron
- رقابت PHP با دیتابیس و cache برای RAM
برای تفکیک حافظه واقعی از cache سیستم، راهنمای مصرف RAM وردپرس را ببینید.
ظرفیت را چگونه برآورد کنیم؟
RSS چند worker را در سناریوهای واقعی—صفحه عمومی بدون cache، wp-admin، checkout و job سنگین—اندازه بگیرید. میانگین تنها کافی نیست؛ worker در import یا صفحه‌ساز ممکن است peak بالاتری داشته باشد. بودجه قابل تخصیص به PHP را بعد از رزرو RAM برای سیستم‌عامل، MySQL، Redis، وب‌سرور و spikeها تعیین کنید.
تقسیم بودجه PHP بر حافظه محافظه‌کارانه هر worker یک نقطه شروع می‌دهد، نه مقدار نهایی. سپس با load test معتبر، queue، error rate، p95 latency، swap و throughput را بسنجید. memory_limit سقف PHP هر request است و معادل RSS ثابت worker نیست.
چه چیزهایی را مانیتور کنیم؟
- تعداد active، idle و total process
- طول و بیشینه queue و accepted connections
- رسیدن به سقف children
- مدت request و slow request
- RSS پردازش‌ها و حافظه available سیستم
- restart، exit غیرعادی و OOM
- CPU، I/O و latency سرویس‌های وابسته
Status page باید فقط برای شبکه یا endpoint مدیریتی مجاز قابل دسترس باشد؛ انتشار آن روی اینترنت اطلاعات عملیاتی افشا می‌کند.
Slow Log چه کمکی می‌کند؟
FPM می‌تواند requestهای طولانی را پس از آستانه مشخص trace کند. این قابلیت برای پیدا کردن stack گیرکرده مفید است، اما log ممکن است مسیر فایل و جزئیات برنامه را آشکار و روی بار زیاد خروجی قابل‌توجه ایجاد کند. آن را محدود، با permission و retention مناسب و برای بازه تشخیصی استفاده کنید.
pm.max_requests برای چیست؟
بازیافت worker پس از تعداد مشخص درخواست می‌تواند اثر رشد حافظه کتابخانه یا extension را محدود کند، اما درمان memory leak یا کد معیوب نیست. مقدار بسیار پایین هزینه spawn و cold state را زیاد می‌کند؛ مقدار بسیار بالا ممکن است رشد پردازش را دیر مهار کند. روند RSS و نرخ recycle را پیش و پس از تغییر مقایسه کنید.
Timeoutها را با هم اشتباه نگیرید
Timeout مرورگر، proxy، وب‌سرور، FastCGI و PHP هرکدام لایه متفاوتی دارند. بالا بردن همه timeoutها job خراب را اصلاح نمی‌کند و worker را مدت بیشتری اشغال می‌کند. برای عملیات طولانی مانند export یا sync، queue/CLI و پردازش batch معمولاً از request تعاملی مناسب‌تر است. قبل از terminate کردن request، اثر آن بر transaction و عملیات پرداخت را بررسی کنید.
Page Cache چگونه معادله را تغییر می‌دهد؟
در cache hit واقعی ممکن است PHP-FPM اصلاً درگیر نشود. به همین دلیل benchmark صفحه عمومی cacheشده ظرفیت wp-admin یا checkout را نشان نمی‌دهد. سناریوهای cacheable و dynamic را جدا تست کنید و hit rate را ثبت کنید. افزایش worker برای ترافیکی که باید در لایه page cache پاسخ گیرد، احتمالاً راه‌حل اصلی نیست.
یک Runbook تنظیم کم‌ریسک
- نسخه config و راه rollback را ثبت کنید.
- بار واقعی، queue، RAM و latency را baseline کنید.
- endpoint یا job کند را جدا profile کنید.
- بودجه RAM همه سرویس‌ها و همه poolها را محاسبه کنید.
- فقط یک پارامتر را در staging یا بازه کم‌ریسک تغییر دهید.
- syntax پیکربندی را با ابزار همان نسخه بررسی و reload کنترل‌شده انجام دهید.
- پس از تغییر، throughput، tail latency، خطا، swap و OOM را بسنجید.
مسیر فایل و فرمان reload به توزیع، نسخه و container بستگی دارد؛ نمونه مربوط به سیستم دیگری را مستقیم اجرا نکنید.
اشتباه‌های رایج
- افزایش چندبرابری
pm.max_childrenبدون محاسبه RAM - افزایش هم‌زمان worker و
memory_limit - restart دوره‌ای به‌جای یافتن request کند
- یکی دانستن process timeout و مشکل Query
- تست فقط صفحه cacheشده
- عمومی کردن status یا slow log
- نادیده گرفتن workerهای CLI و cron
چه زمانی مسئله از PHP-FPM نیست؟
اگر queue صفر است اما یک worker CPU کامل مصرف می‌کند، کد را profile کنید. اگر بیشتر زمان در MySQL است، Slow Query را پیدا کنید. اگر DNS یا HTTP خارجی منتظر است، timeout و رفتار API را بررسی کنید. برای تحلیل لایه‌ای TTFB نیز راهنمای کاهش TTFB وردپرس مفید است.
چه زمانی کمک تخصصی لازم است؟
اگر pool مرتب به سقف می‌رسد، با افزایش worker سرور swap می‌کند یا checkout زیر بار timeout دارد، تغییر بیشتر روی production ریسک قطعی دارد. سرویس افزایش سرعت وردپرس می‌تواند queue، slow log، حافظه worker و bottleneck دیتابیس را با یک workload ثابت تحلیل کند.
پرسش‌های متداول
آیا تعداد worker بیشتر همیشه سایت را سریع‌تر می‌کند؟
خیر؛ پس از ظرفیت CPU، RAM یا وابستگی‌ها، worker بیشتر می‌تواند رقابت و swap را افزایش دهد.
چرا wp-admin کند است ولی صفحه اصلی سریع؟
صفحه اصلی احتمالاً cache می‌شود، اما مدیریت PHP و Queryهای dynamic را اجرا می‌کند.
آیا PHP-FPM برای Apache هم استفاده می‌شود؟
می‌تواند استفاده شود؛ معماری دقیق به handler و پیکربندی میزبان بستگی دارد.