وضعیت سرورها

وبــلاگ

وضعیت سرورها
  • بهینه سازی وب سرور Nginx – بخش اول

    شریفی پویا شنبه ۲۵ دی ۱۳۹۵ امنیت , لینوکس , مقالات

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

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

     

     

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

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

    تغییرات Worker

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

    فرآیند های Worker

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

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

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

    اتصالات worker

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

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

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

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

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

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

     

     

    بهینه سازی های 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 است.

    اندازه بافر

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

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

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

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

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

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

    صف اتصال

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

     

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

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

    0

    برچسب ها :

با عضویت در خبرنامه شما را از آخرین تجربیات مان و مطالب تخصصی آگاه خواهیم کرد.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *