فایل admin-ajax.php برای بسیاری از سایتهای وردپرسی، نقطهای است که “مشکل کندی” از آن شروع میشود؛ نه به این دلیل که ذاتاً بد است، بلکه چون در عمل، تعداد زیادی از افزونهها و حتی برخی قالبها، کارهای سنگین و پرتکرار را به این مسیر میسپارند. نتیجه میتواند چیزی شبیه این باشد:
افزایش ناگهانی مصرف CPU، کند شدن صفحات، افزایش TTFB، خطاهای 503 یا حتی از دسترس خارج شدن سایت در ساعات پرترافیک.
نکته مهم اینجاست که «کندی admin-ajax» معمولاً یک مشکل تکعلتی نیست؛
اغلب ترکیبی از تعداد زیاد درخواستها + هزینه پردازش بالا برای هر درخواست + کمبود منابع یا تنظیمات نامناسب است. به همین خاطر، این مقاله را طوری نوشتهام که هم برای کاربر عادی قابل اجرا باشد و هم برای مدیر سایت/توسعهدهنده، مسیر عیبیابی و حل مسئله کاملاً شفاف و قابل اندازهگیری باشد.
علت کندی admin-ajax.php در وردپرس
اگر میخواهید مشکل کندی را سریع و اصولی جمعبندی کنید (بدون آزمون و خطای زیاد)، میتوانید از خدمات پشتیبانی وردپرس استفاده کنید تا دقیقاً مشخص شود کدام افزونه/قالب/اکشن Ajax یا تنظیمات سرور عامل اصلی است.
همچنین اگر سایت شما نیاز به رسیدگی گستردهتر مثل بهینهسازی، پایش منابع، تنظیم کش، بررسی امنیت و رفع خطاهای تکرارشونده دارد،سرویس پشتیبانی سایت میتواند مسیر حل مشکل را مرحلهبهمرحله و حرفهای جلو ببرد.
همچنین اگر در لاگها الگوهای مشکوک میبینید، مصرف منابع بیدلیل بالا میرود، صفحات ناخواسته ساخته میشوند یا درخواستهای عجیب به سایت ارسال میشود، احتمال آلودگی وجود دارد و بهتر است موضوع را جدیتر دنبال کنید؛ در چنین شرایطی سرویس پاکسازی سایت ویروسی کمک میکند هم بدافزار حذف شود و هم مسیرهای نفوذ و تکرار حمله بسته شود.
admin-ajax.php چیست و دقیقاً چه کاری انجام میدهد؟
admin-ajax.php یکی از فایلهای هسته وردپرس است که برای پردازش درخواستهای Ajax استفاده میشود. Ajax (مخفف Asynchronous JavaScript and XML) یعنی مرورگر بدون اینکه صفحه را رفرش کند، یک درخواست به سرور میفرستد و پاسخ میگیرد؛ سپس همان پاسخ را در صفحه نمایش میدهد یا براساس آن، UI را بهروزرسانی میکند.
در وردپرس، بسیاری از اکشنهای Ajax از مسیر /wp-admin/admin-ajax.php عبور میکنند.
نکتهای که باید بدانید این است که بسیاری از درخواستهای Ajax در وردپرس، برخلاف تصور، “سبک و سریع” نیستند؛ چون در بسیاری موارد، وردپرس را تقریباً کامل بارگذاری میکنند: یعنی افزونهها، توابع، هوکها و حتی بخشی از قالب ممکن است درگیر شوند. به همین دلیل، اگر تعداد درخواستها زیاد باشد یا هر درخواست شامل کوئریهای سنگین دیتابیس باشد، admin-ajax به یک گلوگاه جدی تبدیل میشود.
نمونههای رایج استفاده از admin-ajax
- افزودن به علاقهمندی/مقایسه بدون رفرش (خصوصاً در فروشگاهها)
- فیلتر محصولات ووکامرس (برند، قیمت، ویژگیها)
- جستجوی زنده (Live Search) و پیشنهاد لحظهای
- ثبت رأی/امتیاز، لایک، کامنتهای Ajax
- آپدیت مینیکارت، شمارش موجودی یا وضعیتهای پویا
- پینگهای دورهای Heartbeat در پیشخوان
- گزارشگیریهای لحظهای برخی افزونهها (آمار، امنیت، مانیتورینگ)
واقعیت این است که admin-ajax بد نیست؛ استفاده نادرست یا بیشازحد از آن، سایت را کند میکند. برای حل مشکل، باید دقیقاً بفهمیم کدام “اکشن” Ajax بیشترین بار را ایجاد میکند، سپس تعداد و هزینه پردازش آن اکشن را کاهش دهیم.
چرا admin-ajax.php کند میشود؟ (علتهای واقعی و ریشهای)
وقتی میگوییم admin-ajax کند است، معمولاً منظورمان این نیست که خود فایل مشکل دارد؛ بلکه یعنی درخواستهایی که از طریق آن ارسال میشوند، یا زیاد هستند یا سنگین پردازش میشوند (یا هر دو). در ادامه، مهمترین علتها را دقیق، با توضیح عملی و نکتههای تشخیصی بررسی میکنیم.
1) افزونهها یا اکشنهای Ajax سنگین (بد طراحی شده یا تنظیمات نادرست)
بسیاری از افزونهها برای هر قابلیت کوچک، یک اکشن Ajax تعریف میکنند.
مشکل زمانی شروع میشود که آن اکشن:
- دیتابیس را چندین بار کوئری میزند
- خروجی را هر بار از صفر محاسبه میکند
- هیچ کشی ندارد
- روی صفحات پرترافیک فعال است.
در چنین شرایطی حتی اگر هر درخواست فقط 300 تا 800 میلیثانیه طول بکشد، با 50 یا 100 درخواست همزمان، سرور زیر فشار میرود و همه چیز کند میشود.
افزونههای آمار و بازدید داخلی، چت آنلاین، اعلانها، پاپآپها، برخی فرمسازها، فیلترهای ووکامرس و سیستمهای عضویت/نوتیفیکیشن از رایجترین عوامل این وضعیت هستند. همچنین بعضی افزونهها در حالت پیشفرض، Ajax را برای کاربران مهمان هم فعال میکنند؛ یعنی هر بازدیدکننده جدید، چندین درخواست اضافی به سرور تحمیل میکند.
2) Heartbeat API و فشار در پیشخوان (Backend)
وردپرس برای چند قابلیت حیاتی مثل Autosave، جلوگیری از تداخل ویرایش (Post Locking)، نمایش اعلانها، و برخی هماهنگیهای لحظهای در پیشخوان، از Heartbeat API استفاده میکند. این سیستم بهصورت دورهای، درخواستهایی به سرور میفرستد (اغلب از طریق admin-ajax). اگر چند کاربر همزمان در پیشخوان فعال باشند یا افزونهها Heartbeat را سنگینتر کرده باشند، تعداد درخواستها و هزینه پردازش بالا میرود.
مشکل Heartbeat معمولاً خودش را با کندی داخل پیشخوان، دیر لود شدن ویرایشگر، یا افزایش درخواستهای تکراری به admin-ajax نشان میدهد.
نکته اینجاست که Heartbeat را باید مدیریت کرد، نه اینکه کورکورانه خاموش کرد؛ چون خاموش کردن کامل، ممکن است باعث از دست رفتن ذخیره خودکار و مشکل در ویرایش همزمان شود.
3) افزایش تعداد درخواستها (Concurrent Requests) و معماری UI نادرست
گاهی هر درخواست admin-ajax خیلی هم سنگین نیست، اما تعداد درخواستها زیاد است. مثلاً یک صفحه شامل:
اسلایدر + پاپآپ + جستجوی زنده + مینیکارت + نمایش پرفروشها + پیشنهاد هوشمند باشد. اگر هر کدام یک Ajax بزنند، با ورود هر کاربر، چندین درخواست همزمان ایجاد میشود. در ترافیک بالا، همین موضوع کافی است تا PHP Workers اشباع شوند و درخواستها در صف بمانند؛ نتیجه: کندی عمومی سایت.
4) کش نشدن پاسخها یا قابل کش نبودن طراحی
بسیاری از پاسخهای Ajax قابل کش هستند (مثلاً “لیست پرفروشترینها” یا “آخرین مقالات” در یک ویجت ثابت)، اما در طراحی برخی افزونهها، همه چیز به شکل داینامیک و بدون کش انجام میشود. اگر همان داده برای هزار کاربر یکسان است، هیچ منطقی ندارد هر بار از دیتابیس استخراج شود.
راهحل حرفهای اینجا استفاده از Transient API یا Object Cache (مثل Redis/Memcached) است.
5) دیتابیس کند، wp_options سنگین و autoload مشکلساز
حتی اگر Ajax از نظر منطق برنامه سبک باشد، دیتابیس میتواند گلوگاه شود. مواردی مثل:
زیاد شدن دادههای autoload در جدول wp_options، انباشته شدن transientها، لاگهای افزونهها، یا نبود ایندکس روی جداول پرمصرف (خصوصاً در ووکامرس) باعث میشود هر درخواست Ajax زمان زیادی صرف کوئریها کند. این موضوع در ابزارهایی مثل Query Monitor یا New Relic به شکل کوئریهای طولانی کاملاً قابل مشاهده است.
6) منابع ناکافی هاست، محدودیت PHP Workers و تنظیمات ضعیف PHP
روی هاستهای اشتراکی، محدودیت تعداد پردازههای PHP (یا PHP Workers) بسیار تعیینکننده است. وقتی درخواستهای Ajax زیاد میشود، سریعتر از صفحات عادی صف ایجاد میکنند، چون معمولاً قابل کش در سطح CDN/کش صفحه نیستند.
اگر OPcache خاموش باشد یا منابع CPU/I/O کم باشد، زمان پاسخدهی شدیداً افزایش پیدا میکند.
نتیجه ممکن است خطاهایی مثل 504/503 یا کندی شدید در ساعات پرترافیک باشد.
7) بدافزار، اسکریپتهای مخرب و Abuse روی admin-ajax
در برخی موارد، کندی admin-ajax به خاطر یک افزونه معمولی نیست؛ بلکه یک اسکریپت مخرب یا باتها به صورت هدفمند از مسیر admin-ajax سوءاستفاده میکنند؛ چون میدانند در بسیاری از سایتها باز است و میتواند عملیات سنگین ایجاد کند. اگر در لاگها درخواستهای غیرعادی، پارامترهای عجیب یا نرخهای بالا از IPهای مشکوک میبینید،
موضوع امنیت را جدی بگیرید.
نشانهها و علائم کندی admin-ajax (از نگاه کاربر و مدیر سایت)
برای اینکه مطمئن شوید مشکل واقعاً از admin-ajax است، باید نشانهها را درست بشناسید. گاهی کندی سایت به خاطر تصاویر سنگین یا اسکریپتهای فرانتاند است؛ اما admin-ajax معمولاً الگوی مشخصی دارد:
درخواستهای XHR تکراری، طولانی، و پرتعداد.
علائم رایج در فرانتاند
- کند شدن فیلترها، مینیکارت یا جستجوی زنده
- گیر کردن عملیات “افزودن به سبد خرید” یا نمایش پیامهای دیرهنگام
- کندی محسوس در صفحات خاص (مثلاً صفحه فروشگاه یا دسته محصولات)
- در DevTools مرورگر، XHR به
admin-ajax.phpبا زمانهای 1 تا چند ثانیه
علائم رایج در پیشخوان (Backend)
- کندی ویرایشگر، ذخیره خودکار دیرهنگام، یا پیامهای تأخیر در ذخیره
- افزایش درخواستهای دورهای (Heartbeat) در Network
- کند شدن صفحات تنظیمات برخی افزونهها
علائم روی هاست/سرور
- افزایش CPU و RAM همزمان با افزایش بازدید
- وجود حجم بالایی از درخواستها به مسیر
/wp-admin/admin-ajax.phpدر access log - خطاهای 503/504 هنگام اوج ترافیک
- کند شدن کلی سایت با وجود فعال بودن کش صفحه (چون Ajax معمولاً از کش صفحه عبور میکند)
چطور دقیقاً بفهمیم کدام درخواست Ajax مشکل دارد؟ (روشهای حرفهای تشخیص)
بزرگترین اشتباه در حل کندی admin-ajax این است که بدون شناسایی اکشن (action) مشکلدار، شروع کنیم به خاموش/روشن کردن افزونهها یا تغییرات تصادفی. روش حرفهای این است که بفهمیم: کدام action بیشترین زمان را میگیرد، چه افزونهای آن را ساخته و دقیقاً چه کاری در سرور انجام میدهد.
روش 1: بررسی با DevTools مرورگر (سریع و بدون افزونه)
- صفحه مشکلدار را در Chrome باز کنید.
- کلید F12 را بزنید و وارد تب Network شوید.
- فیلتر XHR یا Fetch را فعال کنید.
- درخواستهایی که به
admin-ajax.phpمیروند را پیدا کنید. - روی یکی از آنها کلیک کنید و در بخش Payload/Headers دنبال پارامتر
actionبگردید.
پارامتر action معمولاً نام عملیاتی است که افزونه/قالب تعریف کرده. همین نام، کلید اصلی برای پیدا کردن منبع مشکل است.
روش 2: Query Monitor (برای ردیابی دقیق افزونه و کوئریها)
افزونه Query Monitor یکی از بهترین ابزارها برای تشخیص گلوگاههای وردپرس است. با آن میتوانید ببینید در زمان اجرای یک درخواست Ajax:
چه کوئریهایی اجرا شده، کدام هوکها درگیر بودهاند، و زمان پردازش دقیقاً کجا صرف شده است.
- درخواست Ajax را پیدا کنید
- زمان اجرای PHP را بررسی کنید
- کوئریهای سنگین و تکراری را شناسایی کنید
- منبع (پلاگین/قالب) را تشخیص دهید
روش 3: بررسی لاگها (Access log / Error log)
اگر به لاگ دسترسی دارید، بررسی Access log بسیار روشنگر است: میبینید کدام IP بیشترین درخواست به admin-ajax میزند، نرخ درخواست چقدر است، و آیا الگو شبیه حمله/بات است یا ترافیک واقعی. همچنین Error log میتواند خطاهای PHP مرتبط با برخی اکشنهای Ajax را نشان دهد که خودشان باعث کندی/ریتری میشوند.
راهکارهای قطعی و مدرن برای رفع کندی admin-ajax.php (به ترتیب اولویت و اثرگذاری)
راهحل واقعی، مجموعهای از اقدامات است؛ اما اگر بخواهیم اصولی نگاه کنیم، شما باید دو هدف را همزمان دنبال کنید:
(الف) کاهش تعداد درخواستها و
(ب) کاهش هزینه پردازش هر درخواست.
در ادامه، راهکارها را به شکل عملی، با توضیحات کامل و نکات اجرایی میخوانید.
راهکار 1: افزونه/قالب تولیدکننده Ajax سنگین را شناسایی و اصلاح کنید
اولین و اثرگذارترین اقدام این است که دقیقاً همان اکشنی را که کند است پیدا کنید. سپس یکی از این مسیرها را انتخاب کنید:
یا تنظیمات افزونه را تغییر دهید (مثلاً کاهش رفرش زنده، خاموش کردن ویجت غیرضروری، کم کردن نمایشهای داینامیک)، یا اگر افزونه واقعاً سنگین و ناکارآمد است، جایگزین سبکتر پیدا کنید.
نکته مهم: خیلی از مدیران سایت چند افزونه همکارکرد نصب میکنند (مثلاً چند ابزار آمار، چند ابزار بهینهسازی، چند ابزار اسلایدر/پاپآپ). تداخل این افزونهها باعث میشود تعداد درخواستها چند برابر شود. یک ممیزی ساده افزونهها و حذف موارد کمارزش، در بسیاری از سایتها مشکل را تا حد زیادی حل میکند.
راهکار 2: Heartbeat API را مدیریت کنید (نه خاموش کورکورانه)
اگر کندی بیشتر در پیشخوان اتفاق میافتد، یا در Network درخواستهای دورهای میبینید، احتمالاً Heartbeat نقش پررنگی دارد. بهترین رویکرد این است که فرکانس Heartbeat را کمتر کنید یا اجرای آن را به صفحات ضروری (مثل صفحه ویرایش نوشته) محدود کنید.
خاموش کردن کامل Heartbeat ممکن است باعث شود ذخیره خودکار از کار بیفتد یا هنگام ویرایش همزمان، مشکل ایجاد شود. بنابراین اگر تیم فنی دارید، بهتر است کنترل آن را دقیق و مرحلهای انجام دهید.
- کاهش نرخ پینگ (مثلاً از 15 ثانیه به 60 ثانیه)
- محدود کردن Heartbeat به برخی صفحات
- بررسی افزونههایی که Heartbeat را سنگینتر میکنند
راهکار 3: برای اکشنهای تکراری، کش لایهای تعریف کنید (Transient / Object Cache)
یکی از حرفهایترین کارها این است که اکشنهای Ajax را بررسی کنید و ببینید کدام پاسخها “واقعاً تکراری” هستند.
مثال واضح: یک ویجت “پرفروشترین محصولات” یا “آخرین مطالب” که برای همه کاربران یکسان است. اگر چنین دادهای هر بار با کوئریهای سنگین از دیتابیس استخراج شود، admin-ajax بهطور طبیعی کند خواهد شد.
اینجا دو تکنیک بسیار مؤثر دارید:
Transient API (کش داخل وردپرس با زمان انقضا) و Object Cache مثل Redis که ذخیره/خواندن داده را بسیار سریعتر میکند. خروجی اکشن را 1 تا 10 دقیقه کش کنید (بسته به ماهیت داده)، سپس با یک درخواست سبک، نتیجه را برگردانید. این کار در ترافیک بالا، تفاوتی شبیه “شب و روز” ایجاد میکند.
راهکار 4: کاهش درخواستهای همزمان (UI/اسکریپتها را بازطراحی کنید)
اگر یک صفحه چندین درخواست Ajax دارد، باید اولویتبندی کنید: کدام قابلیت واقعاً ضروری است و کدام قابلیت فقط “تزئینی” است. بسیاری از سایتها با حذف چند ویجت غیرضروری (مثل شمارندههای لحظهای، پاپآپهای سنگین، پیشنهادهای بیش از حد) بهبود بزرگ میگیرند.
همچنین میتوانید درخواستها را “تجمیع” کنید؛ یعنی به جای اینکه هر ویجت جداگانه یک Ajax بزند، یک endpoint دادههای مورد نیاز را برگرداند و در فرانتاند بین بخشها تقسیم شود.
این کار معمولاً نیاز به توسعه اختصاصی دارد، اما در سایتهای جدی کاملاً ارزشمند است.
راهکار 5: درخواستهای Ajax برای کاربران مهمان را محدود کنید (در صورت امکان)
یک اشتباه رایج این است که عملیات پرهزینه برای کاربر مهمان هم فعال باشد؛ در حالی که شاید ارزش واقعی ندارد. مثلاً یک سایت ممکن است برای هر بازدید مهمان، دادههای پیشنهادی را داینامیک بسازد یا آمار لحظهای ثبت کند. اگر هدف شما سئو و تجربه کاربری است، بهتر است عملیات سنگین را یا محدود کنید، یا با کش انجام دهید، یا فقط پس از تعامل کاربر (مثلاً کلیک) اجرا کنید.
- اجرای برخی اکشنها فقط برای کاربران لاگینشده
- اجرای Ajax فقط بعد از تعامل (به جای اجرا در لود اولیه)
- کاهش نرخ رفرش زنده ویجتها
نقش حملات، باتها و بدافزار در فشار admin-ajax (موضوعی که نباید دستکم بگیرید)
اگر تعداد درخواستهای admin-ajax ناگهان افزایش پیدا کرده و با رفتار عادی کاربران سازگار نیست، یکی از سناریوهای جدی، Abuse یا حمله است. مهاجمها معمولاً به دنبال مسیرهایی هستند که:
در بسیاری از سایتها باز است، میتواند پردازش سنگین ایجاد کند، توسط کش صفحه پوشش داده نمیشود. admin-ajax دقیقاً چنین ویژگیهایی دارد.
نشانههای حمله/بات روی admin-ajax
- افزایش درخواستها از IPهای متعدد یا یک IP با نرخ بسیار بالا
- درخواستها حتی وقتی بازدید واقعی ندارید هم ادامه دارد
- وجود پارامترهای غیرعادی در درخواستها
- بالا رفتن مصرف منابع در ساعات غیرمعمول
- افزایش خطاهای 403/404/503 کنار admin-ajax
راهکارهای امنیتی موثر
بهترین رویکرد امنیتی این است که قبل از اینکه فشار سرور بالا برود، یک لایه محافظ داشته باشید: WAF (مثل Cloudflare)، Rate Limiting و قوانین محدودسازی روی مسیر admin-ajax.
همچنین اگر احتمال آلودگی وجود دارد، بررسی فایلها و دیتابیس و پاکسازی حرفهای ضروری است.
اگر “کندی” همراه با “الگوهای مشکوک” باشد، بهینهسازی به تنهایی کافی نیست؛
چون تا زمانی که منبع حمله یا کد مخرب حذف نشود، فشار دوباره برمیگردد.
بهینهسازی دیتابیس و سرور برای کاهش زمان پردازش Ajax (به زبان عملی)
وقتی یک درخواست Ajax وارد وردپرس میشود، معمولاً چند مرحله پشت سر هم رخ میدهد: PHP اجرا میشود، وردپرس بوت میشود، افزونهها هوکها را اجرا میکنند، کوئریهای دیتابیس زده میشود، سپس خروجی تولید و ارسال میشود. اگر هر کدام از این بخشها کند باشد، admin-ajax کند به نظر میرسد.
بنابراین باید هم دیتابیس را تمیز و سریع نگه دارید و هم لایه PHP/سرور را درست تنظیم کنید.
بهینهسازی دیتابیس (مخصوصاً برای سایتهای فروشگاهی)
- wp_options و autoload:
اگر autoload سنگین شود، در هر درخواست (حتی Ajax) حجم زیادی داده بیدلیل بارگذاری میشود و سرعت پایین میآید. - پاکسازی transientها:
transientهای خراب یا انباشته شده میتوانند هم دیتابیس را سنگین کنند و هم باعث تأخیر شوند. - لاگ افزونهها:
بعضی افزونهها لاگهای عظیم ذخیره میکنند؛ اگر پاکسازی دورهای نداشته باشند، کوئریها کند میشود. - ایندکسگذاری:
در ووکامرس و سایتهای دادهمحور، نبود ایندکس مناسب روی ستونهای پرتکرار میتواند هر درخواست Ajax را چند برابر کند.
بهینهسازی سرور و PHP (کلیدی برای admin-ajax)
- OPcache: اگر خاموش باشد، PHP کدها را هر بار دوباره کامپایل میکند و زمان پاسخ بالا میرود.
- PHP Workers: محدودیت پردازهها باعث صف شدن درخواستهای Ajax و کندی زنجیرهای میشود.
- Object Cache (Redis): فشار دیتابیس را کم میکند و پاسخ Ajax را سریعتر میکند.
- وبسرور: LiteSpeed/NGINX با تنظیم درست معمولاً عملکرد بهتری از Apache در بار بالا دارد.
- منابع واقعی: اگر سایت رشد کرده، گاهی تنها راه منطقی، ارتقای منابع یا مهاجرت به سرویس بهتر است.
جایگزینی مدرن: مهاجرت از admin-ajax به REST API (برای توسعههای حرفهای)
اگر سایت شما توسعه اختصاصی دارد (یا برنامه دارید بخشهایی سفارشی بسازید)، بهتر است بدانید که دنیای وردپرس مدرن بیشتر به سمت WP REST API رفته است. REST API معمولاً ساختارمندتر است، ابزارهای بیشتری برای کش شدن دارد، و از نظر معماری، استانداردتر محسوب میشود.
البته این به معنای “بد بودن admin-ajax” نیست. هنوز هم برای بسیاری از سناریوها مناسب است، اما اگر میخواهید طراحی پایدارتر، قابل توسعهتر و سازگارتر با کش و CDN داشته باشید، REST API گزینه بهتری است. در برخی پروژهها، ترکیب این دو هم منطقی است:
کارهای سبک و سازگار با کش در REST، و برخی عملیات اداری/خاص در admin-ajax.
چه زمانی مهاجرت به REST API ارزشمند است؟
- وقتی چندین ویجت/کامپوننت نیاز به دادههای داینامیک دارند
- وقتی میخواهید پاسخها قابل کشتر باشند
- وقتی SPA یا فرانتاند مدرن (React/Vue) دارید
- وقتی کنترل دقیق روی endpointها و محدودسازیها میخواهید
چکلیست مرحلهای عیبیابی (گامبهگام، قابل اجرا برای اکثر سایتها)
- گام 1: شناسایی action در DevTools یا Query Monitor، درخواستهای
admin-ajax.phpرا ببینید و نامactionرا استخراج کنید.
بدون این مرحله، عملاً دارید حدس میزنید. - گام 2: بررسی کنید درخواست از فرانت است یا بکانداگر بیشتر در پیشخوان است، Heartbeat محتملتر است. اگر در صفحات فروشگاه/صفحه اصلی است،
افزونههای فرانتاند یا ویجتها محتملترند. - گام 3: تعداد درخواستها را اندازه بگیریدآیا هر کاربر با ورود، 1 درخواست Ajax دارد یا 10 درخواست؟ آیا درخواستها هر چند ثانیه تکرار میشوند؟
اگر تعداد زیاد است، باید UI را سبکتر کنید یا نرخ رفرش زنده را پایین بیاورید. - گام 4: زمان پردازش هر درخواست را بررسی کنیداگر هر درخواست 1 تا 3 ثانیه طول میکشد، مشکل احتمالاً کوئری دیتابیس، محاسبه بدون کش، یا سرور ضعیف است.
اگر هر درخواست 200ms است اما تعداد زیاد، مشکل معماری و ترافیک/باتهاست. - گام 5: تست افزونهها به روش کنترلشدهموقتاً افزونه مرتبط با action را غیرفعال کنید (در زمان کمترافیک و با دقت).
اگر مشکل حل شد، یا تنظیمات افزونه را اصلاح کنید یا جایگزین مناسب انتخاب کنید. - گام 6: بررسی امنیت و باتهااگر الگو غیرعادی است، WAF و Rate Limit را فعال کنید و لاگها را بررسی کنید.
در صورت مشکوک بودن، پاکسازی و بررسی امنیتی را جدی بگیرید. - گام 7: بهینهسازی کش/دیتابیس/سروربعد از اینکه منبع دقیق مشخص شد، روی کش مناسب (Object Cache)، بهینهسازی دیتابیس و تنظیمات PHP تمرکز کنید.
این مرحله معمولاً بیشترین اثر را روی “زمان پاسخ” دارد.
جدول جمعبندی علتها و راهحلها (سریع و تصمیمساز)
| علت اصلی | نشانهها | بهترین راهحل عملی |
|---|---|---|
| افزونه Ajax سنگین | XHR طولانی، افزایش CPU، کندی در صفحات خاص | شناسایی action، اصلاح تنظیمات، حذف/جایگزینی، کش کردن خروجی |
| Heartbeat API پرتکرار | کندی پیشخوان، درخواستهای دورهای | کاهش فرکانس Heartbeat، محدودسازی به صفحات ضروری |
| تعداد زیاد درخواستها | شبکه پر از XHR، اشباع PHP Workers | کاهش ویجتهای Ajax، اجرای Ajax بعد از تعامل، تجمیع درخواستها |
| دیتابیس کند / autoload سنگین | کوئریهای طولانی در QM/New Relic | پاکسازی، کاهش autoload، ایندکسگذاری، Redis Object Cache |
| هاست ضعیف / تنظیمات PHP نامناسب | TTFB بالا، صف شدن درخواستها، 503/504 | OPcache، افزایش PHP Workers، ارتقای منابع، تنظیم PHP-FPM |
| بات/حمله/بدافزار | الگوی غیرعادی، IPهای مشکوک، درخواستهای زیاد بدون بازدید | WAF، Rate limit، مسدودسازی، بررسی امنیت و پاکسازی |
جمعبندی و مسیر پیشنهادی اجرا (کاملاً عملی)
برای رفع کندی admin-ajax.php یک نسخه “یکسان برای همه” وجود ندارد؛ اما یک مسیر استاندارد و حرفهای داریم که تقریباً همیشه جواب میدهد: ابتدا اکشن مشکلدار را پیدا میکنیم، سپس تعداد درخواستها را کنترل میکنیم، بعد هزینه پردازش را کاهش میدهیم، و در نهایت اگر نیاز باشد سراغ بهینهسازی سرور/دیتابیس و امنیت میرویم.
