زیاد شدن تعداد محصول به‌تنهایی نباید هر صفحه فروشگاه را کند کند. مشکل معمولاً زمانی دیده می‌شود که یک Query برای هر درخواست بخش بزرگی از محصول و metadata را scan می‌کند، فیلترهای ترکیبی index مناسب ندارند، قالب برای هر کارت محصول چند Query یا محاسبه اجرا می‌کند، یا import و sync هم‌زمان دیتابیس را تحت فشار می‌گذارد. اول باید مسیر کند را دقیق نام‌گذاری کنید.
پاسخ سریع: صفحه دسته، جست‌وجو، فیلتر، ویرایش محصول، import و Checkout را جدا benchmark کنید. Queryهای پرتکرار و کند، cache hit/miss، PHP time و مصرف دیتابیس را در همان سناریو ثبت کنید. حذف metadata، افزودن index حدسی یا ارتقای سرور پیش از یافتن Query می‌تواند هزینه را بیشتر و مشکل را پنهان کند.
«فروشگاه کند» کدام بخش است؟
| مسیر | گلوگاه محتمل | ابزار تشخیص |
|---|---|---|
| دسته محصولات | Query کاتالوگ، کارت محصول، تصویر و cache | DevTools، Query Monitor، slow log |
| جست‌وجو و فیلتر | meta/tax query، sort و شمارش facet | Query plan و profiler |
| ویرایش/فهرست مدیریت | ستون افزونه، lookup خارجی و autoload | Query Monitor و PHP trace |
| Import یا Sync | write زیاد، index، تصویر و API | batch timing، queue و DB metrics |
| Checkout | session، ارسال، درگاه و موجودی | Network و log تراکنش |
اگر صفحه اصلی سریع اما فیلتر قیمت کند است، بهینه‌سازی فونت یا تصویر مسئله اصلی نیست. اگر wp-admin کند و صفحات cacheشده سریع‌اند، backend و Queryهای مدیریتی را بررسی کنید.
اندازه کاتالوگ را با شکل داده بسنجید
ده‌هزار محصول ساده با ویژگی محدود با همان تعداد محصول متغیر و صدها variation رفتار یکسانی ندارد. تعداد variation، taxonomy، attribute، meta row، تصویر و تاریخچه تغییر مهم‌اند. یک شمارش خام محصول برای ظرفیت‌سنجی کافی نیست؛ نسبت variation به محصول و Queryهای واقعی workload را ثبت کنید.
Queryهای فیلتر و جست‌وجو
فیلتر هم‌زمان قیمت، موجودی، برند، چند ویژگی و sort می‌تواند join و شمارش پرهزینه بسازد. با Slow Query وردپرس، متن Query، فراوانی، زمان و execution plan را بررسی کنید. Query یک‌بارۀ ۳۰۰ میلی‌ثانیه‌ای ممکن است از Query پنجاه‌بارۀ ۳۰ میلی‌ثانیه‌ای کم‌اهمیت‌تر باشد.
index باید بر اساس predicate، join، ترتیب ستون و الگوی write طراحی شود. index زیاد import و update را کند و فضای دیسک را مصرف می‌کند. روی clone دارای داده نزدیک به production، plan قبل و بعد و هزینه write را مقایسه کنید؛ schema production را با توصیه عمومی اینترنت تغییر ندهید.
N+1 در کارت‌های محصول
قالب یا افزونه ممکن است برای هر محصول جداگانه امتیاز، موجودی شعبه، قیمت سفارشی یا داده ERP را بخواند. با افزایش تعداد کارت، تعداد Query یا HTTP call خطی بالا می‌رود. profiler باید caller را نشان دهد. راه‌حل می‌تواند prefetch، lookup مناسب، batch API یا cache محدود باشد؛ حذف ویژگی تجاری بدون شناخت لازم نیست.
Lookup Table و داده‌های مشتق‌شده
ووکامرس برای بعضی جست‌وجوهای محصول از داده‌های lookup استفاده می‌کند. اگر sync سفارشی محصول را خارج از APIهای پشتیبانی‌شده تغییر دهد، lookup ممکن است قدیمی شود. ابزارهای رسمی بازسازی را فقط پس از backup و ابتدا روی staging اجرا کنید؛ rebuild روی کاتالوگ بزرگ می‌تواند I/O و lock ایجاد کند و باید زمان‌بندی و مانیتور شود.
Page Cache و Object Cache
صفحات عمومی دسته می‌توانند از page cache سود ببرند، اما تعداد ترکیب فیلتر، زبان، ارز و وضعیت کاربر ممکن است cache keyها را منفجر کند. Cart و Checkout را عمومی cache نکنید. object cache مانند Redis در workload خواندنی تکراری مفید است، اما Query بد، cardinality بالا یا invalidation مداوم را خودکار حل نمی‌کند.
hit rate، eviction، memory و latency را اندازه بگیرید. نگهداری objectهای بزرگ یا TTL نامتناسب ممکن است RAM را پر کند. راه‌اندازی Redis بدون prefix درست در چند محیط نیز خطر آمیختن داده cache را دارد.
Import، ERP Sync و تغییرات انبوه
واردسازی تصویر، قیمت و موجودی می‌تواند CPU، I/O و دیتابیس را هم‌زمان مصرف کند. batch size، concurrency، retry و نرخ خطا را ثبت کنید. عملیات را idempotent طراحی کنید تا retry محصول تکراری نسازد. اجرای import سنگین در ساعت خرید و همراه backup یا گزارش‌گیری، latency کاربران را بالا می‌برد.
برای update فقط فیلدهای تغییرکرده را بنویسید و از درخواست یک‌به‌یک غیرضروری به ERP دوری کنید. اما مستقیم‌نویسی در جدول‌ها برای سرعت، hook، cache invalidation و lookup را دور می‌زند و یکپارچگی کاتالوگ را به خطر می‌اندازد.
تصویر و Media Library
کاتالوگ بزرگ معمولاً media زیادی دارد. تصویر بیش‌ازحد بزرگ، thumbnailهای متعدد و storage کند، صفحه و import را متاثر می‌کند. فرمت و ابعاد را متناسب با محل نمایش تولید کنید و lazy loading را با تصویر اصلی بالای صفحه اشتباه اعمال نکنید. حذف گروهی فایل‌های «بدون استفاده» خطرناک است، چون reference ممکن است در meta، variation یا محتوای ترجمه‌شده باشد.
wp-admin و ستون‌های سفارشی
ستون موجودی، SEO، supplier یا آمار فروش می‌تواند برای هر ردیف Query یا API اجرا کند. تعداد ردیف صفحه را موقتاً کم و ستون‌ها را روی staging مقایسه کنید. اگر ذخیره محصول کند است، hookهای save، تولید تصویر، sync و پاک‌سازی cache را trace کنید؛ سرعت آرشیو عمومی شاهد مناسبی برای این مسیر نیست.
منابع و ظرفیت PHP/MySQL
CPU، available RAM، I/O latency، buffer pool، connection و صف PHP را در بازه کندی ببینید. افزایش worker بدون RAM کافی می‌تواند swap یا OOM بسازد. سرور بزرگ‌تر زمانی منطقی است که saturation با workload معتبر اثبات شده و Query/کد غیرعادی رفع شده باشد. راهنمای تشخیص کندی ووکامرس تفکیک frontend و backend را کامل می‌کند.
جست‌وجوی مستقل چه زمانی مطرح می‌شود؟
اگر نیاز به جست‌وجوی متنی و facet پیچیده در کاتالوگ بزرگ دارید و بهینه‌سازی Query داخلی به نیاز محصول پاسخ نمی‌دهد، موتور جست‌وجوی جدا می‌تواند گزینه باشد. اما sync، تأخیر ایندکس، fallback، مانیتورینگ و هزینه عملیاتی اضافه می‌کند. قبل از انتخاب، queryهای واقعی، کیفیت نتیجه، نرخ update و رفتار هنگام قطع سرویس را آزمایش کنید.
برنامه اصلاح مرحله‌ای
- از دیتابیس و media backup قابل restore بگیرید.
- سه تا پنج سناریوی واقعی و baseline ثبت کنید.
- Query، PHP، HTTP خارجی و resource را در یک timeline پروفایل کنید.
- N+1، خطا و job مزاحم را در مالک اصلی اصلاح کنید.
- lookup و index را فقط با plan و clone ارزیابی کنید.
- cache را با key، invalidation و hit rate طراحی کنید.
- import و sync را batch، rate-limit و زمان‌بندی کنید.
- ظرفیت یا معماری جست‌وجو را پس از اندازه‌گیری ارتقا دهید.
معیار پذیرش تغییر
- p50 و p95 صفحه دسته، جست‌وجو و فیلتر
- تعداد و مجموع زمان Query در هر request
- زمان ذخیره محصول و throughput import
- درستی قیمت، موجودی، variation و نتایج فیلتر
- cache hit rate و eviction
- CPU، RAM، I/O و صف PHP در بار کنترل‌شده
فقط سریع شدن یک URL با cache گرم کافی نیست. cache سرد، کاربر واردشده، تغییر موجودی و invalidation پس از update را نیز آزمایش کنید.
اشتباه‌های رایج
- حذف postmeta یا محصول قدیمی بدون backup و معیار
- ساخت index حدسی روی production
- نصب چند افزونه cache و جست‌وجو هم‌زمان
- اجرای import با concurrency نامحدود
- افزایش PHP worker بدون بودجه RAM
- سنجش فقط صفحه اصلی cacheشده
- نادیده گرفتن درستی قیمت و موجودی برای کسب سرعت
چه زمانی کمک تخصصی لازم است؟
اگر فیلتر، import یا مدیریت محصول با رشد کاتالوگ کند شده و تغییر schema یا معماری جست‌وجو مطرح است، آزمون مستقیم روی production می‌تواند فروش و موجودی را مختل کند. پشتیبانی فروشگاه ووکامرس می‌تواند Query، کد مالک، cache و workload همگام‌سازی را اندازه‌گیری و اصلاح قابل بازگشت طراحی کند.
پرسش‌های متداول
ووکامرس حداکثر چند محصول را پشتیبانی می‌کند؟
یک عدد ثابت و معنادار وجود ندارد؛ variation، Query، افزونه، سخت‌افزار و نرخ تغییر workload را تعیین می‌کنند.
آیا VPS مشکل کاتالوگ بزرگ را حل می‌کند؟
اگر محدودیت زیرساخت اثبات شود کمک می‌کند، اما N+1، Query بدون index یا API کند باقی می‌ماند.
آیا Redis برای محصولات زیاد ضروری است؟
خیر؛ باید الگوی reuse، hit rate و invalidation آن را توجیه کند. page و Query نامناسب را جایگزین نمی‌کند.
آیا حذف محصولات ناموجود سرعت را بالا می‌برد؟
بدون اندازه‌گیری قطعی نیست و ممکن است URL و سابقه تجاری را از بین ببرد. archive، redirect و retention را آگاهانه طراحی کنید.