PHP Worker چیست و چه تفاوتی با Entry Process در هاست دارد؟
PHP Worker، LSPHP Process و Entry Process را از هم تفکیک کنید و ببینید همزمانی درخواستهای پویا، Cache و محدودیت منابع چگونه روی وردپرس و ووکامرس اثر میگذارند.
پاسخ کوتاه: PHP Worker چیست؟
PHP Worker اصطلاحی برای فرایند یا ظرفیت همزمان اجرای درخواستهای PHP است. در LiteSpeed، تنظیماتی مانند LSPHP Workers و Max Connections روی تعداد فرایندهای LSPHP و همزمانی اثر میگذارند. Entry Process اما مفهوم دیگری است و در CloudLinux تعداد درخواستهای همزمانی را که وارد محیط LVE میشوند محدود میکند.
PHP Worker و Entry Process را یک عدد فرض نکنید؛ تعریف و محل اعمال آنها متفاوت است و معماری میزبان تعیین میکند چه نسبتی میانشان وجود داشته باشد.
یک درخواست وردپرس چگونه به PHP میرسد؟
در Page Cache Hit ممکن است وبسرور پاسخ آماده را بدون اجرای WordPress/PHP برگرداند. در Cache Miss یا مسیرهای پویا، درخواست باید وارد PHP شود، WordPress را اجرا کند، Queryهای لازم را انجام دهد و پاسخ بسازد. در این بخش ظرفیت اجرای همزمان PHP اهمیت پیدا میکند.
PHP Worker در LiteSpeed چگونه تعریف میشود؟
مستندات LiteSpeed توضیح میدهند که LSPHP_Workers حداکثر تعداد worker/child process در سطح حساب هاست اشتراکی را کنترل میکند و Max Connections نیز روی اتصال همزمان LSPHP اثر دارد. جزئیات دقیق به ProcessGroup، suEXEC و تنظیمات میزبان وابسته است.
Entry Process در CloudLinux چیست؟
CloudLinux، EP را تعداد Entry Processهای همزمان تعریف میکند؛ یعنی درخواستهایی که وارد LVE کاربر میشوند. این عدد با تعداد بازدیدکننده آنلاین برابر نیست. یک کاربر میتواند چند Request بسازد و بسیاری از Assetهای Static نیز بسته به معماری مسیر متفاوتی داشته باشند.
تفاوت مفهومی PHP Worker و EP
| مفهوم | لایه | چه چیزی را محدود میکند؟ |
|---|---|---|
| PHP Worker/LSPHP Worker | اجرای PHP | ظرفیت Process/Worker PHP |
| Entry Process | LVE/ورودی حساب | درخواستهای همزمان ورودی به محیط کاربر |
| NPROC | Process Limit | تعداد Processهای داخل LVE |
| CPU | پردازنده | زمان پردازشی قابل مصرف |
چرا تعداد Worker بیشتر همیشه بهتر نیست؟
هر Worker برای اجرای PHP به CPU و حافظه نیاز دارد. اگر تعداد فرایندها بالا برود ولی CPU و RAM کافی نباشد، فقط صف کار را به فشار بیشتر روی سرور تبدیل میکنید. LiteSpeed نیز در راهنمای Shared Hosting تأکید میکند که افزایش Max Connections الزاماً عملکرد را بهتر نمیکند.
Cache چگونه نیاز به Worker را کاهش میدهد؟
Page Cache میتواند بسیاری از درخواستهای عمومی را بدون اجرای PHP پاسخ دهد. Object Cache نیز Queryهای تکراری را کاهش میدهد اما خود PHP همچنان اجرا میشود. به همین دلیل در سایت محتوایی Cacheable، Worker کمتر ممکن است بار بیشتری را نسبت به فروشگاه کاملاً پویا تحمل کند.
مقاله LiteSpeed و Redis در وردپرس این دو نوع Cache را جدا توضیح میدهد.
WooCommerce چرا به همزمانی حساستر است؟
Cart، Checkout، My Account و بسیاری از APIها نباید مانند صفحه عمومی Full Page Cache شوند. بنابراین سهم درخواستهایی که به PHP و دیتابیس میرسند بیشتر است. در کمپین، چند Checkout همزمان میتواند Worker، CPU و DB را همزمان درگیر کند.
نشانههای کمبود ظرفیت اجرای PHP
- افزایش TTFB فقط در صفحات پویا
- کندی wp-admin هنگام افزایش ترافیک
- صف شدن Requestهای PHP
- خطاهای 503/508 بسته به پلتفرم
- رسیدن مکرر به Resource Fault
- کندی Checkout در حالی که صفحات Cache Hit سریعاند
برای تشخیص قطعی باید Log و Usage همان بازه زمانی بررسی شود.
چطور Worker مناسب را تخمین بزنیم؟
عدد ثابت «هر X بازدید یک Worker» قابل اتکا نیست. سه عامل مهمترند: مدت اجرای هر Request پویا، تعداد Requestهای پویا در ثانیه و میزان Cache Hit. هرچه PHP زودتر Request را تمام کند، Worker سریعتر برای کار بعدی آزاد میشود.
بهینهسازی قبل از افزایش Worker
- Queryهای کند و Pluginهای سنگین را پیدا کنید.
- Page Cache را برای صفحات مجاز فعال کنید.
- Persistent Object Cache را در صورت تناسب معماری بررسی کنید.
- Cron و Action Scheduler را مدیریت کنید.
- External APIهای کند را از Request اصلی جدا کنید.
- OPcache و نسخه PHP مناسب را بررسی کنید.
چه سؤالهایی از میزبان بپرسیم؟
- PHP Handler چیست؟
- حداکثر Worker یا Max Connection حساب چقدر است؟
- EP و NPROC جداگانه محدود میشوند؟
- در صورت رسیدن به Limit چه خطایی ثبت میشود؟
- Usage و Fault در پنل قابل مشاهده است؟
- Worker با ارتقای پلن افزایش مییابد؟
- برای WooCommerce چه تنظیمی پیشنهاد میشود؟
یک مدل ساده برای فهم صف PHP
فرض کنید هر Request پویا بهطور متوسط ۵۰۰ میلیثانیه PHP را درگیر میکند. یک Worker در شرایط ایدهآل میتواند تقریباً دو Request در ثانیه تمام کند. اگر ناگهان ۱۰ Request پویا در ثانیه وارد شوند، Workerهای محدود باعث Queue میشوند. اما اگر همان Request با بهینهسازی به ۱۰۰ میلیثانیه برسد، ظرفیت همان Worker چند برابر میشود. این مثال نشان میدهد کاهش زمان اجرا اغلب از افزودن Worker ارزشمندتر است.
Slow API چگونه Worker را قفل میکند؟
اگر PHP منتظر پاسخ یک API بیرونی، Payment Gateway یا سرویس ارسال پیامک بماند، Worker تا پایان Timeout آزاد نمیشود. حتی اگر CPU مصرف زیادی نداشته باشد، ظرفیت همزمانی اشغال شده است. Timeout کوتاه، Queue غیرهمزمان و Circuit Breaker در معماری اپلیکیشن میتوانند این ریسک را کم کنند.
wp-cron و Jobهای پسزمینه
Jobهای سنگین Import، Feed، Backup، Image Processing و Action Scheduler میتوانند همزمان با ترافیک کاربر Worker و CPU را مصرف کنند. زمانبندی Job در ساعات کمترافیک، Batch کوچکتر و Cron واقعی میتواند از رقابت با Checkout جلوگیری کند.
OPcache کجای این تصویر است؟
OPcache bytecode کامپایلشده PHP را در حافظه نگه میدارد تا فایل PHP برای هر Request دوباره Parse و Compile نشود. این قابلیت تعداد Worker را مستقیماً افزایش نمیدهد، اما میتواند زمان CPU هر Request را کم کند و Worker را زودتر آزاد کند. WordPress Site Health نیز availability Opcode Cache را بهعنوان تست عملکرد میشناسد.
چرا Memory Limit با Worker Count گره میخورد؟
memory_limit سقف حافظه یک اجرای PHP است، نه RAM تضمینشده حساب. اگر چند Worker همزمان هرکدام حافظه زیادی مصرف کنند، مجموع Memory Pressure بالا میرود. بنابراین افزایش Worker بدون بررسی Peak Memory میتواند به OOM یا Fault منجر شود.
برای WooCommerce چه چیزی را مانیتور کنیم؟
- Latency Checkout و Add to Cart
- تعداد Requestهای پویا در ثانیه
- زمان PHP و Queryهای دیتابیس
- Queue و Failure در Action Scheduler
- CPU/Memory Fault در کمپین
- Cache Hit Ratio صفحات عمومی
این دادهها کمک میکنند بفهمید مشکل واقعاً Worker است یا یک Query/Plugin کند.
تفاوت Worker با Thread یا CPU Core
Worker PHP معادل CPU Core نیست و الزاماً Thread هم نیست. یک Process PHP میتواند روی Coreهای موجود زمان پردازنده بگیرد و سیستمعامل بین Processها زمانبندی انجام میدهد. بنابراین عبارت «۱۰ Worker» به معنی «۱۰ Core» نیست. منابع CPU تعیین میکنند این Workerها در عمل چقدر سریع کار کنند.
چرا Front-end سریع ولی wp-admin کند است؟
Front-end عمومی ممکن است از Full Page Cache پاسخ داده شود و PHP را دور بزند؛ اما wp-admin تقریباً همیشه پویاست. اگر Worker، CPU یا دیتابیس محدود باشد، مدیر سایت کندی را در پیشخوان حس میکند در حالی که تست صفحه اصلی عالی است. برای ارزیابی هاست وردپرس هر دو مسیر را آزمایش کنید.
Load Test باید چه چیزی را شبیهسازی کند؟
تست هزار Request به یک صفحه Cache شده چیزی درباره ظرفیت Checkout نمیگوید. سناریوی تست باید نسبت Cache Hit/Miss، Login، Search، Add to Cart و API را شبیه رفتار واقعی کاربر کند. هدف پیدا کردن نقطه اشباع و نوع خطاست، نه تولید یک عدد Requests per Second بدون Context.
جمعبندی
PHP Worker ظرفیت اجرای همزمان PHP را توصیف میکند؛ Entry Process یک محدودیت ورودی در معماریهایی مانند CloudLinux است. این دو میتوانند روی هم اثر بگذارند اما مترادف نیستند. برای انتخاب هاست وردپرس، Worker را کنار CPU، RAM، EP، Cache و زمان اجرای Request بررسی کنید.