مقاله 09 / عملکرد وب‌سایت
افزایش سرعت وردپرس از سمت سرور؛ تشخیص گلوگاه پیش از ارتقا
مشخصات پیشنهادی انتشار
- عنوان سئو
- افزایش سرعت وردپرس از سمت سرور | نگهبان وب
- توضیح متا
- علت کندی وردپرس را پیش از ارتقای سرور پیدا کنید؛ نقش کش، PHP، دیتابیس، افزونه‌ها و تصاویر را با معیارهای مقایسه قبل و بعد بررسی کنید.
- مسیر پیشنهادی
- /blog/wordpress-server-performance
- عبارت اصلی
- افزایش سرعت وردپرس از سمت سرور
- تصویر
- wordpress-server-performance.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
کندی وردپرس همیشه با خرید سرور قوی‌تر حل نمی‌شود. گاهی تصویر بزرگ، افزونه سنگین، درخواست بیرونی یا query نامناسب عامل اصلی است. افزایش منابع بدون تشخیص می‌تواند هزینه را بیشتر کند و همان مشکل را در مقیاس بزرگ‌تر نگه دارد.
برای تصمیم درست باید صفحه عمومی، کاربر واردشده و مسیر خرید را جدا بررسی کنید. این مسیرها رفتار کش و پردازش یکسانی ندارند. نتیجه یک تست روی صفحه اصلی، تصویر کاملی از سرعت فروشگاه نمی‌دهد.
زمان رسیدن اولین بایت، زمان دریافت فایل‌ها و زمان آماده شدن تعامل صفحه را از هم جدا ببینید. TTFB فقط پردازش PHP نیست؛ شبکه، فاصله کاربر، اتصال و لایه‌های واسط هم روی آن اثر دارند. برای مقایسه، شرایط آزمون و وضعیت کش را ثابت نگه دارید.
سه مسیر نمونه انتخاب کنید: یک مقاله عمومی، یک صفحه محصول و مسیر سبد یا حساب کاربر. برای هرکدام حالت کش گرم و سرد، وضعیت ورود و موقعیت آزمون را ثبت کنید. بدون این اطلاعات، مقایسه «قبل و بعد» ممکن است صرفاً تفاوت شرایط باشد.
از شواهد به گلوگاه برسید
| نشانه | بررسی بعدی | تصمیم عجولانه‌ای که باید کنار گذاشت |
|---|---|---|
| صفحه عمومی سریع و حساب کاربر کند است | پردازش پویا، session و queryها | افزایش کلی منابع بدون بررسی مسیر |
| CPU هنگام درخواست‌ها اشباع می‌شود | PHP، افزونه و هم‌زمانی worker | زیاد کردن worker بدون سنجش حافظه |
| CPU پایین و پاسخ کند است | I/O، قفل دیتابیس و درخواست بیرونی | نتیجه‌گیری اینکه سرور سالم است |
| HTML سریع و نمایش صفحه کند است | تصویر، فونت و JavaScript | تعویض دیتابیس برای مشکل فرانت |
| کندی فقط در اوج ترافیک رخ می‌دهد | صف، ظرفیت و نرخ cache hit | تکیه بر تست تک‌درخواست |
برای تحلیل باید به داده همان بازه زمانی دسترسی داشته باشید. پایش سرویس و منابع ارتباط میان افزایش درخواست، خطا و مصرف منابع را روشن‌تر می‌کند.
کش را متناسب با نوع صفحه تنظیم کنید
کش کامل صفحه می‌تواند بار صفحات عمومی را کاهش دهد. اما سبد خرید، پرداخت، پنل کاربر و محتوای شخصی باید قواعد جدا داشته باشند. آزمون فقط با یک مرورگر کافی نیست؛ دو حساب یا دو نشست مستقل را بررسی کنید تا اطلاعات شخصی میان کاربران جابه‌جا نشود.
کش شیء، OPcache و کش صفحه وظایف یکسانی ندارند. فعال کردن چند لایه بدون شناخت ترتیب آن‌ها می‌تواند عیب‌یابی و حذف کش را سخت کند. برای هر لایه بنویسید چه چیزی ذخیره می‌کند، چه زمانی منقضی می‌شود و پس از تغییر محتوا چگونه پاک می‌شود.
ظرفیت PHP را با حافظه تطبیق دهید
تعداد worker بیشتر همیشه بهتر نیست. اگر هر worker حافظه قابل توجهی مصرف کند، هم‌زمانی زیاد می‌تواند فشار حافظه و جابه‌جایی روی دیسک ایجاد کند. اگر تعداد بسیار کم باشد، درخواست‌ها در صف می‌مانند. تنظیم باید با مصرف واقعی و رفتار ترافیک انجام شود.
نسخه PHP، سازگاری افزونه‌ها و تنظیمات اجرایی را با محیط آزمایشی بررسی کنید. تغییر چند گزینه هم‌زمان تشخیص اثر هرکدام را دشوار می‌کند. پس از هر تغییر، همان مسیرها و شاخص‌های قبلی را دوباره بسنجید.
دیتابیس و افزونه‌ها را جدا بررسی کنید
queryهای کند، قفل‌ها و حجم داده‌های خودکار بارگذاری‌شونده را بررسی کنید. افزونه گزارش‌گیری یا اتصال به سرویس بیرونی می‌تواند مسیر پاسخ را طولانی کند. خاموش کردن افزونه در سایت واقعی بدون شناخت نقش آن ممکن است فروش یا حسابداری را مختل کند؛ مقایسه را ابتدا در محیط مناسب انجام دهید.
پاک‌سازی دیتابیس باید با بکاپ قابل بازیابی و شناخت مالکیت جدول‌ها همراه باشد. حذف داده صرفاً براساس نام جدول یا توصیه عمومی خطرناک است. درباره داده سفارش، تراکنش و حساب کاربر حساسیت بیشتری لازم است.
تصویر و CDN را در جای درست استفاده کنید
تصویر را با ابعاد متناسب و قالب مناسب ارائه کنید و اندازه نمایشی را مشخص کنید. فایل‌های ثابت قابل کش را از مسیر مناسب برسانید. CDN فاصله دریافت برخی منابع را کاهش می‌دهد، اما مشکل query کند یا پردازش نامناسب در مبدأ را خودبه‌خود حل نمی‌کند.
در فروشگاه، تصاویر محصول باید کیفیت کافی داشته باشند و حجم آن‌ها نیز کنترل شود. اولویت بارگذاری تصویر اصلی و بارگذاری تنبل تصاویر پایین صفحه را بررسی کنید. تعداد درخواست‌ها، فونت‌های اضافی و کدهای شخص ثالث هم در تجربه نهایی سهم دارند.
برنامه بهبود را با عدد ببندید
یک تغییر مشخص، یک معیار موفقیت و یک روش برگشت تعریف کنید. مثلاً هدف کاهش زمان پاسخ مسیر محصول در شرایط آزمون ثابت باشد، نه صرف گرفتن نمره کامل ابزار. نتیجه آزمایشگاهی و تجربه کاربران واقعی را جدا گزارش کنید.
پرسش‌های رایج
آیا نصب Redis وردپرس را همیشه سریع می‌کند؟
خیر. اثر آن به پیکربندی کش شیء و گلوگاه واقعی بستگی دارد. ابزار جدید باید مسئله اندازه‌گیری‌شده‌ای را حل کند.
چه زمانی ارتقای سرور منطقی است؟
وقتی شواهد نشان دهد منابع موجود، پس از اصلاحات متناسب، پاسخ‌گوی بار موردنیاز نیستند. ابتدا محدودیت واقعی را مشخص کنید.
برای بررسی گلوگاه، درخواست بررسی عملکرد سرور ثبت کنید و مسیرهای کند، زمان شروع و آمار ترافیک در دسترس را بنویسید.
