آموزش کانفیگ وب سرور NGINX

NGINX به خاطر داشتن دو قابلیت شهرت پیدا کرده است. اولین قابلیت عملکرد بالا در تعادل بار و دیگری کش محتوای ایستا و پویای صفحات وب است. قبلا در مقاله وب سرور NGINX  به معرفی این وب سرور پرداختیم. در این مقاله آموزش کانفیگ بهینه NGINX و تعیین بهترین روش بهبود کارایی در این وب سرور است. به طوری که بتوانید با سرعت بیشتری به کاربران نهایی خود سرویس دهی کنید.

تغییرات Worker

آسان ترین کاری که برای بهبود کارایی این وب سرور می توانید انجام دهید، تنظیم صحیح تعداد Worker ها و تعداد اتصالات است. زمانی که سایتی با ترافیک کم دارید و NGINX، دیتابیس و وب سایت همگی روی یک سرور نصب هستند در فایل  /etc/nginx/nginx.conf، فرایند worker را این گونه تنظیم کنید:  worker_processes ۱;

در مقابل اگر سایتی دارید که ترافیک آن بالاست یا Instance اختصاصی برای NGINX در نظر گرفته شده است، به هر هسته CPU یک worker اختصاص دهید:

worker_processes auto;

توصیه ما این است که این مقدار را دستی تنظیم کنید جهت یافتن تعداد فرآیند هایی که سرور می تواند همزمان اجرا کند از این دستور استفاده کنید:

grep ^processor /proc/cpuinfo | wc -l

اتصالات worker

بیشترین تعداد اتصالاتی که هر فرآیند worker در یک زمان می تواند پردازش کند با گزینه ی worker_connections  تنظیم می شود. مقدار پیش فرض اتصالات یک worker 512 تا است اما معمولا سیستم ها قدرت پردازش بیشتر از این مقدار را هم دارند.

بهترین عدد برای تعداد اتصالات یک worker را تنها با آزمایش کردن به دست می آورید چون بسته به نوع ترافیکی که سرور NGINX  به آن پاسخگویی می کند متغیر است. همچنین محدودیت های هسته سیستم با استفاده  از دستور ulimit نیز مشخص می شود:

ulimit -n

این دستور  در پاسخ یک عدد به شما بر می گرداند:

65536

علاوه بر این شما می توانید، از یک روش اطلاع رسانی رویداد I/O مقیاس پذیر به نام  epoll استفاده کنید. با استفاده از این روش در واقع یک تریگر روی رویدادها قرار میدهید که به شما اطمینان می دهد فرآیند های I/O در بهترین سطح توانمندی در حال کار هستند. و نهایتا، اگر می خواهید یک worker تمام اتصالات جدید را در یک لحظه بپذیرد از multi_accept استفاده کنید.
تابع events پس از پیکربندی باید این چنین باشد:

events {
worker_connections 66536;
use epoll;
multi_accept on;
}

بهینه سازی های TCP

Keep Alive

Keep alive اجازه اتصال مجدد را به مرورگرها می دهد.
keepalive_timeout  و keepalive_requests  کنترل تنظیمات keep alive را انجام می دهند.
sendfile بارگزاری فایل های ثابت از  فایل سیستم را بهینه سازی می کند، مثل لوگوی وب سایت ها
tcp_nodelay به سرور NGINX این اجازه را می دهد تا TCP بتواند چندین بافر را به عنوان بسته های مجزا ارسال کند.

tcp_nopush  مقدار اطلاعاتی را که در یک زمان با فعال سازی گزینه TCP_CORK در پشته ی TCP می توان به سیم فرستاد را بهینه سازی می کند.  کار TCP_CORK چیست؟ TCP_CORK هنگامی که ظرفیت یک بسته به حداکثر اندازه ی سگمنت برسد، اطلاعات را بلاک می کند. حال سوال دیگری مطرح می شود که حداکثر اندازه سگمنت چقدر است؟ MMS یا حداکثر اندازه سگمنت برابر است با  MTU (حداکثر واحد انتقال) منهای ۴۰ تا ۶۰ بایت اولیه که برای هدر IP است.

keepalive_timeout 65;
keepalive_requests 100000;
sendfile on;
tcp_nopush on;
tcp_nodelay on;

اندازه بافر

حافظه بافر به رابط حافظه ای بین دو تا دستگاه و یا سخت افزار هست. بافر برای این استفاده میشه تا تفاوت سرعت بین دو قطعه را جبران کند. اگر اندازه بافر ها خیلی کوچک باشد، سرور NGINX نوشتن را در یک فایل موقت انجام خواهد داد. این کار میزان I/O دیسک را بیش از اندازه بالا می برد.

client_body_buffer_size اندازه ی بافر کلاینت را مدیریت می کند. بیشترین بافرهای کلاینت از روش POST از ارسال ها می آیند. معمولا بهترین انتخاب برای مقداردهی به  این متغیر ۱۲۸ کیلو بایت است.

