بهینه سازی وب سرور Nginx – بخش اول

چگونه وب سرور Nginx را تنظیم کنیم تا بهترین کارایی را داشته باشد

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

تغییرات Worker

آسان ترین کاری که برای بهبود کارایی این وب سرور می توانید انجام دهید ، تنظیم صحیح تعداد Worker  ها و تعداد اتصالات است.

فرآیند های Worker

در شرایطی که سایتی با ترافیک کم دارید و nginx، بانک اطلاعاتی و نرم افزار وب همگی روی یک سرور نصب هستند در فایل  /etc/nginx/nginx.conf، فرایند worker را اینگونه تنظیم کنید: worker_processes 1;

درمقابل اگر سایتی دارید که ترافیک آن بالاست یا 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 مقیاس پذیر به اسم  use 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 (حداکثر واحد انتقال) منهای 40 تا 60 بایت اولیه که برای هدر IP است.

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

اندازه بافر

در انتخاب اندازه برای بافر از ترفند ها استفاده کنید تا سودمندی آن را ببینید. اگر اندازه بافر ها خیلی کوچک باشد، سرور nginx نوشتن را در یک فایل موقت انجام خواهد داد. این کار میزان I/O دیسک را بیش از اندازه بالا می برد.

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

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

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  در کارت شبکه بافر کنید. حتما قبل ازین کار  از دفترچه راهنمای کارت شبکه برای یافتن بهترین مقدار برای این متغیر کمک بگیرید.

ادامه این آموزش را در بخش دوم و سوم سری مقالات بهینه سازی وب سرور Nginx دنبال کنید.