کانفیگ Nginx جهت بهبود عملکرد

NGINX به عنوان یک بالانس عملکرد بالا ، حافظه پنهان و سرور وب شناخته شده است و بیش از 40 درصد از سایت های پرجمعیت جهان را تأمین می کند. برای اغلب موارد استفاده، تنظیمات پیش فرض NGINX و لینوکس به خوبی کار می کنند، اما دستیابی به عملکرد مطلوب گاهی اوقات نیاز به کمی تنظیم دارد. این پست وبلاگ در مورد برخی از تنظیمات NGINX و لینوکس در هنگام تنظیم یک سیستم بحث می کند.

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

کانفیگ Nginx جهت بهبود عملکرد

کانفیگ Nginx جهت بهبود عملکرد

معرفی

درک اولیه معماری NGINX و مفاهیم پیکربندی فرض شده است. این پست تلاش نمی کند مستندات NGINX را کپی کند، اما یک مرور کلی از گزینه های مختلف و پیوندهایی به مستندات مربوطه را ارائه می دهد.

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

ما با بحث در مورد تنظیمات لینوکس شروع می کنیم، زیرا ارزش برخی از تنظیمات سیستم عامل تعیین نحوه تنظیم پیکربندی NGINX شما را تعیین می کند.

تنظیم پیکربندی لینوکس شما

تنظیمات در هسته های مدرن لینوکس (2.6+) برای اکثر اهداف مناسب هستند، اما تغییر برخی از آنها می تواند سودمند باشد. ورودی هسته را برای پیام های خطا نشان می دهد که یک تنظیم بسیار کم است و تنظیم آن را به عنوان توصیه می شود. در اینجا ما فقط آن تنظیمات را پوشش می دهیم که احتمالا از تنظیم در کارهای معمول استفاده می کنند. برای جزئیات بیشتر درباره تنظیم این تنظیمات، لطفا به اسناد لینوکس خود مراجعه کنید.

صف Backlog

تنظیمات زیر مربوط به اتصالات و نحوه آنها هستند. اگر میزان بالای اتصالات ورودی را بالا ببرید و سطوح عملکرد نامنظم (به عنوان مثال بعضی از اتصالات ظاهرا خاموش می شوند)، تغییر تنظیمات می تواند کمک کند.

  • net.core.somaxconn– حداکثر تعداد اتصالات که می تواند برای پذیرش NGINX باشد. پیش فرض معمولا بسیار کم است و معمولا قابل قبول است، زیرا NGINX ارتباطات را بسیار سریع می پذیرد، اما اگر وب سایت شما ترافیک سنگین را تجربه کند، ارزش آن را افزایش می دهد. اگر پیام های خطا در ورودی هسته نشان می دهد که مقدار خیلی کوچک است، آن را افزایش دهید تا خطاهای متوقف شوند.توجه: اگر این مقدار را به مقدار بیش از 512 تنظیم کنید، backlogپارامتر را به listenدستورالعمل NGINX تغییر دهید .
  • net.core.netdev_max_backlog– میزان که در آن بسته ها توسط کارت شبکه قبل از اینکه به پردازنده منتقل شوند، توسط کارت شبکه ذخیره می شوند. افزایش ارزش می تواند عملکرد در ماشین آلات با مقدار زیادی از پهنای باند را بهبود بخشد. ورودی کرنل را برای خطاهای مربوط به این تنظیم بررسی کنید و با مشاوره در مورد تغییر آن به مستندات کارت شبکه مراجعه کنید.

توصیفگرهای فایل

توصیفگرهای فایل ها منابع سیستم عامل هستند که برای نمایش اتصالات و باز کردن فایل ها، از جمله چیزهای دیگر استفاده می شود. NGINX می تواند به دو توصیفگر فایل در هر اتصال استفاده کند. به عنوان مثال، اگر NGINX پروکسی باشد، به طور کلی از یک توصیفگر فایل برای اتصال به سرویس گیرنده استفاده می کند و دیگری برای اتصال به سرور پروکسی، هر چند این نسبت بسیار پایین تر از HTTP استفاده می کند. برای یک سیستم که تعداد زیادی از اتصالات را در اختیار دارد، ممکن است تنظیمات زیر تنظیم شود:

  • sys.fs.file-max – محدودیت سیستم برای توصیفگرهای فایل
  • nofile– محدودیت توصیفگر فایل کاربر، در فایل /etc/security/limits.conf تنظیم شده است

