«Apache یک وب سرور آزاد ، بازمتن و مستقل از پلتفرم است که به ایفای موثر ترین نقش در رشد WWW مشهور است. در سال ۲۰۰۹ به عنوان اولین وب سرویس با میزبانی از ۱۰۰ میلیون وب سایت شناخته شد همچنین در همین سال به بیش از ۴۹٪ از وب سایت ها سرویس دهی کرده است.»
این جملاتی است که در پایگاه Wikipedia در مورد apache بیان شده است .مدیریت و پاسخگویی بهتر به درخواست های همزمان احتمالا اولین و مهم ترین دغدغه ی هر مدیر سیستمی است.اما آیا راه سریع تری برای سرویس دهی بهتر وجود دارد!؟ پاسخ کوتاه اینکه Nginx (بخوانید Engine-X) قادر است به واسطه ی معماری مناسب ، درخواست های بیشتری را با صرف منابع کمتری پاسخ گوید. اما به استناد به کدامین دلیل؟ چه معماری این قابلیت را فراهم می آورد !؟
حدود ۱۲ سال پیش دن کیگل مطلبی را منتشر و متذکر شد که «زمان آن رسیده که وب سرور ها به اداره ی ده هزار درخواست همزمان بپردازند» و این بیانات آغازی شد بر چالش C10K و Nginx سکان کشتی این جنبش را به دست گرفت. Apache در سال ۱۹۹۵ ساخته شده بود و در مقایسه ، Nginx که در سال ۲۰۰۴ به عنوان پاسخ C10K و با پند گیری از تجربیات نا موفق آپاچی معرفی شده بود ، راهی به سوی سرویس دهی بهتر یک وب سرور بود. امروز Nginx به دو ویژگی در میان مدیران سرور معروف است : پاسخگویی در زمان لود زیاد و نیاز یه منابع اندک.
عمده علت اختلاف عملکردی حاصل از نحو اداره ی Connection ها در درخواست های دریافتی است.آپاچی از چند ماژول برای مدیریت پردازش همزمان (multi-processing modules )که آنها را MPM میخواند ، استفاده می کند. ماژول mpm_prefork که برای اداره هر درخواست ، آن را به یک پروسس جدید و مجزا با تنها یک نخ نگاشت می دهد. هرپروسس فرزند فقط می تواند یک Connection را در هر لحظه اداره کند و هرچه تعداد درخواست ها کمتر باشد ، پروسس های کمتری ایجاد می شود. این ماژول در وضعیتی که Connection ها اندک است سرعت بالایی ارائه می کند اما با افزایش Connection ها و درخواست ها ، حجم سر بار سویچ پروسس ها و میزان حافظه مصرفی آنها سیستم را ناکارآمد می سازد.
ماژول دیگری (mpm_worker) وجود دارد که عملکرد متفاوتی دارد. این ماژول با ایجاد پروسس هایی با چند نخ سعی در اداره ی Connection ها دارد. هر نخ به تنهایی می تواند درخواست های یک Connection را مدیریت کند. طبعا نخ ها در مصرف حافظه و سویچ ها عملکرد بهینه تری ارائه می کنند.
از نسخه ۲.۴ آپاچی و پس از آن ، ماژول mpm_event ارائه شده است که برای Connection هایی که به صورت محاوره ای عمل میکنند و اصلاحا keep-alive connection هستند ، عملکرد بهتری دارد. این ماژول مانند mpm_worker عمل میکند با این تفاوت که برای Connection های پایدار بهسازی شده است و بر مبنای رویداد های عرضه شده از سوی کلاینت عمل می کند.در این متد فرض است که هر Connection نخ مربوط به خود را تا پایان حیات خود حفظ می کند.
اینکه آپاچی اجازه ی انتخاب شیوه اداره ی امور مرتبط به Connection را به دست می دهد خود یک مزیت است.اما Nginx مدتی طولانی پس از آپاچی ارائه شده است لذا انتظار می رود که تجربیان ناکارآمد تا حد امکان محو شده باشد. لذا Nginx از الگوریتم غیر همگام(asynchronous) ، مسدود نشدنی (non-blocking) و هدایت شده به واسطه ی رویداد ها (event-driven) برای اداره ی Connection ها بهره می برد.پروسس های Enginx می توانند هزاران Connection را پاسخگو باشند چرا که پاسخگویی بر مبنای یک حلقه که مکررا رویدادها را چک و پردازش می کند اجرا می شود. تجزیه ی درخواست های connection ها ، امکان می دهد هر پروسس تنها زمانی به درخواست اهمیت دهد که یک رویداد جدید اتفاق افتاده باشد.بدین ترتیب رویداد هایی که ممکن است بین Connection های مختلف یکسان باشند قابل چشم پوشی و Cache شدن هستند.هر Worker در قالب یک پروسس تک نخی عمل می کند و پروسس ها می توانند فضای حافظه مشترک برای cache داده و نگهداری داده های تکرار پذیر Session ها داشته باشند. در این حالت پردازش غیر همگام از Connection های مختلف میسر ، همچنین نخ ها و پروسس ها در انحصار یک Connection نیستند.وقتی یک Connection بسته می شود ، تنها از حلقه پروسس Worker خارج می شود. این سازوکار امکان مدیریت بهتر منابع را به دست می دهد و همچنین عملکرد بهتری در زمان بار زیاد سرور خواهد داشت.
تفاوت عمده بعدی در عملکرد ساختار توسعه پذیری یا ماژول های این دو وب سرور است. اگرچه آپاچی امکان لود داینامیک ماژول ها را به دست می دهد ، اما «مثل همیشه استعداد مادرزادی بهتر از استعداد اکتسابی است(آرتور شوپنهاور)».ماژول های Nginx نیازمند کامپایل در هسته ی سیستم هستند.این مسئله به نفع performance است ، نیز خطر وقوع DLL Hell را ناممکن می سازد ، با این حال لود داینامیک احتمالا کاربرانی را خوشحال خواهد ساخت…
تفاوت دیگر به نحو پیکربندی مرتبط است.آپاچی امکان directory override را به دست می دهد که به کمک آن به ازای هر دایرکتوری می توان تنظیمات متفاوتی را اعمال نمود.چنین امکانی در Nginx فراهم نیست و پیکربندی به طور متمرکز انجام می شود و فایلی مانند htaccess در آن تفسیر نمی شود. این مسئله و عدم امکان لود داینامیک ماژول ها تاحدی باعث کاهش انعطاف پذیری Nginx می شود ، اما برای کدام مدیر سیستم انعطاف پذیری بر کارایی اولویت دارد؟
در ساختار پیکربندی متمرکز به دلیل تجمیع پیکربندی ، و عدم فراخوان مکرر سیستم فایل به ازای دایرکتوری ها کارایی ارتقا می یابد. همچنین مسئله حائز اهمیت دیگر دیدگاه امنیت سیستم است. توزیع پیکربندی ها در سطح دایرکتوری در حقیقت توزیع مسئولیت پیکربندیهای امنیتی در سطح کاربران است. چه اتفاقی خواهد افتاد اگر کاربری ناخواسته تهدید امنیتی ایجاد کند؟ اطمینان از اینکه فقط مدیر سیستم می تواند پیکربندی های وب سرور را در دست داشته باشد باعث آسودگی خاطر بیشتری است. البته تفاوت های عملکردی دیگری نیز وجود دارد که برای برسی تفاوت ها ، پایگاه www.nginx.com مفید خواهد بود.
اگر هنوز کنجکاوی شما را متقاعد به برسی بیشتر Nginx به عنوان وب سرویس محبوب آینده تان نکرده است تصویر فوق که انفوگرام عملکرد Nginx است شاید مفید واقع شود. اما در پایان بد نیست بدانیم که از netcraft نیز اطلاعات آماری زیر در دست است :
