نحوه تعیین گلوگاه سرور، رفع سریع گلوگاه، بهبود عملکرد سرور، و جلوگیری از پس‌رفت.
نمای کلی
این راهنما به شما نشان می‌دهد که چگونه یک سرور با بار اضافی را در ۴ مرحله رفع کنید:
- ارزیابی: گلوگاه سرور را تعیین کنید.
- تثبیت: پیاده‌سازی اصلاحات سریع برای کاهش تأثیر.
- بهبود: افزایش و بهینه‌سازی قابلیت‌های سرور.
- پایش: از ابزارهای خودکار برای کمک به جلوگیری از مشکلات آینده استفاده کنید.
ارزیابی
وقتی ترافیک بیش‌ازحد به سرور وارد می‌شود، یک یا چند مورد از موارد زیر می‌تواند به گلوگاه تبدیل شود: واحد پردازش مرکزی (CPU)، شبکه، حافظه، یا ورودی/خروجی دیسک. شناسایی اینکه کدام‌یک از این‌ها گلوگاه است، امکان تمرکز تلاش‌ها بر مؤثرترین روش‌های کاهش را فراهم می‌کند.
- واحد پردازش مرکزی: استفاده از واحد پردازش مرکزی که به‌طور مداوم بالای ۸۰٪ است باید بررسی و برطرف شود. عملکرد سرور اغلب زمانی کاهش می‌یابد که استفاده از CPU به حدود ۸۰ تا ۹۰ درصد برسد و با نزدیک شدن استفاده به ۱۰۰ درصد، این کاهش بیشتر نمایان می‌شود. استفاده از CPU برای ارائه یک درخواست ناچیز است، اما انجام این کار در مقیاسی که درطول افزایش ترافیک با آن مواجه می‌شویم، گاهی اوقات می‌تواند سرور را تحت‌الشعاع قرار دهد. انتقال بار سرویس‌دهی به زیرساخت‌های دیگر، کاهش عملیات پرهزینه، و محدود کردن تعداد درخواست‌ها باعث کاهش استفاده از واحد پردازش مرکزی می‌شود.
- شبکه: در دوره‌های ترافیک بالا، توان عملیاتی شبکه موردنیاز برای برآورده کردن درخواست‌های کاربر می‌تواند از ظرفیت فراتر رود. برخی‌از سایت‌ها، بسته به ارائه‌دهنده خدمات میزبانی وب، ممکن است به سقف انتقال داده تجمعی برسند. کاهش اندازه و مقدار داده‌های منتقل‌شده به سرور و از سرور این گلوگاه را برطرف خواهد کرد.
- حافظه: وقتی سیستم حافظه کافی نداشته باشد، داده‌ها باید برای ذخیره‌سازی به دیسک منتقل شوند. دسترسی به دیسک به‌طور قابل‌توجهی کندتر از حافظه است و این می‌تواند کل برنامه را کند کند. اگر حافظه کاملاً تمام شود، می‌تواند منجر به خطاهای کمبود حافظه (OOM) شود. تنظیم تخصیص حافظه، رفع نشت حافظه، و ارتقای حافظه می‌تواند این گلوگاه را برطرف کند.
- ورودی/خروجی دیسک: نرخی که داده‌ها می‌توانند از دیسک خوانده یا روی آن نوشته شوند توسط خود دیسک محدود می‌شود. اگر ورودی/خروجی دیسک گلوگاه باشد، افزایش مقدار داده‌های ذخیره‌شده در حافظه پنهان می‌تواند این مشکل را کاهش دهد (به قیمت افزایش استفاده از حافظه). اگر این کار مؤثر نبود، ممکن است لازم باشد دیسک‌هایتان را ارتقا دهید.
تکنیک‌های این راهنما بر رفع گلوگاه‌های CPU و شبکه تمرکز دارند. برای اکثر سایت‌ها، CPU و شبکه مربوط‌ترین گلوگاه‌ها درطول افزایش ترافیک خواهند بود.
اجرای top در سرور تحت‌تأثیر قرارگرفته نقطه شروع خوبی برای بررسی گلوگاه‌ها است. درصورت دردسترس بودن، این داده‌ها را با داده‌های سابقه از ارائه‌کننده خدمات میزبانی وب یا ابزار نظارت تکمیل کنید.
لرزش‌گیری
سروری که بار اضافی دارد می‌تواند به‌سرعت به خرابی‌های آبشاری در جاهای دیگر سیستم منجر شود. بنابراین، مهم است که قبل‌از تلاش برای ایجاد تغییرات مهم‌تر، سرور را تثبیت کنید.
محدودیت نرخ
محدود کردن نرخ با محدود کردن تعداد درخواست‌های ورودی از زیرساخت محافظت می‌کند. این موضوع با کاهش عملکرد سرور اهمیت بیشتری پیدا می‌کند: با افزایش زمان پاسخ، کاربران تمایل دارند صفحه را به‌طور تهاجمی بازآوری کنند - که بار سرور را حتی بیشتر افزایش می‌دهد.
رفع اشکال
اگرچه رد کردن درخواست نسبتاً کم‌هزینه است، بهترین راه برای محافظت از سرور این است که محدودیت نرخ را در جایی بالادست آن مدیریت کنید - برای مثال، ازطریق متعادل‌کننده بار، پراکسی معکوس، یا CDN.
دستورالعمل‌ها:
مطالعه بیشتر:
ذخیره‌سازی HTTP در حافظه نهان
به‌دنبال راه‌هایی برای ذخیره تهاجمی‌تر محتوا در حافظه نهان باشید. اگر منبعی بتواند از حافظه پنهان HTTP (چه حافظه پنهان مرورگر باشد یا CDN) ارائه شود، دیگر نیازی به درخواست آن از سرور مبدأ نیست، که این امر بار سرور را کاهش می‌دهد.
سرایندهای HTTP مثل Cache-Control، Expires، و ETag نشان می‌دهند که یک منبع چگونه باید توسط حافظه نهان HTTP ذخیره شود. بازرسی و اصلاح این سرصفحه‌ها ذخیره‌سازی موقت را بهبود می‌بخشد.
اگرچه از عامل‌های خدماتی نیز می‌توان برای ذخیره‌سازی موقت استفاده کرد، آن‌ها از حافظه نهان جداگانه‌ای استفاده می‌کنند و به‌جای جایگزینی برای ذخیره‌سازی موقت HTTP مناسب، مکمل آن هستند. به همین دلیل، هنگام مدیریت سرور با بار اضافی، تلاش‌ها باید بر بهینه‌سازی حافظه پنهان HTTP متمرکز شود.
عیب‌یابی
Lighthouse را اجرا کنید و به ممیزی ارائه دارایی‌های ایستا با خط‌مشی حافظه نهان کارآمد نگاه کنید تا فهرستی از منابع با زمان بقای (TTL) کوتاه تا متوسط را مشاهده کنید. برای هر منبع فهرست‌شده، بررسی کنید که آیا TTL باید افزایش یابد یا نه. به‌عنوان یک دستورالعمل کلی:
- منابع ایستا باید با TTL طولانی (۱ سال) در حافظه پنهان ذخیره شوند.
- منابع پویا باید با TTL کوتاه (۳ ساعت) ذخیره شوند.
رفع اشکال
دستورالعمل max-age سرصفحه Cache-Control را روی تعداد ثانیه مناسب تنظیم کنید.
دستورالعمل‌ها:
تنزل متین
تنزل متین راهبردی است که در آن عملکرد به‌طور موقت کاهش می‌یابد تا بار اضافی از سیستم برداشته شود. این مفهوم را می‌توان به روش‌های مختلفی اعمال کرد: برای مثال، ارائه یک صفحه نوشتاری ایستا به‌جای یک برنامه با ویژگی‌های کامل، غیرفعال کردن جستجو یا برگرداندن نتایج جستجوی کمتر، یا غیرفعال کردن برخی ویژگی‌های پرهزینه یا غیرضروری. باید بر برداشتن عملکردهایی تأکید شود که می‌توان آن‌ها را به‌طور ایمن و آسان با حداقل تأثیر بر کسب‌وکار برداشت.
بهبود
استفاده از شبکه توزیع محتوا (CDN)
ارائه دارایی‌های ایستا را می‌توان از سرور شما به یک شبکه توزیع محتوا (CDN) منتقل کرد و درنتیجه بار را کاهش داد.
عملکرد اصلی CDN ارائه سریع محتوا به کاربران ازطریق فراهم کردن شبکه بزرگی از سرورها است که در نزدیکی کاربران قرار دارند. بااین‌حال، اکثر CDNها ویژگی‌های اضافی مرتبط با عملکرد مانند فشرده‌سازی، توازن بار، و بهینه‌سازی رسانه را نیز ارائه می‌دهند.
راه‌اندازی CDN
شبکه‌های توزیع محتوا از مقیاس بهره می‌برند، بنابراین راه‌اندازی شبکه توزیع محتوای خودتان به‌ندرت منطقی است. پیکربندی CDN پایه نسبتاً سریع راه‌اندازی می‌شود (حدود ۳۰ دقیقه) و شامل به‌روزرسانی گزارش‌های ساناد برای اشاره به CDN است.
بهینه‌سازی استفاده از CDN
عیب‌یابی
با اجرای WebPageTest، منابعی را که از CDN ارائه نمی‌شوند (اما باید ارائه شوند) شناسایی کنید. در صفحه نتایج، روی مربع بالای «استفاده مؤثر از CDN» کلیک کنید تا فهرست منابعی را که باید از CDN ارائه شوند ببینید.
رفع اشکال
اگر منبعی توسط CDN ذخیره نمی‌شود، بررسی کنید که شرایط زیر برآورده شده باشد:
- سرایند
Cache-Control: publicدارد. - دارای سرصفحه
Cache-Control: s-maxage،Cache-Control: max-age، یاExpiresاست. - این دستگاه دارای
Content-Length،Content-Range، یاTransfer-Encoding headerاست.
مقیاس‌بندی منابع محاسباتی
تصمیم برای مقیاس‌بندی منابع محاسباتی باید با دقت گرفته شود. اگرچه اغلب لازم است منابع محاسباتی مقیاس‌بندی شوند، انجام این کار پیش‌از موعد می‌تواند پیچیدگی معماری و هزینه‌های مالی غیرضروری ایجاد کند.
عیب‌یابی
زمان تا اولین بایت (TTFB) بالا می‌تواند نشانه‌ای از این باشد که سرور به ظرفیت خود نزدیک می‌شود. می‌توانید این اطلاعات را در ممیزی Lighthouse کاهش زمان پاسخ سرور (TTFB) پیدا کنید.
برای بررسی بیشتر، از ابزار پایش برای ارزیابی استفاده از واحد پردازش مرکزی استفاده کنید. اگر استفاده فعلی یا پیش‌بینی‌شده از CPU از ۸۰٪ فراتر رفت، باید به فکر افزایش سرورهایتان باشید.
رفع اشکال
افزودن متعادل‌کننده بار امکان توزیع ترافیک در چندین سرور را فراهم می‌کند. ترازکننده بار در جلوی استخری از سرورها قرار می‌گیرد و ترافیک را به سرور مناسب هدایت می‌کند. ارائه‌دهندگان ابری ترازکننده‌های بار خودشان را ارائه می‌دهند (GCP، AWS، Azure) یا می‌توانید ترازکننده بار خودتان را بااستفاده از HAProxy یا NGINX راه‌اندازی کنید. وقتی متعادل‌کننده بار در جای خود قرار گرفت، می‌توان سرورهای اضافی را اضافه کرد.
علاوه‌بر توازن بار، اکثر ارائه‌دهندگان ابری مقیاس‌بندی خودکار (GCP، AWS، Azure) را ارائه می‌دهند. مقیاس‌بندی خودکار در ارتباط با توازن بار کار می‌کند - مقیاس‌بندی خودکار به‌طور خودکار منابع محاسباتی را براساس تقاضا در یک زمان مشخص افزایش و کاهش می‌دهد. بااین‌حال، مقیاس‌بندی خودکار جادویی نیست - زمان می‌برد تا نمونه‌های جدید آنلاین شوند و نیاز به پیکربندی قابل‌توجهی دارد. به‌دلیل پیچیدگی بیشتری که مقیاس‌بندی خودکار به‌همراه دارد، ابتدا باید راه‌اندازی ساده‌تر مبتنی بر متعادل‌کننده بار درنظر گرفته شود.
فعال کردن فشرده‌سازی
منابع نوشتاری باید بااستفاده از gzip یا brotli فشرده شوند. Gzip می‌تواند حجم انتقال این منابع را تا حدود ۷۰٪ کاهش دهد.
عیب‌یابی
برای شناسایی منابعی که باید فشرده شوند، از ممیزی فعال کردن فشرده‌سازی نوشتار Lighthouse استفاده کنید.
رفع اشکال
با به‌روزرسانی پیکربندی سرور، فشرده‌سازی را فعال کنید. دستورالعمل‌ها:
بهینه‌سازی تصاویر و رسانه‌ها
تصاویر بخش عمده‌ای از اندازه فایل اکثر وب‌سایت‌ها را تشکیل می‌دهند؛ بهینه‌سازی تصاویر می‌تواند به‌سرعت و به‌طور قابل‌توجهی اندازه سایت را کاهش دهد.
عیب‌یابی
Lighthouse ممیزی‌های مختلفی دارد که بهینه‌سازی‌های احتمالی تصویر را پرچم‌گذاری می‌کند. به‌صورت جایگزین، استراتژی دیگر استفاده از DevTools برای شناسایی بزرگ‌ترین فایل‌های تصویری است - این تصاویر احتمالاً گزینه‌های خوبی برای بهینه‌سازی خواهند بود.
حسابرسی‌های Lighthouse مربوط:
- اندازه مناسب تصاویر
- به‌تعویق انداختن تصاویر خارج‌از صفحه
- کدبندی کارآمد تصاویر
- ارائه تصاویر در قالب‌های نسل بعدی
- استفاده از قالب‌های ویدیویی برای محتوای پویانمایی‌شده
گردش کار Chrome DevTools:
- گزارش فعالیت شبکه
- روی Img کلیک کنید تا منابع غیرتصویری را فیلتر کنید
- روی ستون اندازه کلیک کنید تا فایل‌های تصویری براساس اندازه مرتب شوند
رفع اشکال
اگر وقتتان کم است…
وقتتان را روی شناسایی تصاویر بزرگ و تصاویری که مکرراً بار می‌شوند و بهینه‌سازی دستی آن‌ها با ابزاری مثل Squoosh متمرکز کنید. نگاره‌های اصلی اغلب گزینه‌های خوبی برای بهینه‌سازی هستند.
این موارد را به یاد داشته باشید:
- اندازه: تصاویر نباید بزرگ‌تر از حد لازم باشند.
- فشرده‌سازی: به‌طور کلی، سطح کیفیت ۸۰-۸۵ تأثیر حداقلی بر کیفیت تصویر خواهد داشت و درعین‌حال اندازه فایل را ۳۰-۴۰٪ کاهش می‌دهد.
- قالب: برای عکس‌ها از JPEG به‌جای PNG استفاده کنید؛ برای محتوای پویانمایی‌شده از MP4 به‌جای GIF استفاده کنید.
اگر وقت بیشتری دارید…
اگر تصاویر بخش قابل‌توجهی از سایت شما را تشکیل می‌دهند، راه‌اندازی CDN تصویر را درنظر بگیرید. شبکه‌های توزیع محتوای تصویر برای ارائه و بهینه‌سازی تصاویر طراحی شده‌اند و ارائه تصویر را از سرور مبدأ بارگیری می‌کنند. راه‌اندازی CDN تصویر ساده است اما نیاز به به‌روزرسانی نشانی‌های وب تصویر موجود دارد تا به CDN تصویر اشاره کند.
مطالعه بیشتر:
کوچک کردن JS و CSS
کوچک‌سازی نویسه‌های غیرضروری را از جاوا اسکریپت و CSS برمی‌دارد.
عیب‌یابی
از ممیزی‌های Minify CSS و Minify JavaScript در Lighthouse برای شناسایی منابعی که نیاز به کوچک‌سازی دارند استفاده کنید.
رفع اشکال
اگر وقتتان محدود است، روی کوچک کردن جاوا اسکریپت تمرکز کنید. اکثر سایت‌ها جاوا اسکریپت بیشتری نسبت به CSS دارند، بنابراین این کار تأثیر بیشتری خواهد داشت.
ناظر
ابزارهای نظارت بر سرور، جمع‌آوری داده، داشبورد، و هشدار درباره عملکرد سرور را ارائه می‌دهند. استفاده از آن‌ها می‌تواند به جلوگیری و کاهش مشکلات عملکردی سرور در آینده کمک کند.
راه‌اندازی نظارت باید تا حد امکان ساده باشد. جمع‌آوری بیش‌ازحد داده‌ها و هشدار دادن هزینه‌هایی دارد: هرچه دامنه یا دفعات جمع‌آوری داده‌ها بیشتر باشد، جمع‌آوری و ذخیره آن گران‌تر است؛ هشدار بیش‌ازحد ناگزیر منجر به نادیده گرفتن صفحه‌ها می‌شود.
هشداردهی باید از سنجه‌هایی استفاده کند که به‌طور مداوم و دقیق مشکلات را شناسایی می‌کنند. زمان پاسخ سرور (تأخیر) سنجه‌ای است که به‌ویژه برای این کار بسیار خوب عمل می‌کند: طیف گسترده‌ای از مشکلات را شناسایی می‌کند و مستقیماً با تجربه کاربری مرتبط است. هشدار دادن براساس سنجه‌های سطح پایین‌تر مانند استفاده از CPU می‌تواند مکمل مفیدی باشد اما زیرمجموعه کوچک‌تری از مشکلات را شناسایی می‌کند. علاوه‌براین، هشدار باید براساس عملکرد مشاهده‌شده در انتهای نمودار (به‌عبارت دیگر صدک ۹۵ یا ۹۹) باشد، نه براساس میانگین‌ها. درغیراین‌صورت، میانگین‌ها به‌راحتی می‌توانند مشکلاتی را که بر همه کاربران تأثیر نمی‌گذارند پنهان کنند.
رفع اشکال
همه ارائه‌دهندگان اصلی ابری ابزار نظارت خودشان را ارائه می‌دهند (GCP، AWS، Azure). علاوه‌براین، Netdata جایگزین عالی رایگان و متن‌بازی است. صرف‌نظر از اینکه کدام ابزار را انتخاب می‌کنید، باید عامل پایش ابزار را در هر سروری که می‌خواهید پایش کنید نصب کنید. پس‌از تکمیل، حتماً هشداردهی را راه‌اندازی کنید.
دستورالعمل‌ها: