معرفی nginx و بررسی ویژگی های آن

این وب سرور که هر روز جمع بیشتری از آن استفاده می کنند WordPress.com را لیست استفاده کننده گان خود دارد.

از نکات مهم معرفی nginx این است که بر روی سیستم عامل های windows linux Bsd و osx به راحتی نصب می شود.

در این سیستم استفاده از روش  asynchronous event-driven  است که باعث شده که به میزان استفاده ثابت از RAM برسیم.

asynchronous event-driven چیست؟

• وب سرور ها به طریق مختلفی اقدام به مدیریت درخواست ها  (connection ) می کنند.
• برای هر درخواست یک process جدید درست می کنند.
• جهت هر درخواست یک process جدید درست می کنند در حالی که سیستم connection poll هم دارند که تا مدتی process ها را نگه می دارد و در صورتی که در آن زمان درخواست جدیدی بیاید از process های بیکار استفاده می کنند.
• برای هر درخواست یک thread جدید درست می کنند.
• بـرای هر درخواست یک thread جدید درست می کنند در حالی که سیستم thread poll هم دارند که تا مدتی thread ها را نگه می دارد و در صورتی که در آن زمان درخواست جدیدی بیاید از thread های بیکار استفاده می کنند.
• یک process همه event ها را مدیریت می کند. (قبول درخواست، پاسخ به کاربر، خواندن داده و … )

ترکیبات روش ها

Nginx از روش چهارم استفاده می کند به همراه ساخت process برای مجموعه از event ها … البته مقداری مشخص را در config مشخص می کند. همه این ها برای این است که بیشترین استفاده را از سیستم خود بکنیم.

به طور کلی باز کردن process و thread هزینه بر است و از آن مهمتر مدیریت اینهاست. وب سرورهایی شبیه Apache که  process و thread هستند با درخواست های زیاد به شدت درگیر مدیریت  process و thread می شوند که در نتیجه فشار زیاد تری به سرور می آورند.

http://www.devside.net/articles/apache-performance-tuning
The more RAM your system has, the more processes [and threads] Apache can allocate and use; which directly translates into the amount of concurrent requests/clients Apache can serve.

ارتباط مستقیمی بین RAM و درخواست ها در این وب سرور ها وجود دارد که در روش nginx تا جای ممکن از استفاده ی اضافه آن جلوگیری شده است. توضیح دیگری را دیدم که جالب به نظر می رسید.

فکر کنید که وب سرور یک پیتزا فروشیست که باید سفارش ها را از طریق تلفن دریافت کند. در روش process و thread فروشگاه کارمند استخدام می کند. (process و thread) که هرکدامشان یک خط تلفن دارند و هر کدام سفارش را از طریق تلفن می گیرند. و صبر می کنند تا پیتزا حاضر شود تا به مشتری بگویند ( هنوز تلفن قطع نشده) پیتزای شما حاضر است.

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

معرفی nginx و قابلیت های آن

nginx علاوه بر این که یک وب سرور است,  reverse proxy و e-mail (IMAP/POP3) proxy هم هست … علاوه بر درخواست های http در خواست های مربوط به IMAP و POP3 هم می تواند از امکانات nginx استفاده کند. در این روش شما می توانید از روش ها loadbalancing و چیزهایی از این قبیل برای ایمیل استفاده کنید. البته شما می توانید حتی کارهای عجیب غریبی مثل authentication mail را هم از طریق nginx انجام دهید.

reverse proxy درخواست های بیرونی را به صورت صف شده و جاهای مختلف می فرستد

•     در  reverse proxy ها موجودی سرور های شما را مخفی می کنند و همه ی دنیا شما را از دریچه reverse proxy می بینند.
•     تمام درخواست ها از reverse proxy می گذرد پس جای مناسبی برای firewall ها و … است
•     برای  reverse proxy درخواست ها به صورت گسترده ای می تواند پخش کند.
•     در reverse proxy فشار را با cache کردن محتوای صفحات ثابت می تواند کم کند
•     برای  reverse proxy با فشرده سازی محتوای خروجی سرور ها می تواند زمان درخواست ها را کم کرده و پاسخ به درخواست ها را سریع تر کند.
•     درخواست ها بین سرور reverse proxy و سرور مجازی به سرعت انجام می شود و connection در reverse proxy باز می ماند و سرور اصلی در گیر نمی شود. ( روش SpoonFeeding )

