تعمیر سرور بیش از حد بارگذاری شده

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

کیتی همپنیوس
Katie Hempenius

نمای کلی

این راهنما به شما نشان می دهد که چگونه یک سرور اضافه بار را در 4 مرحله تعمیر کنید:

  1. ارزیابی : گلوگاه سرور را تعیین کنید.
  2. تثبیت : برای کاهش تأثیر، راه‌حل‌های سریع را اجرا کنید.
  3. بهبود : افزایش و بهینه سازی قابلیت های سرور.
  4. مانیتور : از ابزارهای خودکار برای کمک به جلوگیری از مشکلات آینده استفاده کنید.

ارزیابی کنید

هنگامی که ترافیک سرور را بیش از حد بارگذاری می کند، یک یا چند مورد از موارد زیر می تواند به گلوگاه تبدیل شود: CPU، شبکه، حافظه یا ورودی/خروجی دیسک. شناسایی اینکه کدام یک از این گلوگاه ها هستند، تمرکز تلاش ها را بر روی تأثیرگذارترین اقدامات کاهش می دهد.

  • CPU: استفاده از CPU که به طور مداوم بیش از 80٪ است باید بررسی و رفع شود. عملکرد سرور اغلب زمانی که استفاده از CPU به 80-90% می رسد کاهش می یابد و با نزدیک شدن به 100% استفاده بیشتر مشخص می شود. استفاده از CPU برای ارائه یک درخواست ناچیز است، اما انجام این کار در مقیاسی که در هنگام افزایش ترافیک با آن مواجه می‌شویم، گاهی اوقات می‌تواند سرور را تحت تأثیر قرار دهد. بارگذاری سرویس به زیرساخت های دیگر، کاهش عملیات گران قیمت و محدود کردن تعداد درخواست ها، استفاده از CPU را کاهش می دهد.
  • شبکه: در دوره‌های پر ترافیک، توان عملیاتی شبکه مورد نیاز برای برآورده کردن درخواست‌های کاربر می‌تواند از ظرفیت فراتر رود. برخی از سایت‌ها، بسته به ارائه‌دهنده میزبانی، ممکن است در مورد انتقال داده‌های تجمعی نیز محدودیت داشته باشند. کاهش حجم و کمیت داده های منتقل شده به سرور و از آن، این تنگنا را برطرف می کند.
  • حافظه: هنگامی که یک سیستم حافظه کافی ندارد، داده ها باید برای ذخیره سازی روی دیسک بارگذاری شوند. دسترسی به دیسک بسیار کندتر از حافظه است و این می تواند کل برنامه را کندتر کند. اگر حافظه کاملاً تمام شود، می تواند منجر به خطاهای Out of Memory (OOM) شود. تنظیم تخصیص حافظه، رفع نشت حافظه و ارتقاء حافظه می تواند این تنگنا را برطرف کند.
  • ورودی/خروجی دیسک: سرعت خواندن یا نوشتن داده ها از دیسک توسط خود دیسک محدود می شود. اگر ورودی/خروجی دیسک یک گلوگاه است، افزایش مقدار داده های کش شده در حافظه می تواند این مشکل را کاهش دهد (به قیمت افزایش استفاده از حافظه). اگر این کار نکرد، ممکن است لازم باشد دیسک های خود را ارتقا دهید.

تکنیک‌های این راهنما بر رسیدگی به گلوگاه‌های CPU و شبکه تمرکز دارند. برای اکثر سایت ها، CPU و شبکه مرتبط ترین تنگناها در طول افزایش ترافیک خواهند بود.

اجرای top سرور آسیب‌دیده، محل شروع خوبی برای بررسی تنگناها است. اگر در دسترس است، این را با داده های تاریخی از ارائه دهنده هاست خود یا ابزار نظارت تکمیل کنید.

تثبیت کنید

یک سرور بیش از حد می تواند به سرعت منجر به خرابی های آبشاری در سایر نقاط سیستم شود. بنابراین، مهم است که سرور را قبل از تلاش برای ایجاد تغییرات مهم تر، تثبیت کنید.

محدود کردن نرخ

محدود کردن نرخ با محدود کردن تعداد درخواست‌های دریافتی از زیرساخت محافظت می‌کند. با کاهش عملکرد سرور، این امر به طور فزاینده ای اهمیت می یابد: با افزایش زمان پاسخ، کاربران تمایل دارند صفحه را به طور تهاجمی تازه کنند - بار سرور را حتی بیشتر افزایش می دهد.