بنادر کوتاه مدت

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

  • net.ipv4.ip_local_port_range– شروع و پایان دامنه ارزش های پورت اگر می بینید که از پورت ها خارج می شوید، محدوده را افزایش دهید. یک پورت معمولی پورت های 1024 تا 65000 است.

تنظیم تنظیمات NGINX شما

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

فرآیندهای کارگری

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

  • worker_processes– تعداد فرآیندهای NGINX کارگر (پیش فرض 1 است). در اغلب موارد، اجرای یک فرایند کارگر در هر هسته CPU به خوبی کار می کند و توصیه می کنیم این دستورالعمل را autoبرای رسیدن به آن تنظیم کنید. زمان هایی وجود دارد که ممکن است بخواهید این تعداد را افزایش دهید، مانند زمانی که فرآیندهای کارگر باید مقدار زیادی از I / O دیسک را انجام دهند.
  • worker_connections– حداکثر تعداد اتصالات که هر پردازش کارگر می تواند به طور همزمان اداره کند. به طور پیش فرض 512 است، اما اکثر سیستم ها منابع کافی برای پشتیبانی از تعداد بیشتری دارند. تنظیم مناسب بستگی به اندازه سرور و ماهیت ترافیک دارد و می تواند از طریق تست کشف شود.

اتصالات نگهدارنده

اتصالات نگهدارنده میتوانند با کاهش CPU و سربارهای شبکه مورد نیاز برای باز کردن و بستن اتصالات، بر عملکرد تاثیر مهمی داشته باشند. NGINX تمام اتصالات سرویس گیرنده را متوقف می کند و ارتباطات جداگانه و مستقل را به سرورهای بالادست ایجاد می کند. NGINX از keepalives برای مشتریان و سرورهای بالادست پشتیبانی می کند. دستورالعمل های زیر مربوط به نگهداری مشتری هستند:

  • keepalive_requests– تعداد درخواست های مشتری می تواند بیش از یک اتصال continuousalive را انجام دهد. به طور پیش فرض 100 است، اما مقدار بسیار بالایی می تواند برای آزمایش با یک ابزار نسل بار استفاده شود که به طور کلی تعداد زیادی درخواست از یک مشتری را می فرستد.
  • keepalive_timeout – مدت زمانی که یک اتصال پایدار باقی می ماند باز است

دستور زیر مربوط به نگهدارنده های بالادست می باشد:

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

برای فعال کردن اتصالات keepalive به سرورهای بالادست، شما همچنین باید دستورالعمل های زیر را در تنظیمات ذکر کنید:

proxy_http_version 1.1;
proxy_set_header Connection "";

ورود به سیستم

ثبت هر درخواست هر دو CPU و I / O cycles را مصرف می کند و یکی از راه های کاهش تاثیر آن این است که فعال کردن بافر دسترسی دسترسی داشته باشید. با بافر کردن، به جای انجام یک عملیات نوشتن جداگانه برای هر ورود ورود، NGINX بافر یک سری از نوشته ها و آنها را به یک فایل با هم در یک عملیات واحد می نویسد.

برای فعال کردن بافر دسترسی دسترسی، شامل پارامتر به دستور؛ NGINX محتویات بافر را به log وارد می کند وقتی که بافر به مقدار می رسد . برای اینکه NGINX بعد از یک مقدار معین زمان بافر را بنویسد، شامل پارامتر است. هنگامی که هر دو پارامتر تنظیم می شوند، NGINX در صورت ورود ورودی بعدی به بافر یا نوشته های در بافر بزرگتر از زمان مشخص، NGINX می نویسد. نوشته های ورود نیز زمانی نوشته شده است که یک فرآیند کارگر مجددا باز کردن فایل های ورودی خود را یا خاموش کردن. برای غیر فعال کردن ورود به سیستم به طور کامل، شامل پارامتر به دستور.buffer=sizeaccess_logsizeflush=timeoffaccess_log

ارسال فایل

