چرا سایت وردپرسی کند است؟ یک کیس واقعی: از ۴ ثانیه به ۱.۵ ثانیه

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

صورت مسئله

سایت ما با وردپرس، قالب Woodmart، Elementor و Yoast SEO ساخته شده و از WP Rocket برای کش صفحه استفاده می‌کند. صفحه‌های کش‌شده در حدود ۰.۱۲ ثانیه پاسخ می‌دادند و همه‌چیز خوب به نظر می‌رسید. اما وقتی همان صفحه‌ها را بدون کش درخواست کردیم، زمان پاسخ سرور (TTFB) بین ۳.۵ تا ۷ ثانیه بود. حتی فایل robots.txt که وردپرس آن را می‌سازد، ۲.۷ ثانیه طول می‌کشید.

چرا این مهم است، وقتی کش وجود دارد؟ چون هر بار که محتوا تغییر می‌کند کش پاک می‌شود، کاربران واردشده و فرم‌ها کش نمی‌شوند، و نقشه‌ی سایتی که گوگل می‌خواند هم معمولاً کش نیست. کش مشکل را پنهان می‌کند، حلش نمی‌کند.

قدم ۱: مظنونان همیشگی

اول سراغ موارد شناخته‌شده رفتیم:

• هندلر PHP: سایت با FastCGI قدیمی اجرا می‌شد. آن را به PHP-FPM تغییر دادیم.
• Object Cache: Redis روی سرور نصب بود اما وردپرس از آن استفاده نمی‌کرد. آن را فعال کردیم.

هر دو تغییر درست و لازم بودند، اما زمان پاسخ همچنان حدود ۳.۵ تا ۴ ثانیه بود. پس مشکل اصلی جای دیگری بود.

قدم ۲: فرضیه‌ای که غلط درآمد

سایت روی سروری با Plesk میزبانی می‌شود که ده‌ها سایت دیگر هم روی همان نسخه‌ی PHP دارد. حافظه‌ی OPcache (کش کد کامپایل‌شده‌ی PHP) فقط ۱۲۸ مگابایت بود و سقف ۱۰ هزار فایل داشت. این مقدار برای این همه سایت کم به نظر می‌رسید. فرضیه‌ی ما این بود که کش مدام پر و خالی می‌شود و کد در هر درخواست دوباره کامپایل می‌شود.

حافظه را به ۱ گیگابایت و سقف فایل را به ۱۰۰ هزار رساندیم و دوباره اندازه گرفتیم: هیچ تغییری نکرد. درس این مرحله: حدسی که منطقی به نظر می‌رسد، تا وقتی اندازه‌گیری نشده فقط یک حدس است.

قدم ۳: اندازه‌گیری به‌جای حدس

این بار زمان هر مرحله از اجرای وردپرس را جداگانه اندازه گرفتیم. هیچ درخواستی به سرورهای بیرونی ارسال نمی‌شد و کل صفحه فقط حدود ۳۰ کوئری دیتابیس داشت. پس مشکل نه از شبکه بود و نه از دیتابیس. نتیجه‌ی زمان‌سنجی callbackهای مرحله‌ی init:

Elementor و Yoast در هر درخواست صدها فایل PHP را بارگذاری می‌کنند. وقتی بررسی کردیم، OPcache این فایل‌ها را کش کرده بود. پس کامپایل مشکل نبود و چیزی در دسترسی به فایل‌ها کند بود.

قدم ۴: پیدا کردن مقصر واقعی

یک آزمایش ساده طراحی کردیم: بررسی وجود ۴۳۵ فایل افزونه‌ها، سه بار پشت سر هم، یک بار با تنظیمات معمول سایت و یک بار بدون تنظیم open_basedir:

بیش از ده برابر کندتر. open_basedir یک تنظیم امنیتی PHP است که اسکریپت‌ها را به پوشه‌های مشخصی محدود می‌کند. کنترل‌پنل‌هایی مثل Plesk آن را به‌صورت پیش‌فرض برای همه‌ی سایت‌ها فعال می‌کنند. وقتی این تنظیم فعال است، PHP باید مسیر هر فایل را هنگام هر دسترسی بررسی کند و کش مسیرها (realpath cache) عملاً استفاده نمی‌شود. برای سایتی که در هر درخواست صدها فایل بارگذاری می‌کند، این هزینه به چند ثانیه می‌رسد.

نتیجه

بعد از غیرفعال کردن open_basedir فقط برای این سایت:

آیا غیرفعال کردن open_basedir امن است؟

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

درس‌هایی که گرفتیم

1. بدون کش اندازه بگیرید. زمان پاسخ صفحه‌ی کش‌شده درباره‌ی سلامت سایت چیزی نمی‌گوید.
2. حدس نزنید، اندازه بگیرید. منطقی‌ترین فرضیه‌ی ما (OPcache) غلط بود.
3. تنظیمات پیش‌فرض کنترل‌پنل را بشناسید. تنظیمی که برای امنیت هزاران سایت طراحی شده، ممکن است برای سایت شما گران تمام شود.
4. هر تغییر را با بکاپ و امکان بازگشت انجام دهید. همه‌ی این مراحل روی سروری در حال کار انجام شد، بدون اینکه هیچ سایتی از دسترس خارج شود.

سایت شما هم کند است؟

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