رفع کنید

اگرچه رد درخواست نسبتاً ارزان است، بهترین راه برای محافظت از سرور شما این است که محدودیت نرخ را در جایی بالادست آن کنترل کنید - به عنوان مثال، از طریق یک متعادل کننده بار، پروکسی معکوس یا CDN.

دستورالعمل:

مطالعه بیشتر:

HTTP Caching

به دنبال راه هایی برای ذخیره سازی بیشتر محتوا در حافظه پنهان باشید. اگر منبعی را بتوان از یک کش HTTP (چه کش مرورگر یا یک CDN) ارائه کرد، پس نیازی به درخواست آن از سرور مبدا نیست، که بار سرور را کاهش می دهد.

سرصفحه‌های HTTP مانند Cache-Control ، Expires و ETag نشان می‌دهند که چگونه یک منبع باید توسط حافظه پنهان HTTP ذخیره شود. ممیزی و اصلاح این هدرها باعث بهبود حافظه پنهان می شود.

اگرچه سرویس‌کاران می‌توانند برای ذخیره‌سازی نیز استفاده شوند، اما از یک کش جداگانه استفاده می‌کنند و به جای جایگزینی، مکملی برای ذخیره‌سازی HTTP مناسب هستند. به همین دلیل، هنگام مدیریت یک سرور پربار، تلاش ها باید بر روی بهینه سازی کش HTTP متمرکز شود.

تشخیص دهید

Lighthouse را اجرا کنید و با یک حسابرسی سیاست کش کارآمد به دارایی‌های استاتیک خدمت نگاه کنید تا فهرستی از منابع را با مدت زمان کوتاه تا متوسط ​​(TTL) مشاهده کنید. برای هر منبع فهرست شده، در نظر بگیرید که آیا TTL باید افزایش یابد. به عنوان یک دستورالعمل تقریبی:

  • منابع استاتیک باید با TTL طولانی (1 سال) ذخیره شوند.
  • منابع پویا باید با یک TTL کوتاه (3 ساعت) ذخیره شوند.

رفع کنید

دستورالعمل max-age هدر Cache-Control را روی تعداد مناسب ثانیه تنظیم کنید.

دستورالعمل:

انحطاط برازنده

تخریب برازنده استراتژی کاهش موقت عملکرد به منظور تخلیه بار اضافی از یک سیستم است. این مفهوم را می توان به روش های مختلفی به کار برد: به عنوان مثال، ارائه یک صفحه متنی ثابت به جای یک برنامه کاربردی کامل، غیرفعال کردن جستجو یا بازگشت نتایج جستجوی کمتر، یا غیرفعال کردن برخی ویژگی های گران قیمت یا غیر ضروری. باید بر حذف قابلیت هایی که می توان به راحتی و ایمن با کمترین تأثیر تجاری حذف شوند، تأکید کرد.

بهبود بخشد

استفاده از شبکه تحویل محتوا (CDN)

دارایی‌های استاتیک را می‌توان از سرور شما به یک شبکه تحویل محتوا (CDN) بارگذاری کرد و در نتیجه بار را کاهش داد.

وظیفه اصلی CDN ارائه سریع محتوا به کاربران با ارائه شبکه بزرگی از سرورهایی است که در نزدیکی کاربران قرار دارند. با این حال، اکثر CDN ها ویژگی های مرتبط با عملکرد اضافی مانند فشرده سازی، متعادل سازی بار و بهینه سازی رسانه را نیز ارائه می دهند.

یک CDN راه اندازی کنید

CDN ها از مقیاس سود می برند، بنابراین کارکرد CDN خودتان به ندرت منطقی است. یک پیکربندی اولیه CDN نسبتاً سریع تنظیم می شود (حدود 30 دقیقه) و شامل به روز رسانی رکوردهای DNS برای اشاره به CDN است.

بهینه سازی استفاده از CDN

تشخیص دهید

با اجرای WebPageTest منابعی را که از CDN ارائه نمی شوند (اما باید ارائه شوند) شناسایی کنید. در صفحه نتایج، روی مربع بالای «استفاده مؤثر از CDN» کلیک کنید تا فهرست منابعی را که باید از CDN ارائه شوند، مشاهده کنید.