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

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

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.

دستورالعمل ها:

• NGINX
• HAProxy
• مایکروسافت IIS

بیشتر خواندن:

• استراتژی ها و تکنیک های محدود کننده نرخ

HTTP Caching

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

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

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

تشخیص دادن

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

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

ثابت

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

دستورالعمل ها:

• NGINX
• آپاچی
• مایکروسافت

افت شدید

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

بهتر کردن

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

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

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

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

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

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

تشخیص دادن

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

ثابت

اگر منبعی توسط CDN کش نمی شود، بررسی کنید که شرایط زیر برآورده شده است:

• دارای یک هدر Cache-Control: public .
• دارای یک Cache-Control: s-maxage ، Cache-Control: max-age یا Expires header است.
• دارای هدر Content-Length ، Content-Range یا Transfer-Encoding header است.

مقیاس منابع محاسباتی

تصمیم برای مقیاس کردن منابع محاسبه باید با دقت گرفته شود. اگر چه اغلب لازم است که منابع محاسباتی را مقیاس بندی کنیم، انجام این کار پیش از موعد می تواند پیچیدگی معماری و هزینه های مالی غیرضروری ایجاد کند.

تشخیص دادن

زمان بالا برای اولین بایت (TTFB) می تواند نشانه ای از نزدیک شدن ظرفیت سرور باشد. شما می توانید این اطلاعات را در ممیزی زمان پاسخ سرور Lighthouse Reduce (TTFB) بیابید.

برای بررسی بیشتر، از یک ابزار نظارت برای ارزیابی استفاده از CPU استفاده کنید. اگر مصرف فعلی یا پیش بینی شده CPU بیش از 80٪ باشد، باید سرورهای خود را افزایش دهید.

ثابت

اضافه کردن یک متعادل کننده بار توزیع ترافیک را در چندین سرور امکان پذیر می کند. یک بار متعادل کننده در مقابل مجموعه ای از سرورها قرار دارد و ترافیک را به سمت سرور مناسب هدایت می کند. ارائه دهندگان Cloud متعادل کننده های بار خود را ارائه می دهند ( GCP ، AWS ، Azure ) یا می توانید با استفاده از HAProxy یا NGINX خودتان را راه اندازی کنید. هنگامی که یک متعادل کننده بار در محل قرار گرفت، سرورهای اضافی را می توان اضافه کرد.

علاوه بر تعادل بار، اکثر ارائه دهندگان ابر مقیاس خودکار ( GCP ، AWS ، Azure ) را ارائه می دهند. مقیاس خودکار در ارتباط با تعادل بار کار می کند - مقیاس خودکار به طور خودکار منابع محاسبه را در زمان معین افزایش و کاهش می دهد. همانطور که گفته شد، مقیاس خودکار جادویی نیست - زمان می برد تا نمونه های جدید آنلاین شوند و به پیکربندی قابل توجهی نیاز دارد. به دلیل پیچیدگی اضافی که مقیاس خودکار مستلزم آن است، ابتدا باید یک راه اندازی ساده تر مبتنی بر متعادل کننده بار در نظر گرفته شود.

فعال سازی فشرده سازی

منابع متنی باید با استفاده از gzip یا brotli فشرده شوند. Gzip می تواند حجم انتقال این منابع را تا 70% کاهش دهد.

تشخیص دادن

از ممیزی فشرده سازی متن Lighthouse Enable برای شناسایی منابعی که باید فشرده شوند استفاده کنید.

ثابت

فشرده سازی را با به روز رسانی پیکربندی سرور خود فعال کنید. دستورالعمل ها:

• NGINX
• آپاچی
• مایکروسافت

بهینه سازی تصاویر و رسانه ها

تصاویر اکثر حجم فایل اکثر وب سایت ها را تشکیل می دهند . بهینه سازی تصاویر می تواند به سرعت و به میزان قابل توجهی اندازه سایت را کاهش دهد.

تشخیص دادن

Lighthouse دارای انواع ممیزی است که بهینه سازی تصویر بالقوه را نشان می دهد. روش دیگر، استراتژی دیگر استفاده از DevTools برای شناسایی بزرگترین فایل های تصویری است - این تصاویر احتمالاً نامزدهای خوبی برای بهینه سازی خواهند بود.

ممیزی های مربوط به فانوس دریایی:

• اندازه مناسب تصاویر
• به تعویق انداختن تصاویر خارج از صفحه
• رمزگذاری کارآمد تصاویر
• تصاویر را در قالب های نسل بعدی ارائه دهید
• از فرمت های ویدئویی برای محتوای متحرک استفاده کنید

