بهبود عملکرد سایت و پنل ادمین وردپرس/ووکامرس روی LiteSpeed با کمک Redis

اگر روی سرور LiteSpeed و MariaDB، هم سایت کند شده و هم پنل ادمین ووکامرس سنگین است، معمولا مشکل فقط از CPU نیست. در بسیاری از فروشگاه‌های وردپرسی، گلوگاه اصلی ترکیبی از این عوامل است:

• فشار زیاد روی دیسک و I/O
• درخواست‌های پرتکرار admin-ajax.php
• درخواست‌های مداوم REST API در پنل ادمین ووکامرس
• کوئری‌های تکراری MariaDB
• باز بودن صفحات سنگین مانند Orders، Products و Analytics
• نبود Object Cache موثر مانند Redis
• تعداد بسیار زیاد فایل‌های موقت در /tmp
• کمبود swap
• قفل شدن پردازه‌ها در حالت انتظار I/O

در چنین شرایطی، فقط افزایش RAM یا CPU معمولا مشکل را به‌طور کامل حل نمی‌کند. باید هم‌زمان لایه‌های مختلف سیستم شامل وردپرس، ووکامرس، دیتابیس، کش، فایل‌سیستم و تنظیمات سیستم‌عامل بهینه شوند.

1) ابتدا نوع کندی را مشخص کنید

قبل از هر اقدامی باید مشخص شود کندی در کدام بخش بیشتر است:

• کندی فرانت‌اند سایت
• کندی پنل مدیریت
• کندی کل سرور
• قفل شدن مقطعی پردازه‌ها و بالا رفتن I/O Wait

اگر فشار بیشتر در wp-admin و admin-ajax.php دیده می‌شود، مشکل معمولا از این بخش‌هاست:

• Heartbeat API
• WooCommerce Admin
• wc-analytics
• wc-admin options
• افزونه‌های جانبی مثل پیامک، گزارش‌گیری، ACF، فیلترها و ابزارهای مدیریتی

اگر کل سیستم کند می‌شود و در خروجی top یا htop پردازه‌های زیادی در وضعیت D دیده می‌شوند، به احتمال زیاد مشکل فقط از وردپرس نیست و باید دیسک، فایل‌سیستم، /tmp، swap و فشار I/O هم بررسی شوند.

2) چرا admin-ajax.php زیاد دیده می‌شود؟

فایل admin-ajax.php به خودی خود مشکل نیست. این فقط یک endpoint مرکزی است که وردپرس و افزونه‌ها برای اجرای درخواست‌های پس‌زمینه از آن استفاده می‌کنند.

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

• Heartbeat در ادمین بیش از حد فعال است
• ووکامرس در صفحات سفارش و محصول Ajax زیادی تولید می‌کند
• بخش Analytics ووکامرس درخواست‌های متعدد REST می‌فرستد
• یک افزونه خاص مرتب polling انجام می‌دهد
• چند کاربر به‌صورت هم‌زمان در صفحات سنگین پنل فعال هستند

پس دیدن تعداد زیاد درخواست‌های admin-ajax.php به معنی حمله نیست؛ گاهی فقط نتیجه فعالیت عادی ولی پرهزینه در پنل مدیریت است.

3) نشانه‌های فشار از سمت پنل ادمین ووکامرس

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

• POST /wp-admin/admin-ajax.php
• GET /wp-json/wp/v2/users/me
• GET /wp-json/wc-analytics/…
• GET /wp-json/wc-admin/options…

و Referrerهایی مثل:

• /wp-admin/edit.php?post_type=shop_order
• /wp-admin/edit.php?post_type=product
• /wp-admin/admin.php?page=wc-admin…

این الگو نشان می‌دهد که فشار اصلی از Orders، Products، Analytics و pollingهای پنل ووکامرس می‌آید.

4) Heartbeat را محدود کنید

وردپرس برای autosave، قفل ویرایش، و هماهنگی برخی عملیات مدیریتی از Heartbeat استفاده می‌کند. خاموش کردن کامل آن توصیه نمی‌شود، اما کم کردن فرکانس آن معمولا بسیار مفید است.

add_filter('heartbeat_settings', function($settings) {
    $settings['interval'] = 60;
    return $settings;
});

اگر بخواهید فقط در پنل مدیریت اعمال شود:

