مدیریت و نگهداری سرور
بهینه سازی سرعت سایت و سرور یعنی علت کندی را اندازه گیری کنیم و فقط همان بخش را اصلاح کنیم. از وب سرور و PHP تا دیتابیس، کش و تصاویر بررسی می شود و نتیجه با عدد قبل و بعد نشان داده می شود.
در یک نگاه
بهینه سازی سرعت یعنی اول اندازه بگیریم کجا کند است، بعد همان بخش را درست کنیم: تنظیم وب سرور و PHP، دیتابیس، کش، تصاویر یا CDN. بدون اندازه گیری قبل و بعد نمی شود فهمید تغییر اثر داشته است. تیم فنی پیکوهاست این کار را با گزارش انجام می دهد.
هر سطح همه ی کارهای سطح قبلی را دارد. قیمت دقیق بعد از بررسی نیاز و حجم کار اعلام می شود.
۱۰ کار انجام می شود
۲۲ کار انجام می شود
۳۰ کار انجام می شود
برای سایتی که یک گلوگاه مشخص دارد، مثل کش یا نسخه PHP نامناسب، و اصلاح اصول کافی است.
برای سایت یا فروشگاه فعال که کندی از چند لایه می آید و اندازه گیری قبل و بعد لازم دارد.
برای فروشگاه یا سرور پرترافیک روی VPS که علاوه بر تنظیمات، دیتابیس، کش شی و پایش ادامه دار می خواهد.
| کار | پایه | استاندارد | کامل |
|---|---|---|---|
| اندازه گیری | |||
| اندازه گیری TTFB و زمان بارگذاری | ✓ | ✓ | ✓ |
| بررسی صفحه اصلی، محصول و پیشخوان به عنوان صفحه شاخص | ✓ | ✓ | ✓ |
| بررسی مصرف منابع سرور در زمان کندی | - | ✓ | ✓ |
| استفاده از PageSpeed Insights و لاگ سرور | - | ✓ | ✓ |
| شناسایی گلوگاه اصلی بین PHP، دیتابیس و شبکه | - | ✓ | ✓ |
| وب سرور | |||
| بررسی نوع وب سرور و فعال سازی فشرده سازی | ✓ | ✓ | ✓ |
| فعال سازی کش مرورگر برای فایل های ایستا | ✓ | ✓ | ✓ |
| تست نحو پیکربندی وب سرور بعد از هر تغییر | - | ✓ | ✓ |
| PHP | |||
| انتخاب نسخه مناسب PHP | ✓ | ✓ | ✓ |
| فعال سازی OPcache | ✓ | ✓ | ✓ |
| تنظیم PHP-FPM یا LSAPI | - | ✓ | ✓ |
| دیتابیس | |||
| بررسی کوئری های کند | - | ✓ | ✓ |
| بررسی ایندکس ها | - | - | ✓ |
| بررسی تنظیمات MySQL یا MariaDB | - | - | ✓ |
| کش | |||
| راه اندازی کش صفحه | ✓ | ✓ | ✓ |
| بررسی تداخل کش با سبد خرید و صفحات کاربر | - | ✓ | ✓ |
| راه اندازی کش شی مثل Redis در صورت نیاز | - | - | ✓ |
| تصاویر و فایل ها | |||
| فشرده سازی تصاویر سنگین | ✓ | ✓ | ✓ |
| انتخاب فرمت مناسب تصاویر | - | ✓ | ✓ |
| کوچک سازی CSS و JS | - | ✓ | ✓ |
| تنظیم CDN برای فایل های ایستا در صورت مناسب بودن | - | - | ✓ |
| افزونه ها و قالب | |||
| شناسایی افزونه های سنگین | - | ✓ | ✓ |
| بررسی تاثیر افزونه ها بر زمان پاسخ | - | - | ✓ |
| گزارش | |||
| بکاپ از فایل کانفیگ پیش از هر تغییر | ✓ | ✓ | ✓ |
| گزارش عدد قبل و بعد | ✓ | ✓ | ✓ |
| اعمال تغییرات یکی یکی برای مشخص ماندن اثر هر کدام | - | ✓ | ✓ |
| فهرست تغییرات برای بازگشت | - | ✓ | ✓ |
| فهرست پیشنهادهایی که تصمیم شما را می خواهد | - | - | ✓ |
| پیشنهاد مانیتورینگ برای حفظ سرعت | - | - | ✓ |
| بررسی دوباره سرعت بعد از گذشت چند روز | - | - | ✓ |
بررسی LiteSpeed یا Apache یا Nginx، فعال سازی فشرده سازی و کش مرورگر
انتخاب نسخه مناسب، فعال سازی OPcache، تنظیم PHP-FPM یا LSAPI
بررسی کوئری های کند، ایندکس ها و تنظیمات MySQL یا MariaDB
کش صفحه، کش شی (مثل Redis در صورت نیاز)، کش مرورگر
فشرده سازی، فرمت مناسب، کوچک سازی CSS و JS
تنظیم CDN برای فایل های ایستا در صورت مناسب بودن
سرعت فعلی اندازه گیری می شود: TTFB، زمان بارگذاری، مصرف منابع و چند صفحه شاخص مثل صفحه اصلی، محصول و پیشخوان. ابزارهایی مثل PageSpeed Insights و لاگ سرور استفاده می شود.
گلوگاه اصلی پیدا می شود: پردازش PHP، دیتابیس، فایل های سنگین یا شبکه.
فهرست تغییرات پیشنهادی همراه با ریسک هر کدام برای شما فرستاده می شود.
بعد از بکاپ، تغییرات یکی یکی اعمال می شود تا اثر هر کدام مشخص بماند.
اندازه گیری تکرار می شود و عدد قبل و بعد در گزارش می آید.
برای ادامه، پیشنهاد مانیتورینگ و نگهداری داده می شود.
تحویل: تنظیمات اصلاح شده، گزارش اندازه گیری قبل و بعد، فهرست تغییرات برای بازگشت و پیشنهادهایی که نیاز به تصمیم شما دارند.
محدودیت ها: عدد مشخصی از بهبود را نمی توان از قبل قول داد، چون به علت کندی بستگی دارد. اگر کندی از کد قالب یا افزونه ای باشد، تغییر سرور آن را کامل حل نمی کند و باید خود افزونه یا کد اصلاح شود. سرعت بخش هایی مثل API های بیرونی یا سرویس های شخص ثالث هم در اختیار ما نیست. اگر سرور از نظر سخت افزار کم است، ارتقا پیشنهاد می شود و تقسیم بار با Nginx هم یک راه برای ترافیک بالا است.