گردش کار Chrome DevTools:

• ثبت فعالیت شبکه
• برای فیلتر کردن منابع غیرتصویری، روی Img کلیک کنید
• روی ستون Size کلیک کنید تا فایل های تصویری بر اساس اندازه مرتب شوند

ثابت

اگر زمان محدودی دارید…

وقت خود را بر روی شناسایی تصاویر بزرگ و مکرر و بهینه سازی دستی آنها با ابزاری مانند Squoosh متمرکز کنید. تصاویر قهرمان اغلب نامزدهای خوبی برای بهینه سازی هستند.

مواردی که باید در نظر داشت:

• اندازه: تصاویر نباید بزرگتر از حد لازم باشند.
• فشرده سازی: به طور کلی، سطح کیفی 80-85 کمترین تأثیر را بر کیفیت تصویر خواهد داشت در حالی که باعث کاهش 30-40٪ در اندازه فایل می شود.
• فرمت: از JPEG برای عکس ها به جای PNG استفاده کنید. از MP4 برای محتوای متحرک به جای GIF استفاده کنید.

اگر زمان بیشتری دارید…

اگر تصاویر بخش قابل توجهی از سایت شما را تشکیل می دهند، یک CDN تصویر راه اندازی کنید. CDN های تصویر برای سرویس دهی و بهینه سازی تصاویر طراحی شده اند و سرویس تصویر را از سرور مبدا بارگذاری می کنند. راه اندازی یک CDN تصویر ساده است اما نیاز به به روز رسانی URL های تصویر موجود برای اشاره به CDN تصویر دارد.

بیشتر خواندن:

• از CDN های تصویر برای بهینه سازی تصاویر استفاده کنید
• تصاویر.راهنما

JS و CSS را کوچک کنید

Minification کاراکترهای غیر ضروری را از جاوا اسکریپت و CSS حذف می کند.

تشخیص دادن

از ممیزی های Minify CSS و Minify JavaScript Lighthouse برای شناسایی منابعی که نیاز به کوچک سازی دارند استفاده کنید.

ثابت

اگر زمان محدودی دارید، روی کوچک کردن جاوا اسکریپت خود تمرکز کنید. اکثر سایت‌ها جاوا اسکریپت بیشتری نسبت به CSS دارند، بنابراین تأثیرگذاری بیشتری خواهد داشت.

• جاوا اسکریپت را کوچک کنید
• CSS را کوچک کنید

نظارت کنید

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

تنظیم نظارت باید تا حد امکان ساده باشد. جمع آوری و هشدار بیش از حد داده ها هزینه های خود را دارد: هر چه دامنه یا فراوانی جمع آوری داده ها بیشتر باشد، جمع آوری و ذخیره آن هزینه بیشتری دارد. هشدار بیش از حد به ناچار منجر به نادیده گرفته شدن صفحات می شود.

هشدار باید از معیارهایی استفاده کند که به طور مداوم و دقیق مشکلات را تشخیص دهد. زمان پاسخ سرور (تأخیر) معیاری است که به ویژه برای این کار خوب عمل می کند: طیف گسترده ای از مسائل را می گیرد و مستقیماً با تجربه کاربر مرتبط است. هشدار بر اساس معیارهای سطح پایین تر مانند استفاده از CPU می تواند مکمل مفیدی باشد اما زیرمجموعه کوچک تری از مشکلات را به دنبال خواهد داشت. علاوه بر این، هشدار باید بر اساس عملکرد مشاهده شده در دم (به عبارت دیگر صدک های 95 یا 99)، به جای میانگین ها باشد. در غیر این صورت، میانگین ها به راحتی می توانند مسائلی را که همه کاربران را تحت تاثیر قرار نمی دهند، پنهان کنند.

ثابت

همه ارائه دهندگان ابر اصلی ابزار نظارتی خود را ارائه می دهند ( GCP ، AWS ، Azure ). علاوه بر این، Netdata یک جایگزین عالی رایگان و منبع باز است. صرف نظر از اینکه کدام ابزار را انتخاب می کنید، باید عامل نظارت ابزار را روی هر سروری که می خواهید نظارت کنید نصب کنید. پس از تکمیل، مطمئن شوید که هشدار را تنظیم کرده اید.

دستورالعمل ها:

• GCP
• AWS
• لاجوردی
• داده های شبکه