کندی پیشخوان ووکامرس؛ چطور علت را قبل از ارتقای سرور پیدا کنیم؟

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

نویسنده: سجاد · انتشار: ۲۰۲۶/۱۰/۱۳

اول معلوم کنید کدام عملیات کند است

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

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

زمان پاسخ سرور را از انتظار مرورگر جدا کنید

در بخش Network ابزار توسعهٔ مرورگر، درخواست اصلی و درخواست‌های بعدی صفحه را ببینید. اگر HTML رسیده ولی جدول سفارش‌ها منتظر یک درخواست Ajax یا REST است، همان درخواست را بررسی کنید. مدت انتظار پاسخ اولیه را از دانلود و پردازش رابط جدا کنید. زمان انتظار شبکه به‌تنهایی زمان اجرای PHP نیست؛ شبکه، صف پردازش و مسیر واسط هم می‌توانند در آن سهم داشته باشند.

اگر پاسخ‌ها زود می‌رسند ولی کلیک و نمایش جدول دیر است، خطاهای JavaScript، تعداد عناصر صفحه و پردازش مرورگر را بررسی کنید. اگر خود پاسخ دیر می‌آید، سراغ پردازش سرور و وابستگی‌های آن بروید. مقایسهٔ یک صفحهٔ عمومیِ کش‌شده با پیشخوان واردشده علت را اثبات نمی‌کند. اطلاعات شخصی، Cookie و توکن را پیش از ارسال تصویر یا فایل شبکه حذف کنید.

چه شواهدی جمع کنیم؟

• مرورگر: درخواست کند، نوع آن، کد پاسخ و زمان‌بندی مراحل؛ آیا مشکل در مرورگر یا شبکهٔ دیگری هم تکرار می‌شود؟
• وردپرس: نسخه‌ها و افزونه‌های فعال، خطای PHP و مؤلفهٔ مرتبط با عملیات.
• پایگاه داده: پرس‌وجوهای کند یا تکراری و مؤلفهٔ فراخوان؛ تعداد زیاد به‌تنهایی علت قطعی نیست.
• سرویس بیرونی: مقصد درخواست، مدت انتظار و خطا؛ بدون ثبت کلید یا دادهٔ مشتری.
• سرور: مصرف و محدودیت CPU، حافظه، وضعیت پردازش‌های PHP و ورودی‌خروجی دیسک در همان بازه.

گزارش وضعیت سیستم ووکامرس برای ثبت محیط و نسخه‌ها مفید است، اما جای پروفایل همان درخواست کند را نمی‌گیرد. گزارش را پیش از اشتراک‌گذاری از نظر نشانی‌ها و اطلاعات محیط بررسی کنید.

Query Monitor چه چیزی را روشن می‌کند؟

طبق صفحهٔ رسمی Query Monitor، این ابزار پرس‌وجوهای پایگاه داده را بر اساس مؤلفه دسته‌بندی می‌کند و خطاهای PHP و زمان تماس‌های HTTP را نشان می‌دهد. برای مثال، می‌توان دید آیا بارگیری همان صفحه با پرس‌وجوهای تکراری یک افزونه یا انتظار یک مقصد بیرونی همراه بوده است. این نشانه برای ساخت فرضیه مفید است؛ اثبات علت به آزمون مقایسه‌ای نیاز دارد.

ابزار را ابتدا در محیط آزمایشی مناسب به کار ببرید. ابزار عیب‌یابی خودش سربار دارد؛ زمان اجرای اندازه‌گیری همراه ابزار را با نتیجهٔ بدون ابزار یکی نگیرید. اگر درخواست Ajax یا REST کند است، فقط خروجی درخواست HTML را ملاک قرار ندهید. محدودیت ثبت ابزار و دسترسی کاربر را نیز در گزارش بنویسید.

از نشانه تا آزمون: کدام فرضیه را بررسی کنیم؟

• فهرست سفارش‌ها کند است، صفحات دیگر عادی‌اند: ستون‌های سفارشی، فیلتر و فراخوانی داده برای هر سفارش را بررسی کنید. در کپی آزمایشی، ستون یا مؤلفهٔ مشکوک را جدا مقایسه کنید.
• ذخیرهٔ محصول منتظر اتصال است: مدت تماس با انبار، پیامک یا سرویس دیگر را ببینید. انتقال کار به صف فقط زمانی مناسب است که نمایش نتیجه، خطا و تلاش دوباره هم طراحی شود.
• همهٔ عملیات در ساعت شلوغ کند می‌شوند: گزارش منابع و صف پردازش همان بازه را با ساعات دیگر مقایسه کنید؛ یک نمونهٔ خلوت کمبود ظرفیت را رد نمی‌کند.
• پاسخ سریع است ولی رابط دیر آماده می‌شود: درخواست‌های بعدی، خطای مرورگر و اجرای اسکریپت را بررسی کنید؛ تغییر سرور پیش از این تفکیک ممکن است مسئله را هدف نگیرد.

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

مثال فرضی: چرا بازکردن سفارش منتظر انبار می‌ماند؟

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

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

کش، HPOS یا سرور قوی‌تر؛ چه زمانی کمک می‌کنند؟

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

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

بعد از اصلاح، فقط زمان را نسنجید

1. تکرار آزمون: همان عملیات با نقش، فیلتر و دادهٔ مشابه چند بار اجرا شود؛ وضعیت ابزار تشخیص و کش معلوم باشد.
2. صحت سفارش: بازکردن، تغییر وضعیت و ذخیرهٔ سفارش نتیجهٔ درست بدهد؛ عملیات تکراری ناخواسته ساخته نشود.
3. تازگی داده: تغییر قیمت یا موجودی با قاعدهٔ تعیین‌شده دیده شود و دادهٔ قدیمی قابل تشخیص باشد.
4. دسترسی: نقش محدود همان داده و عملیات مجاز را داشته باشد؛ کش مرز دسترسی را تغییر ندهد.
5. وابستگی بیرونی: پاسخ کند یا ناموفق مقصد، رفتار تعریف‌شده داشته باشد؛ پنل خطای قابل پیگیری نشان دهد.
6. بازگشت: نسخهٔ قبل، تنظیمات تغییرکرده و مسئول بازگشت مشخص باشند؛ روش توقف تغییر در محیط آزمایشی بررسی شود.

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

برای بررسی کندی پیشخوان چه بفرستید؟

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