add_action('admin_init', function () {
    add_filter('heartbeat_settings', function($settings) {
        $settings['interval'] = 60;
        return $settings;
    });
});

این کار باعث کاهش درخواست‌های پس‌زمینه و سبک‌تر شدن فشار روی PHP و MariaDB می‌شود.

5) WooCommerce Admin و Analytics را سبک کنید

نسخه‌های جدید ووکامرس در پنل مدیریت، مخصوصا در بخش‌های Analytics، Admin Notes و Options polling، درخواست‌های زیادی ایجاد می‌کنند. اگر استفاده ضروری از این قابلیت‌ها ندارید، بهتر است آن‌ها را محدود یا غیرفعال کنید.

مواردی که باید بررسی شوند:

• WooCommerce Analytics
• Admin Notes
• Marketplace Suggestions
• Usage Tracking
• پیشنهادها و ارتباطات خارجی
• Dashboard widgetهای غیرضروری

در بعضی پروژه‌ها حتی غیرفعال کردن WooCommerce Admin هم نتیجه خوبی داده است:

add_filter('woocommerce_admin_disabled', '__return_true');

این مورد باید با احتیاط و تست انجام شود، چون ممکن است بعضی قابلیت‌های مدیریتی را غیرفعال کند.

6) نقش Redis در بهبود عملکرد

یکی از موثرترین راهکارها برای این سناریو، استفاده از Redis به عنوان Object Cache است.

وردپرس و ووکامرس مدام این داده‌ها را از دیتابیس می‌خوانند:

• options
• transients
• نتایج کوئری‌های تکراری
• داده‌های مربوط به wc-admin
• داده‌های مربوط به wc-analytics
• objectهای تکراری وردپرس
• بخشی از session-like data

بدون Redis، این داده‌ها بارها از MariaDB و در نهایت از دیسک خوانده می‌شوند. اگر I/O دیسک از قبل تحت فشار باشد، همین خواندن‌های تکراری باعث کندی جدی در سایت و ادمین می‌شود.

با Redis:

• queryهای تکراری کمتر به MariaDB می‌رسند
• فشار روی دیتابیس کم می‌شود
• I/O دیسک کاهش می‌یابد
• پاسخ پنل ادمین سریع‌تر می‌شود
• صفحات Orders و Products روان‌تر باز می‌شوند

7) Redis جای LiteSpeed Cache را نمی‌گیرد

این نکته مهم است که Redis و LiteSpeed Cache دو نقش متفاوت دارند:

• LiteSpeed Cache: برای Page Cache
• Redis: برای Object Cache

در صفحات عمومی سایت، LiteSpeed بسیار موثر است. اما در پنل ادمین که معمولا page cache وجود ندارد، Redis بسیار مهم‌تر می‌شود. بهترین حالت برای فروشگاه‌های ووکامرسی این است که هر دو به‌صورت درست در کنار هم استفاده شوند.

8) تعداد زیاد فایل در /tmp چگونه باعث I/O Wait می‌شود؟

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

اگر تعداد زیادی فایل، حتی فایل‌های کوچک، در /tmp یا دایرکتوری‌های موقت مشابه وجود داشته باشد و یک پردازه مدام سعی کند روی آن‌ها عملیات انجام دهد، مثلا:

• stat
• grep
• find
• ls
• اسکن توسط آنتی‌ویروس
• اسکن توسط اسکریپت‌های امنیتی
• جستجوی الگو در فایل‌ها
• پاکسازی یا بررسی فایل‌های session

آن‌وقت سیستم برای هر عملیات مجبور می‌شود:

• ساختار دایرکتوری را بخواند
• متادیتای فایل‌ها را واکشی کند
• inodeها را بررسی کند
• روی دیسک seekهای متعدد انجام دهد

اگر تعداد فایل‌ها زیاد باشد، همین عملیات ظاهرا ساده می‌توانند I/O شدیدی تولید کنند.

نتیجه چیست؟

• iowait بالا می‌رود
• پردازه‌ها کند می‌شوند
• PHP requestها دیر پاسخ می‌دهند
• MariaDB هم به دلیل کندی دیسک عقب می‌افتد
• کل سرور حس «قفل شدن» پیدا می‌کند

این وضعیت مخصوصا روی سرورهایی که:

• sessionها در /tmp انباشته شده‌اند
• افزونه یا اسکریپتی فایل‌های موقت زیاد تولید می‌کند
• آنتی‌ویروس یا malware scanner فعال است
• لاگ‌ها و temp fileها cleanup مناسبی ندارند

بسیار رایج است.

9) قفل شدن پردازه‌ها در وضعیت D

وقتی در top یا ps می‌بینید پردازه‌ها در وضعیت D هستند، یعنی:

پردازه در Uninterruptible Sleep قرار دارد و منتظر تکمیل I/O است.

این پردازه‌ها معمولا:

• CPU زیادی مصرف نمی‌کنند
• ولی سیستم را سنگین و کند نشان می‌دهند
• قابل kill شدن سریع نیستند
• تا وقتی I/O پاسخ ندهد، جلو نمی‌روند

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

• PHP
• LiteSpeed workers
• MariaDB threads
• grep
• find
• backup script
• malware scanner
• processهای امنیتی
• ابزارهای مانیتورینگ

اگر هم‌زمان تعداد زیادی پردازه در D باشند، یعنی گلوگاه اصلی، دیسک یا فایل‌سیستم است؛ نه CPU.

10) کمبود Swap چگونه مشکل را بدتر می‌کند؟

کمبود swap یا نبود swap کافی، در سرورهای وردپرس/ووکامرس خیلی مهم‌تر از چیزی است که معمولا تصور می‌شود.

وقتی RAM تحت فشار قرار می‌گیرد و swap کافی وجود ندارد:

• کرنل فضای مانور کمتری برای مدیریت حافظه دارد
• page cache سریع‌تر تخلیه می‌شود
• پردازه‌ها بیشتر وارد رقابت برای RAM می‌شوند
• فشار روی I/O بیشتر می‌شود
• سرویس‌ها ناپایدارتر می‌شوند
• گاهی OOM یا کندی‌های انفجاری رخ می‌دهد

ارتباط Swap با I/O Wait

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

یعنی اگر:

• Redis
• MariaDB
• LiteSpeed/PHP
• و پردازه‌های جانبی

هم‌زمان به حافظه نیاز داشته باشند، وجود swap متعادل باعث می‌شود کرنل تصمیم‌های بهتری بگیرد و سیستم کمتر دچار spike و lockup شود.

البته swap زیاد، جای RAM را نمی‌گیرد؛ اما نبود آن در سرورهای شلوغ می‌تواند بحران را شدیدتر کند.

11) /tmp، Swap و Redis چه ارتباطی با هم دارند؟

این سه موضوع در ظاهر جدا هستند، اما در عمل به‌شدت به هم وابسته‌اند:

Redis

باعث می‌شود تعداد زیادی از خواندن‌های تکراری از دیتابیس حذف شوند.

/tmp شلوغ

باعث می‌شود هر پردازه‌ای که دنبال فایل بگردد یا فایل‌ها را بررسی کند، I/O زیادی مصرف کند.

Swap ناکافی

باعث می‌شود سیستم در مدیریت حافظه ضعیف‌تر عمل کند و با کوچک‌ترین فشار، افت شدید کارایی رخ دهد.

پس اگر فقط Redis فعال شود اما:

• /tmp شلوغ باشد
• پردازه‌ای مدام روی آن stat یا grep بزند
• swap کافی هم وجود نداشته باشد

باز هم سرور ممکن است دچار I/O Wait و قفل شدن ظاهری شود.

12) MariaDB را هم منطقی تنظیم کنید

Redis فشار را از دیتابیس کم می‌کند، ولی MariaDB همچنان باید درست تنظیم شود. برای سرورهایی با منابع متوسط یا بالا، معمولا این موارد مهم‌اند:

• max_connections بی‌دلیل بالا نباشد
• wait_timeout پایین‌تر تنظیم شود
• innodb_buffer_pool_size متناسب با RAM باشد
• innodb_thread_concurrency = 0
• bufferهای per-connection بیش از حد بزرگ نباشند

اگر MariaDB حافظه را بی‌رویه مصرف کند، فشار RAM بیشتر می‌شود و اثر کمبود swap شدیدتر خواهد شد.

13) صفحات سنگین پنل را سبک‌تر کنید

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

• لیست سفارش‌ها
• لیست محصولات
• صفحه ویرایش محصول
• Woo Analytics

