کانفیگ وب سرور Nginx – بخش اول

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

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

تغییرات Worker

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

فرآیندهای Worker

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

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

worker_processes auto;

1	worker_processes auto;

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

grep ^processor /proc/cpuinfo | wc -l

1	grep ^processor /proc/cpuinfo \| wc -l

اتصالات worker

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

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

ulimit -n

ulimit -n

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

65536

65536

علاوه بر این شما می توانید، از یک روش اطلاع رسانی رویداد I/O مقیاس پذیر به نام epoll استفاده کنید. با استفاده از این روش در واقع یک تریگر روی رویدادها قرار میدهید که به شما اطمینان می دهد فرآیند های I/O در بهترین سطح توانمندی در حال کار هستند.

حتما بخوانید! وب سرور Nginx چیست؟

و نهایتا، اگر می خواهید یک worker تمام اتصالات جدید را در یک لحظه بپذیرد از multi_accept استفاده کنید.

تابع events پس از پیکربندی باید این چنین باشد:

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

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;

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 به کمترین اندازه تعداد بایت خود برای ارسال برسد، به تعویق خواهد افتاد. عدد صفر برای این متغیر به تعویق انداختن انتقال را غیر فعال می کند.

حتما بخوانید! ارتقا نسخه php در سرور لینوکس و دایرکت ادمین

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;

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

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

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

وقفه ها

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

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

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

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

client_header_timeout 3m;

client_body_timeout 3m;

send_timeout 3m;

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

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

حتما بخوانید! کانفیگ وب سرور Nginx – بخش دوم

open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 5;
open_file_cache_errors off;

open_file_cache max=1000 inactive=20s;

open_file_cache_valid 30s;

open_file_cache_min_uses 5;

open_file_cache_errors off;

همچنین شما می توانید توسط یک موقعیت خاص اطلاعات را کش کنید. نگهداری اطلاعات در حافظه کش برای مدت طولانی سودمند است. به خصوص اگر فایل ها جزئی از یک سیستم مدیریت محتوا یا CMS باشند.

location ~* .(woff|eot|ttf|svg|mp4|webm|jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}

location ~* .(woff|eot|ttf|svg|mp4|webm|jpg|jpeg|png|gif|ico|css|js)$ {

expires 365d;

}

Gzip کردن محتوا

در مورد محتواهای ساده ی یک وب سایت، وب سرور Nginx می تواند از فشرده سازی Gzip استفاده کند، تا این محتوای فشرده شده را به کلاینت برساند. مرورگرهای وب امروزی، فشرده سازی Gzip را می پذیرند و این کار باعث می شود حجم محتوایی که به صورت متن ساده ارسال شده است به مقدار بسیار زیادی کاهش پیدا کند. لیستی که در زیر برای شما تهیه شده است، فهرست “امنی” از انواع محتوای قابل فشرده سازی است، حتما دقت داشته باشید فقط فشرده سازی آن دسته از انواعی را که در وب سایت شما استفاده شده است فعال کنید.

gzip on;
gzip_min_length 1000;
gzip_types: text/html application/x-javascript text/css application/javascript text/javascript text/plain text/xml application/json application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/xml font/eot font/opentype font/otf image/svg+xml image/vnd.microsoft.icon;
gzip_disable "MSIE [1-6]\.";

gzip on;

gzip_min_length 1000;

gzip_types: text/html application/x-javascript text/css application/javascript text/javascript text/plain text/xml application/json application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/xml font/eot font/opentype font/otf image/svg+xml image/vnd.microsoft.icon;

gzip_disable "MSIE [1-6]\.";

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

Tags: nginx

کانفیگ وب سرور Nginx – بخش اول