نصب Nginx:

از سایت  http://nginx.org/en/download.html نسخه آخر را دریافت کنید ( که در این مقاله nginx-1.0.6 است)

فایل فشرده شده را باز کنید.

وارد پوشه شوید و از دستور ./configure برای چک کردن نیازمندی ها و ساخت makefile

برای نصب NGINX با دستور make install وب سرور شما نصب می شود. به صورت پیش فرض در آدرس /usr/local/nginx/ قرار می گیرد. برای اجرای وب سرور فایل nginx را اجرا کنید.

/usr/local/nginx/sbin/nginx

حالا port 80 localhost خود را در معرفی nginx مروگر چک کنید.

وب سرور شما با موفقیت نصب و اجرا شد.

برای تست وب سرور با پایتون نیاز یک منتقل Web Server Gateway Interface احتیاج داریم که درخواست های ما را به پایتون بدهد. ما برای این کار از uwsgi استفاده می کنیم. خوشبختانه از ۰٫۸٫۴۰# به صورت پیشفرض تنظیماتش اضافه شده است.

برای شروع باید uwsgi را نصب کنید.

از سایت اصلی دانلود کنید http://projects.unbit.it/ بعد از خارج کردن از حالت فشرده آن را compile کنید . دقت کنید که برای اینکه بتوانید این ماژول c  و پایتونی را کامپایل کنید می بایستی python-dev را هم نصب کنید.

من یک پوشه به اسم /srv/www/zconf/ می سازم که در آن ۲ پوشه وجود دارد

در پوشه application من برنامه ای که از فریم ورک flask# استفاده کرده است گذاشتم و در پوشه دیگر هم logfile مربوط به uwsgi و access مربوط به nginx را گذاشته ام.

معرفی nginx

برنامه ما حالت بسیار ساده ای دارد که فقط درخواست را می گیرد و بدون هیچ cache ای محتوا را بر می گرداند.

#!/usr/bin/env python # -*- encoding: utf-8 -*-   """   app.py ~~~~~~~~~ """ from flask import Flask from flask import render_template_string from werkzeug.contrib.fixers import ProxyFix app = Flask(__name__) @app.route('/') def index():    return render_template_string('<h1>Hello Zconf</h1>') app.wsgi_app = ProxyFix(app.wsgi_app)

در فایل تنظیمات مربوط به قابلیت های nginx هم می بایستی بگوییم که از uwsgi بخواند.

فایل تنظیمات Nginx:

#user  nobody; worker_processes  ۱;

میزان process ی که nginx می تواند باز کند اینجا مشخص می شود

#error_log  logs/error.log; #error_log  logs/error.log  notice; #error_log  logs/error.log  info;

مسیر پیشرفض error ها و نوع error ها در اینجا مشخص می شود

events {    worker_connections  ۱۰۲۴; }

تعداد events هایی که یک process می تواند مدیریت کند

پس می توان گفت تعداد connection ها ضرب بین این متغیر و تعداد process هاست