برای سبک‌تر کردن آن‌ها:

• تعداد آیتم در هر صفحه را کم کنید
• ستون‌های اضافی را حذف کنید
• تب‌های غیرضروری را ببندید
• Analytics را بی‌دلیل باز نگذارید
• چند ادمین هم‌زمان روی صفحات سنگین کار نکنند
• افزونه‌هایی که ستون یا فیلتر اضافه می‌کنند بررسی شوند

14) افزونه‌های جانبی را Audit کنید

افزونه‌های زیر معمولا عامل پنهان مصرف منابع هستند:

• افزونه‌های پیامک ووکامرس
• افزونه‌های گزارش‌گیری
• ابزارهای مدیریت انبار
• ACF روی post typeهای سنگین
• افزونه‌های امنیتی
• بدافزار‌اسکنرها
• ابزارهای مانیتورینگ فایل
• افزونه‌های sync یا import/export

بعضی از این افزونه‌ها علاوه بر Ajax و query، فایل‌های موقت زیادی هم در /tmp تولید می‌کنند یا روی فایل‌سیستم اسکن انجام می‌دهند.

15) علائم مهمی که باید هم‌زمان بررسی شوند

اگر این نشانه‌ها را با هم می‌بینید، مشکل شما تقریبا قطعا چندلایه است:

• admin-ajax.php زیاد
• wc-analytics زیاد
• iowait بالا
• پردازه‌های D
• شلوغی /tmp
• کمبود swap
• کندی MariaDB
• کندی پنل ادمین و فرانت به‌صورت هم‌زمان

در این حالت نباید فقط روی وردپرس تمرکز کرد؛ باید هم وردپرس و هم سیستم‌عامل و هم storage را با هم دید.

16) برنامه عملی پیشنهادی

برای چنین سناریویی، ترتیب اجرای بهینه‌سازی بهتر است این باشد:

مرحله اول: کاهش فشار وردپرس/ووکامرس

• Heartbeat را محدود کنید
• WooCommerce Admin و Analytics غیرضروری را کم کنید
• افزونه‌های سنگین را بررسی کنید
• تعداد requestهای پنل را کاهش دهید

مرحله دوم: فعال‌سازی کش موثر

• LiteSpeed Cache برای page cache
• Redis برای object cache

مرحله سوم: بهینه‌سازی دیتابیس

• تنظیم منطقی MariaDB
• کاهش connectionهای بلااستفاده
• بهبود buffer pool

مرحله چهارم: بررسی سیستم‌عامل

• وضعیت /tmp را بررسی کنید
• فایل‌های موقت انباشته را پاکسازی و lifecycle آن‌ها را مدیریت کنید
• پردازه‌هایی که مداوم stat، grep یا scan انجام می‌دهند شناسایی کنید
• وضعیت swap را بررسی و در صورت نیاز اصلاح کنید
• پردازه‌های D و منبع I/O آن‌ها را پیدا کنید

17) جمع‌بندی

کندی سایت و پنل ادمین در وردپرس/ووکامرس معمولا فقط از یک عامل ایجاد نمی‌شود. در بسیاری از سرورها، بحران واقعی از ترکیب این عوامل شکل می‌گیرد:

• فشار پنل ووکامرس
• درخواست‌های زیاد admin-ajax.php
• WooCommerce Analytics
• کوئری‌های تکراری MariaDB
• نبود Redis
• شلوغی /tmp
• اسکن یا جستجوی مداوم روی فایل‌های موقت
• قفل شدن پردازه‌ها در وضعیت D
• کمبود swap

در این میان، Redis یکی از بهترین و سریع‌ترین ارتقاها برای کاهش بار تکراری روی دیتابیس است، اما اگر /tmp از فایل‌های موقت پر شده باشد یا پردازه‌ای مدام آن‌ها را scan کند، و در کنار آن swap کافی هم وجود نداشته باشد، باز هم I/O Wait بالا می‌ماند.

بنابراین راه‌حل درست، فقط «نصب Redis» نیست؛ بلکه یک بهینه‌سازی چندلایه است:

• سبک‌سازی admin
• کاهش polling و Ajax
• فعال‌سازی Redis
• تنظیم درست LiteSpeed و MariaDB
• مدیریت فایل‌های موقت
• تامین swap مناسب
• شناسایی پردازه‌های گیرکرده در I/O