بهبود زیرساخت ووکامرس؛ تفکیک پاسخ مبدا و کش

گلوگاه پشت پاسخ CDN

درخواست مستقیم به مبدا معمولاً ۹ تا ۱۸ ثانیه منتظر می‌ماند و گاهی timeout می‌شد. workerهای PHP اشغال بودند، حافظهٔ دیتابیس با حجم داده تناسب نداشت و کش صفحه و object cache عملاً فعال نبودند.

برای بررسی، TTFB مستقیم و هم‌زمان، صف PHP-FPM، مصرف حافظهٔ هر worker و تنظیمات MariaDB کنار هم قرار گرفتند. هدرها و استثناهای کش برای مسیرهای شخصی هم بررسی شدند.

اقدام‌ها با توجه به منابع همان سرور

ظرفیت PHP-FPM و buffer pool پایگاه داده بازتنظیم شدند. Redis برای object cache راه‌اندازی شد و نرخ برخورد پس از گرم‌شدن بررسی شد. کش صفحه در reverse proxy با عبور مسیرهای پویا تنظیم شد.

داده‌های قدیمی به‌صورت کنترل‌شده و پس از تهیه و آزمون پشتیبان آرشیو شدند. این شرح مجوز حذف دادهٔ مشابه از فروشگاه دیگر نیست؛ نیاز نگهداری و وابستگی رکوردها باید مستقل بررسی شوند.

دو نتیجهٔ متفاوت برای دو نوع پاسخ

پس از تغییر، TTFB در cache miss حدود ۲٫۷ تا ۳٫۵ ثانیه و در پاسخ کش مبدا حدود ۰٫۱۷ تا ۰٫۲۳ ثانیه ثبت شد. Redis به نرخ برخورد نهایی حدود ۹۳٪ رسید و حجم داده حدود ۴۲۰ مگابایت کمتر شد. جدول، مقدارهای قبل و بعد را جدا نگه می‌دارد.

زمان‌ها از درخواست‌های مستقیم به مبدا در چند مرحله‌اند. سبد و حساب کاربری عمداً از کش عمومی عبور می‌کنند؛ سرعت پاسخ کش‌شده نشان‌دهندهٔ بهبود برابر همهٔ صفحات پویا نیست.

برای بررسی فروشگاه شما

مسیر، زمان رخداد و شرایط کاربر را ثبت کنید. کندی پیشخوان و صحت کش و سبد دو مسیر بررسی مرتبط‌اند. در خدمت سرعت و سرور پیشنهاد پس از اندازه‌گیری داده می‌شود، نه با کپی تنظیمات این پروژه.

جدول نتیجه‌های ثبت‌شده

ظرفیت پردازش را همراه حافظه بخوانیم

افزایش تعداد workerها بدون شناخت مصرف هرکدام می‌تواند محدودیت دیگری بسازد. در شرح این پروژه، ظرفیت PHP-FPM همراه الگوی بار و حافظه بررسی شد. بنابراین عدد تنظیم مناسب از همین محیط به دست می‌آمد، نه از یک دستور ثابت برای همهٔ سرورها. نتیجهٔ این صفحه نیز نسخهٔ آمادهٔ پیکربندی برای کپی در محیط دیگر نیست.

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

مقایسهٔ بعدی با کدام شرایط انجام شود؟

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