سیستم سیستم عامل، sendfile()اطلاعات را از یک توصیفگر فایل به یک دیگر کپی می کند، اغلب به صفر کپی می رسد، که می تواند انتقال داده های TCP را سریعتر کند. برای فعال کردن NGINX برای استفاده از آن، sendfileدستورالعمل را در httpcontext serverیا locationcontext یا context قرار دهید. سپس NGINX می تواند محتوای cached یا روی دیسک را درون یک سوکت بدون هیچ تغییری در زمینه فضای کاربر نوشت و نوشتن بسیار سریع و مصرف چرخه CPU کمتری را به همراه داشت. توجه داشته باشید، با این حال، به دلیل اینکه داده های کپی شده با sendfile()عبور از فضای کاربر کپی می شوند، این موضوع به زنجیره پردازش NGINX معمولی و فیلترهایی که محتوای را تغییر می دهند مانند gzip. هنگامی که یک زمینه پیکربندی شامل هر دو sendfileدستورالعمل و دستورالعمل هایی است که یک فیلتر تغییر محتوا را فعال می کنند، NGINX به طور خودکار غیرفعال می شودsendfile برای آن زمینه

محدودیت ها

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

  • limit_connو limit_conn_zone– محدود کردن تعداد اتصالات مشتری NGINX قبول می کند، به عنوان مثال از یک آدرس IP منحصر به فرد. تنظیم آنها می تواند به جلوگیری از دسترسی مشتریان مختلف به باز کردن ارتباطات بیش از حد و مصرف بیش از سهم خود از منابع کمک کند.
  • limit_rate– محدودیت میزان پاسخ هایی که به مشتری داده می شود، در هر اتصال (بنابراین مشتریانی که اتصالات چندگانه را باز می کنند می توانند این میزان پهنای باند برای هر اتصال را مصرف کنند). تنظیم محدودیت می تواند مانع از ورود سیستم به سیستم توسط مشتریان خاص شود، و حتی کیفیت سرویس را برای همه مشتریان فراهم می کند.
  • limit_reqو limit_req_zone– میزان درخواست های پردازش شده توسط NGINX را محدود کنید، که دارای مزایای مشابه با تنظیمات است limit_rate. آنها همچنین می توانند امنیت را به خصوص برای صفحات ورود، با محدود کردن میزان درخواست به ارزش معقول کاربران انسان، افزایش دهند، اما برای برنامه هایی که تلاش می کنند برنامه شما را با درخواست ها (مانند ربات ها در یک حمله DDoS) کند، بسیار کم است.
  • max_connsپارامتر به serverدستورالعمل در یک upstreamبلوک پیکربندی – حداکثر تعداد اتصالات همزمان پذیرفته شده توسط یک سرور در یک گروه بالادست را تنظیم می کند. محدودیت اعمال می تواند به جلوگیری از بارگذاری سرورهای بالادست کمک کند. تنظیم مقدار به 0 (صفر، به طور پیش فرض) به این معنی است که هیچ محدودیتی وجود ندارد.
  • queue(NGINX Plus) – ایجاد یک صف که در آن درخواست ها قرار می گیرند، زمانی که تمام سرورهای موجود در گروه بالادست به max_connsحد خود برسند . این دستور حداکثر تعداد درخواست ها را در صف و حداکثر زمان انتظار (60 ثانیه به طور پیش فرض) را تعیین می کند. اگر این دستورالعمل را حذف کنید، درخواستها در صف نیستند.

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

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

ذخیره سازی

با فعال کردن ذخیره سازی بر روی نمونه NGINX که بارگذاری متعادل مجموعه ای از سرورهای وب یا برنامه های کاربردی است، شما می توانید به طور چشمگیری زمان پاسخ به مشتریان را بهبود می بخشد در حالی که در عین حال به طور چشمگیری کاهش بار سرورهای باطن را کاهش می دهد. ذخیره سازی یک موضوع به تنهایی است و ما تلاش نمی کنیم آن را در اینجا پوشش دهیم. مراجعه کنید Nginx به علاوه راهنمای مدیریت .

فشرده سازی

فشرده سازی پاسخ های ارسال شده به مشتریان می تواند به میزان قابل توجهی آنها را کاهش دهد، بنابراین آنها از پهنای باند شبکه کمتر استفاده می کنند. از آنجا که فشرده سازی داده ها منابع CPU را مصرف می کند، اما مفید تر است، زیرا واقعا ارزش استفاده از پهنای باند را دارد. مهم است که توجه داشته باشید که شما نباید فشرده سازی را برای اشیایی که قبلا فشرده شده اند، مانند فایل های JPEG فعال کنید. برای کسب اطلاعات بیشتر، راهنمای NGINX Plus Admin را ببینید .

این صفحه چطور بود؟ post