client_max_body_size حداکثر اندازه بافر بدنه را تنظیم می کند. اگر اندازه در یک درخواست از عددی که ما تنظیم کردیم تجاوز کند، خطای ۴۱۳ ( مقدار مورد درخواست بسیار بزرگ است ) به سمت کلاینت بازگردانده می شود. معمولا مرورگرها نمی توانند خطاهای شماره ۴۱۳ را به درستی نمایش دهند. اگر به این متغیر مقدار صفر بدهید، امکان چک کردن اندازه بدنه درخواست غیر فعال می شود.

client_header_buffer_size  اندازه هدر کلاینت را مدیریت می کند. معمولا یک کیلوبایت یک انتخاب درست برای این متغیر است که به عنوان مقدار پیش فرض هم در نظر گرفته شده است.

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

output_buffers تعداد و اندازه ی بافرهایی که برای خواندن یک پاسخ از دیسک استفاده می شود را تنظیم می کند.  در صورت امکان، انتقال اطلاعات کلاینت تا زمانی که سرور NGINX به کمترین اندازه تعداد بایت خود برای ارسال برسد، به تعویق خواهد افتاد. عدد صفر برای این متغیر به تعویق انداختن انتقال را غیر فعال می کند.

client_body_buffer_size      128k;
client_max_body_size         10m;
client_header_buffer_size    1k;
large_client_header_buffers  4 4k;
output_buffers               1 32k;
postpone_output              1460;

صف اتصال

برخی دستورات در فایل /etc/sysctl.conf برای این که بتوانید اندازه ی صف لینوکس را برای اتصالات و بسته ها تغییر دهید در اختیار شما قرار داده شده است. به روز رسانی net.core.somaxconn و net.ipv4.tcp_max_tw_buckets اندازه صف اتصالاتی را که منتظر پذیرفته شدن از سمت سرور NGINX هستند را تغییر می دهد. اگر روی هسته لاگ به خطا برخورد کردید اینقدر این مقدار را افزایش دهید تا خطا متوقف شود.

net.core.somaxconn = 65536
net.ipv4.tcp_max_tw_buckets = 1440000

شما به عنوان یک مدیر سرور می توانید با تنظیم max backlog، بسته ها را قبل از پردازش توسط CPU با استفاده از تگ net.core.netdev_max_backlog  در کارت شبکه بافر کنید.

حتما قبل از این کار از دفترچه راهنمای کارت شبکه برای یافتن بهترین مقدار برای این متغیر کمک بگیرید.

وقفه ها

وقفه ها نیز شدیدا در افزایش کارایی وب سرور موثر هستند.

client_header_timeout زمانی که یک سرور منتظر است تا هدر یک بدنه ارسال شود، دستورات را می فرستد. این دستورات مسئول کنترل زمان هستند، شاید این سوال برای شما هم پیش آمده است که این دستورات دقیقا چه زمانی را کنترل می کنند؟ زمانی که که یک سرور بعد از دریافت یک درخواست باید برای یک بدنه کلاینت یا هدر کلاینت منتظر بماند تا ارسال شوند.  اگر نه بدنه و نه هدر هیچ یک ارسال نشوند ، سرور به خطای ۴۰۸ یا “Request time out” بر می خورد.client_body_timeout زمانی که یک سرور منتظر است تا یک بدنه ارسال شود، دستورات را می فرستد.
send_timeout وقفه پاسخ را به کلاینت اختصاص می دهد. این وقفه روی تمامی انتقالات اعمال نمی شود، اما ترجیحا، تنها بین عمل خواندن  دو -کلاینت بعدی اعمال می شود. بنابراین، اگر کلاینت در این بازه زمانی، هیچ داده ای را نخواند، وب سرور NGINX اتصال را قطع می کند.

client_header_timeout  3m;
client_body_timeout    3m;
send_timeout           3m;

نگهداری محتوای ثابت وب سایت

اگر وب سایت شما دارای محتوای ثابت مثل کد های CSS، جاوا اسکریپت یا تصاویر است، وب سرور NGINX می تواند این فایل ها را برای بازه زمانی کوتاهی در حافظه کش نگهداری کند. اگر قطعه کدی که در زیر مشاهده می کنید را به تنظیمات NGINX اضافه کنید به وب سرور خود دستور می دهید که برای مدت  ۳۰ ثانیه ۱۰۰۰ فایل را در حافظه کش نگهداری کند، فایل هایی را که در مدت ۲۰ ثانیه پیاپی هیچ دسترسی به آنها انجام نشود را از حافظه کش خود بیرون بگزارد و تنها فایل هایی را نگهداری کند که حداقل ۵  بار در این ۳۰ ثانیه مورد درخواست قرار بگیرند.  اگر محتوای سایت خود را مرتبا تغییر نمی دهید می توانید این اعداد را بالاتر انتخاب کنید.