http {    include       mime.types;

مسیری که mime ها را از آن می خواند

   default_type  application/octet-stream;

نوع پیشفرض mime ی که استفاده می شود

#log_format  main  '$remote_addr - $remote_user [$time_local] "$request" ' #                  '$status $body_bytes_sent "$http_referer" ' #                  '"$http_user_agent" "$http_x_forwarded_for"';

قالب log

   #access_log  logs/access.log  main;

log مربوط به درخواست ها

   sendfile        on;

درخواست های مربوط به فایل را قبول کند یا نه

   #tcp_nopush     on;

HTTP response header را با یک پکت ارسال م یکند

   #keepalive_timeout  0;    keepalive_timeout  ۶۵;

میزان زمانی که می خواهیم connection باز باشد تا جواب داده شود

   server {        listen       ۸۰;

port پیشفرض

       server_name  localhost;

اسم سرور

       #charset koi8-r;

charset پیشفرض

#access_log  logs/host.access.log  main;     location / {    include uwsgi_params;

در اینجا من می گویم که از فایل uwsgi_params که به صورت پیشفرض در پوشه conf داری تنظیمات خود را بخوان

   uwsgi_pass ۱۲۷.۰.۰.۱:۳۰۳۱;

آدرسی که از آن می توانی درخواست ها را بخوانی

        }        error_page   ۵۰۰ ۵۰۲ ۵۰۳ ۵۰۴  /50x.html;        location = /50x.html {            root   html;        }    }  }

همونطور که دیدید من درخواست های مربوط به port ۸۰ را به uwsgi دادم. در این مرحله باید با به uwsgi بگوییم که در پورت مورد نظر اجرا شود

# uwsgi --socket 127.0.0.1:3031 --file application/app.py --callable app --processes 4 --daemonize logs/uwsgi.log

حالا سرور nginx را kill کنید و دوباره startکنید

وب سرور شما به خوبی توانست درخواست را از فایل پایتون بگیرد و نمایش دهد.

بنچمارک nginx

در این مرحله با apache benchmark به تعداد ۱۰۰۰۰۰ درخواست را به سرور می فرستیم که نتیجه کار را ببینیم

linuxweb@linuxweb>-PA65-UD3-B3:~$ ab -n ۱۰۰۰۰۰ -c ۱۰ -g test_data_1.txt http://zconf/ This is ApacheBench, Version ۲.۳ <$Revision: ۶۵۵۶۵۴ $> Copyright ۱۹۹۶ Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking zconf (be patient) Completed ۱۰۰۰۰ requests Completed ۲۰۰۰۰ requests Completed ۳۰۰۰۰ requests Completed ۴۰۰۰۰ requests Completed ۵۰۰۰۰ requests Completed ۶۰۰۰۰ requests Completed ۷۰۰۰۰ requests Completed ۸۰۰۰۰ requests Completed ۹۰۰۰۰ requests Completed ۱۰۰۰۰۰ requests Finished ۱۰۰۰۰۰ requests Server Software:        nginx/۱.۰.۶ Server Hostname:        zconf Server Port:            ۸۰ Document Path:          / Document Length:        ۲۰ bytes Concurrency Level:      ۱۰ Time taken for tests:   ۱۹.۹۶۱ seconds Complete requests:      ۱۰۰۰۰۰ Failed requests:        ۰ Write errors:           ۰ Total transferred:      ۱۷۶۰۰۰۰۰ bytes HTML transferred:       ۲۰۰۰۰۰۰ bytes Requests per second:    ۵۰۰۹.۸۶ [#/sec] (mean) Time per request:       ۱.۹۹۶ [ms] (mean) Time per request:       ۰.۲۰۰ [ms] (mean, across all concurrent requests) Transfer rate:          ۸۶۱.۰۷ [Kbytes/sec] received Connection Times (ms)              min  mean[+/-sd] median   max Connect:        ۰    ۰   ۰.۰      ۰       ۰ Processing:     ۱    ۲   ۱.۵      ۲      ۳۵ Waiting:        ۱    ۲   ۱.۵      ۲      ۳۵ Total:          ۱    ۲   ۱.۵      ۲      ۳۵ Percentage of the requests served within a certain time (ms)  ۵۰%      ۲  ۶۶%      ۲  ۷۵%      ۲  ۸۰%      ۲  ۹۰%      ۲  ۹۵%      ۳  ۹۸%      ۶  ۹۹%     ۱۲ ۱۰۰%     ۳۵ (longest request)

همانطور که دقت می کنید با اینکه Concurrency برابر ۱۰ بود زمان connection زمانی معادل ۰ داشته .

از طرفی هم نمودار های دیگری نیز وجود دارد که استفاده از آنها خالی از لطف نیست.