Apache vs NGINX - من يفوز من حيث الأداء؟

تعد Apache vs NGINX واحدة من أكثر المناظرات سخونة (منذ إصدار NGINX) لأن كلاهما من أكثر خوادم الويب شيوعًا في الكلمة تليها LiteSpeed ​​و OpenLiteSpeed.

تعمل Apache و NGINX على تشغيل ما يقرب من 60 ٪ من مواقع الويب العالمية. تتشابه Apache و NGINX من حيث الأداء والميزات. من ناحية أخرى ، تختلف الهندسة المعمارية والأمان والأداء.

قد يكون من الصعب الاختيار بين هذين الخادمين لأن كلاهما ممتاز. نظرًا لأن لكل خادم ويب مجموعته الخاصة من المزايا والعيوب ، فمن الأهمية بمكان توفير أفضل خيار ممكن.

يمكنك أيضًا التحقق من مناقشة openlitespeed و nginx هنا.

مقارنة Apache مقابل NGINX Speed

قبل التعمق في مناقشة Apache و NGINX. سنقوم أولاً بإجراء اختبار سرعة بسيط ، حيث سنجري الاختبار في السيناريوهات التالية.

• دعونا نختبر ملفًا ثابتًا صغيرًا من 5 كيلو بايت
• ملف ثابت بحجم 1 ميغا بايت
• اختبار تطبيق PHP Hello World بسيط
• المقارنة المعيارية بين Apache و NGINX for WordPress

لقد استخدمنا نفس الإجراء لاختبار openlitespeed مقابل nginx. يعد OpenLiteSpeed ​​بديلاً رائعًا حقًا لـ NGINX لأنه يدعم قواعد إعادة كتابة .htaccess الأساسية أيضًا ، وبالتالي يمكنك الانتقال بسهولة من Apache إلى OpenLiteSpeed.

دعونا نختبر ملفًا ثابتًا صغيرًا من 5 كيلو بايت

الحكم النهائي : قام كلا الخادمين بنفس الأداء مع ملف ثابت صغير.

اباتشي

NGINX

ملف ثابت بحجم 1 ميغا بايت

الحكم النهائي : فازت NGINX بوضوح بملف ثابت كبير.

اباتشي

NGINX

اختبار تطبيق PHP Hello World بسيط

الحكم النهائي : كلا الخادمين نفذوا نفس الشيء مع تطبيق hello world php.

اباتشي

NGINX

المقارنة المعيارية بين Apache و NGINX for WordPress

الحكم النهائي : فازت NGINX بوضوح بموقع WordPress. يمكنك استخدام هذا الدليل لتسريع متجر WooCommerce

اباتشي

NGINX

نتيجة الاختبار - Apache vs NGINX

كما نرى في الاختبارات أن NGINX أفضل نسبيًا من Apache من حيث السرعة. النتائج هي:

1. اختبر ملفًا ثابتًا صغيرًا من 5 كيلوبايت:

في هذا الاختبار ، نرى أن كلا من Apache ad NGINX يعطيان نفس النتائج النسبية.

2. اختبر ملفًا ثابتًا كبيرًا بحجم 1 ميغابايت:

في هذا الاختبار ، نرى أن سرعة NGINX أفضل من Apache. NGINX تعطي متوسط ​​وقت استجابة أقل بكثير.

3. اختبر تطبيق PHP Hello World بسيط

في هذا الاختبار ، نرى أن كلاً من Apache و NGINX يعطيان نفس النتائج النسبية.

4. اختبار Apache مقابل NGINX لـ WordPress

في هذا الاختبار ، نرى أن متوسط ​​وقت استجابة NGINX أقل بكثير من وقت استجابة أباتشي مما يمنحها سرعة أكبر من سرعة NGINX.

اباتشي

هناك مجتمع من المطورين الذين يحتفظون بـ Apache كخادم ويب مفتوح المصدر. يستخدم بنية مدفوعة بالعملية حيث يقوم بإنشاء مؤشر ترابط جديد لكل طلب اتصال.
علاوة على ذلك ، يقدم Apache مجموعة متنوعة من الوحدات النمطية التي يمكن استخدامها لزيادة وظائف خادم الويب الخاص بك. Apache سريع وموثوق وآمن وقابل للتخصيص بدرجة كبيرة لتلبية احتياجات البيئات المختلفة من خلال استخدام الملحقات والوحدات النمطية.

هندسة معالجة الاتصال

يحتوي Apache على عدد من وحدات المعالجة المتعددة (تسمى MPMs بواسطة Apache) التي تتحكم في كيفية معالجة طلبات العميل. بشكل أساسي ، يتيح هذا للمسؤولين التبديل السريع لبنية معالجة الاتصال.

• mpm-Prefor: تقوم وحدة المعالجة المتعددة (MPM) بتنفيذ خادم ويب مسبق التفرع غير مترابط. يمكن لكل عملية خادم الاستجابة للطلبات الواردة ، كما تتم إدارة حجم تجمع الخادم بواسطة عملية أصل. إنه مناسب للمواقع التي تحتاج إلى تجنب الترابط من أجل العمل مع المكتبات غير الآمنة لمؤشر الترابط. إنها أيضًا أفضل MPM لعزل كل طلب ، مما يضمن عدم تأثير مشكلة مع أحد على الآخرين.
• عامل mpm: يتم تنفيذ خادم هجين متعدد العمليات متعدد الخيوط بواسطة وحدة المعالجة المتعددة (MPM). يمكن أن يخدم عددًا كبيرًا من الطلبات بموارد نظام أقل من الخادم المستند إلى العمليات لأنه يستخدم مؤشرات الترابط لتقديم الطلبات. من خلال الحفاظ على العديد من العمليات المتاحة ، لكل منها العديد من مؤشرات الترابط ، فإنها تحتفظ بالكثير من استقرار الخادم القائم على العمليات.
• حدث mpm: يهدف الحدث Multi-Processing Module (MPM) إلى السماح بخدمة طلبات متعددة في نفس الوقت عن طريق تفويض معالجة معينة إلى سلاسل رسائل المستمع ، وتحرير سلاسل العمليات العاملة لخدمة الطلبات الجديدة.
  يتمتع Apache بتصميم مرن يسمح لك بالاختيار من بين مجموعة متنوعة من خوارزميات معالجة الاتصال والطلب. نظرًا لتغير مشهد الإنترنت ، فإن الاختيارات المقدمة هي في الأساس نتاج تطور الخادم وزيادة الطلب على التزامن.

المحتوى الثابت مقابل الديناميكي

يمكن معالجة المحتوى الثابت بواسطة خوادم Apache باستخدام آلياتها القياسية القائمة على الملفات. تعد مناهج MPM المذكورة أعلاه مسؤولة في الغالب عن أداء هذه الإجراءات.

يمكن لـ Apache أيضًا معالجة المحتوى الديناميكي عن طريق تضمين معالج خاص باللغة في كل حالة من حالات العامل. يمكّنه ذلك من تنفيذ محتوى ديناميكي دون استخدام مكونات خارجية داخل خادم الويب. يمكن استخدام الوحدات القابلة للتحميل ديناميكيًا لتمكين هذه المعالجات الديناميكية.

نظرًا لأن Apache يمكنه التعامل مع المحتوى الديناميكي داخليًا ، يكون تكوين المعالجة الديناميكي أسهل عادةً. يمكن تبديل الوحدات بسهولة إذا تغيرت متطلبات المحتوى ، ولا يلزم تنسيق الاتصال مع برنامج إضافي.

التوزيع الموزع مقابل التكوين المركزي

من خلال تحليل وتفسير التوجيهات في الملفات المخفية داخل مجلدات المحتوى نفسها ، يضيف Apache خيارًا للسماح بمزيد من التكوين على أساس كل دليل. ملفات .htaccess هي اسم هذه الملفات.

نظرًا لوجود هذه الملفات داخل مجلدات المحتوى ، يبحث Apache عن ملف .htaccess في كل مكون من مكونات المسار إلى الملف المطلوب ويطبق التوجيهات الموجودة هناك. يمكّن هذا بشكل فعال من إعداد خادم الويب اللامركزي ، والذي يستخدم بشكل شائع لإعادة كتابة عناوين URL ، وقيود الوصول ، والتفويض والمصادقة ، وحتى سياسات التخزين المؤقت.

بينما يمكن إعداد جميع الأمثلة السابقة في ملف تكوين Apache الرئيسي ، توفر ملفات .htaccess عددًا من المزايا. أولاً ، نظرًا لأنه يتم تقييمها في كل مرة يتم مواجهتها على طول مسار الطلب ، يتم تنفيذها دون الحاجة إلى إعادة تحميل الخادم. ثانيًا ، يمكّن المستخدمين غير المتميزين من التحكم في أجزاء معينة من محتوى الويب الخاص بهم دون منحهم سلطة كاملة على ملف التكوين.

يمكن الآن لبعض برامج الويب ، مثل أنظمة إدارة المحتوى ، تخصيص بيئتها بسهولة دون الحاجة إلى الوصول إلى ملف التكوين المركزي. يستخدم مقدمو الاستضافة المشتركة هذا للحفاظ على التحكم في الإعداد الأساسي مع إتاحة وصول العملاء إلى أدلةهم المحددة.

الملف مقابل التفسير المستند إلى URI

يمكن أن يفسر Apache طلبًا على أنه إما مورد نظام ملفات مادي أو وجهة URI تتطلب تقييمًا أكثر تجريدًا. بشكل عام ، يستخدم Apache كتل <Directory> أو <File> للأولى ، بينما يتم استخدام كتل <Location> لمزيد من الموارد المجردة.

نظرًا لأن Apache تم بناؤه من الألف إلى الياء ليكون خادم ويب ، فإنه يفسر الطلبات على أنها موارد نظام ملفات افتراضيًا. للعثور على ملف فعلي ، يبدأ بجذر المستند ويلحق جزء الطلب بعد المضيف ورقم المنفذ. على الويب ، يتم تمثيل التسلسل الهرمي لنظام الملفات بشكل أساسي من خلال شجرة المستندات المتاحة.

عندما لا يتطابق الطلب مع نظام الملفات الأساسي ، يقدم Apache عددًا من الخيارات. يمكن استخدام توجيه الاسم المستعار ، على سبيل المثال ، لتعيين مكان مختلف. يتيح لك استخدام كتل <Location> بدلاً من نظام الملفات العمل مع URI مباشرةً. تتوفر أيضًا اختلافات التعبير العادي لتطبيق التكوين بشكل أكثر مرونة عبر نظام الملفات.

على الرغم من أن Apache يمكن أن يعمل على كل من نظام الملفات الأساسي ومساحة الويب ، إلا أنه يفضل استخدام تقنيات نظام الملفات. تعكس بعض قرارات التصميم ذلك ، مثل استخدام ملفات .htaccess لإعداد كل دليل.

معامل

يسمح لك نظام الوحدات النمطية في Apache بتحميل الوحدات النمطية وتفريغها ديناميكيًا لتلبية احتياجاتك أثناء تشغيل الخادم. نواة Apache موجودة دائمًا ، ولكن يمكن تمكين الوحدات النمطية أو تعطيلها ، وإضافة الوظائف أو حذفها والاتصال بالخادم الرئيسي.

يتم استخدام هذه الميزة بواسطة Apache في مجموعة واسعة من المهام. نظرًا لنضج النظام الأساسي ، فإنه يأتي بمكتبة كبيرة من الوحدات النمطية. على سبيل المثال ، يقوم Mod php بتضمين مترجم PHP في كل عامل قيد التشغيل ، ويمكن استخدامه لتغيير أجزاء من الوظائف الأساسية للخادم.

من ناحية أخرى ، لا تتعامل الوحدات النمطية مع المحتوى الديناميكي فقط. يمكنهم إعادة كتابة عناوين URL ، ومصادقة العملاء ، وتقوية الخادم ، والتسجيل ، والتخزين المؤقت ، والضغط ، والوكيل ، ومعدل التقييد ، وتشفير البيانات ، من بين وظائف أخرى. يمكنهم تقديم وظائف محسنة دون إضافة الكثير من العمل.

الدعم والتوافق والنظام البيئي والتوثيق

نظرًا لأن Apache كان موجودًا منذ فترة طويلة ، فهناك الكثير من الدعم له. بالنسبة للخادم الأساسي والمواقف المستندة إلى المهام التي تتضمن توصيل Apache ببرامج أخرى ، توجد مكتبة كبيرة من وثائق الطرف الأول والثالث يمكن الوصول إليها.

تحتوي العديد من الأدوات ومشاريع الويب على أدوات لتشغيل نفسها داخل بيئة Apache ، بالإضافة إلى الوثائق. قد يتم توفير ذلك في المشاريع نفسها أو في الحزم التي يحتفظ بها فريق التعبئة والتغليف الخاص بالتوزيع.

بسبب حصتها في السوق ومقدار الوقت الذي كانت متاحة فيه ؛ سيتلقى Apache المزيد من الدعم من مشاريع الجهات الخارجية بشكل عام. من المرجح أيضًا أن يكون المسؤولون قد عملوا مع Apache ، ليس فقط بسبب استخدامه على نطاق واسع ، ولكن أيضًا لأن العديد من الأشخاص بدأوا حياتهم المهنية في بيئات الاستضافة المشتركة ، حيث يتم استخدام Apache تقريبًا بسبب ميزات الإدارة الموزعة .htaccess .

مزايا Apache مقابل NGINX

يفضل العديد من مشرفي المواقع والمطورين Apache على NGINX لأنه أقدم بكثير. وهو متوافق مع أنظمة تشغيل Windows و Unix و Linux.

• لتقديم المواد الديناميكية ، يعد هذا أداءً ممتازًا.
• تحميل وتفريغ الوحدات ديناميكيًا.
• توفير ملف .htaccess لكل دليل يمكن استخدامه لتجاوز الإعدادات على مستوى النظام.
• الدعم والوثائق معلقة.
• يستخدم النموذج نهج اتصال واحد لكل عملية.
• يتضمن الوحدات النمطية mod_evasive و mod_security ، والتي تضيف طبقة أمان إضافية.

عيوب Apache مقابل NGINX

• غير قادر على التعامل مع عدد كبير من الطلبات في نفس الوقت.
• عند المقارنة بـ NGINX ، يستغرق عرض المحتوى الثابت وقتًا أطول.
• يوفر إمكانات إعداد وإدارة واسعة النطاق. نتيجة لذلك ، فهي ليست مناسبة للمبتدئين.
• مواقع الويب التي بها عدد كبير من الزيارات لها مخاوف تتعلق بالأداء.

NGINX

في محاولة للتغلب على مشكلة "C10k" ، اخترع المبرمج الروسي Igor Sysoev NGINX. حقق Igor هدفه: يمكن لـ NGINX بسهولة إدارة أكثر من 10000 اتصال متزامن. للتعامل بشكل أفضل مع التوصيلات الجديدة ، يتميز NGINX بتصميم غير متزامن يحركه الحدث. NGINX هو خادم ويب يوفر الكثير من الإمكانات. المدرجة أدناه هي عدد قليل منهم:

• ذاكرة تخزين مؤقت HTTP وموازن تحميل
• الوكيل الأمامي لخوادم الويب Apache وخوادم الويب الأخرى.
• يتم تقديم كل من بروتوكولات HTTP و HTTPS و SMTP و POP3 و IMAP بواسطة خادم الوكيل العكسي هذا.

منذ إطلاقه ، زادت شعبية NGINX بسبب انخفاض استخدام الموارد والقدرة على التوسع بشكل فعال على الأجهزة منخفضة التكلفة. NGINX هو خادم ويب متخصص في تقديم المواد الثابتة بسرعة وهو مصمم لإعادة توجيه الطلبات الديناميكية إلى البرامج الأكثر ملاءمة لمثل هذه المهام.

هندسة معالجة الاتصال

وصلت NGINX إلى مكان الحادث بعد Apache ، مع فهم أفضل لقضايا التزامن التي ستواجهها المواقع على نطاق واسع. تم بناء NGINX من الألف إلى الياء باستخدام خوارزمية معالجة الاتصال غير المتزامن وغير المحظور والمدفوع بالأحداث للاستفادة من هذه المعلومات.

تولد NGINX عمليات عاملة ، كل منها قادر على التعامل مع عشرات الآلاف من الاتصالات. تحقق عمليات العمال ذلك من خلال تطوير آلية الحلقات السريعة التي تتحقق من الأحداث وتعالجها بشكل منتظم. من خلال فصل العمل الفعلي عن الاتصالات ، يمكن لكل عامل التركيز على اتصال فقط عند وقوع حدث جديد.

يتم وضع كل من اتصالات العامل في حلقة الحدث ، حيث تتعايش مع اتصالات أخرى. تتم معالجة الأحداث بشكل غير متزامن داخل الحلقة ، مما يسمح بإنجاز العمل بطريقة غير محجوبة. يتم حذف الارتباط من الحلقة بعد إغلاقها.

يمكن لـ NGINX التوسع بشكل استثنائي مع الحد الأدنى من الموارد بفضل طريقة معالجة الاتصال الخاصة بها. نظرًا لأن الخادم أحادي الخيوط ولا يتم إنشاء عمليات إضافية للتعامل مع كل اتصال جديد ، يظل استخدام الذاكرة ووحدة المعالجة المركزية ثابتًا نسبيًا ، حتى عندما يكون الخادم تحت ضغط شديد.

المحتوى الثابت مقابل الديناميكي

NGINX ليس لديها دعم أصلي لمعالجة المحتوى الديناميكي. يجب على NGINX تمرير PHP وطلبات المحتوى الديناميكي الأخرى إلى معالج خارجي للمعالجة ثم الانتظار حتى يتم إرجاع المحتوى المقدم. يمكن بعد ذلك إبلاغ العميل بالنتائج.

بالنسبة للمسؤولين ، هذا يعني أنه يجب تكوين الاتصال بين NGINX والمعالج باستخدام أحد البروتوكولات التي تفهمها NGINX (http ، FastCGI ، SCGI ، uWSGI ، memcache). هذا يمكن أن يجعل الأمور أكثر تعقيدًا ، خاصة عند تقدير عدد الاتصالات المسموح بها ، لأن كل استدعاء للمعالج سيتطلب اتصالاً جديدًا.

من ناحية أخرى ، توفر هذه الاستراتيجية بعض الفوائد. سيكون الحمل الزائد للمترجم الديناميكي موجودًا فقط للمواد الديناميكية لأنه غير مدرج في عملية العامل. يمكن إرسال المحتوى الثابت بطريقة مباشرة ، مع استشارة المترجم الفوري عند الضرورة فقط. هذا ممكن أيضًا مع Apache ، لكنه يلغي الفوائد المذكورة في القسم السابق.

التوزيع الموزع مقابل التكوين المركزي

NGINX لا يفهم ملفات .htaccess وليس لديه طريقة لتقييم التكوين لكل دليل خارج ملف التكوين الرئيسي. على الرغم من أنه أقل تنوعًا من نهج Apache ، إلا أنه يحتوي على مجموعة من الفوائد الخاصة به.

زيادة الأداء هو أكثر مكاسب ملحوظة على نهج .htaccess لإعداد مستوى الدليل. لكل طلب ، سيتحقق الخادم من هذه الملفات في كل من الأدلة الرئيسية المؤدية إلى الملف المطلوب في إعداد Apache القياسي الذي يسمح بـ .htaccess في أي دليل. إذا ظهر هذا البحث واحدًا أو أكثر من ملفات .htaccess ، فيجب قراءتها ومعالجتها. يمكن لـ NGINX تقديم الطلبات بشكل أسرع عن طريق تنفيذ استعلام دليل واحد وقراءة الملف لكل طلب من خلال عدم السماح بتجاوزات الدليل (بافتراض أن الملف موجود في بنية الدليل التقليدية).

فائدة أخرى هي أنها آمنة. يؤدي توزيع الوصول إلى التكوين على مستوى الدليل أيضًا إلى توزيع مسؤوليات الأمان على المستخدمين الفرديين ، الذين قد يتم الوثوق بهم أو لا يمكن الوثوق بهم للقيام بذلك بشكل صحيح. من خلال التأكد من أن المسؤول لديه سيطرة كاملة على خادم الويب ، يمكنك تجنب العديد من الأخطاء الأمنية التي قد تظهر عند منح الوصول للآخرين.

إذا كنت قلقًا بشأن هذه المشكلات ، فضع في اعتبارك أنه يمكنك تعطيل تفسير .htaccess . في Apache.

تفسير ملف VS المستند إلى URI

تم تصميم NGINX للعمل كخادم ويب وكذلك خادم وكيل. إنه يعمل بشكل كبير مع URIs ، حيث يترجم إلى نظام الملفات عند الضرورة ، بسبب البنية المطلوبة لهاتين الوظيفتين.

يمكن ملاحظة ذلك في الطريقة التي يتم بها بناء ملفات تكوين NGINX ومعالجتها في بعض الحالات.
NGINX ليس لديها طريقة لتحديد التكوين لدليل نظام الملفات ، لذلك يوزع URI.

تعد كتل الخادم والموقع ، على سبيل المثال ، أهم كتل التكوين لـ NGINX. كتلة الخادم هي المسؤولة عن تفسير المضيف المطلوب ، في حين أن كتل الموقع مسؤولة عن مطابقة أجزاء من URI بعد المضيف والمنفذ. تتم الآن معالجة الطلب باعتباره URI بدلاً من موقع نظام ملفات.

يجب في النهاية تعيين جميع طلبات الملفات الثابتة إلى مكان على القرص. تختار NGINX كتل الخادم والموقع التي ستعالج الطلب أولاً ، ثم تجمع جذر المستند مع URI ، وتعديله حسب الحاجة بناءً على الإعدادات.

قد يبدو هذا مشابهًا ، ولكن تفسير الطلبات إلى حد كبير على أنها URIs بدلاً من مواقع أنظمة الملفات يجعل من السهل على NGINX العمل كخادم ويب وبريد وخادم وكيل. يتم إعداد NGINX من خلال تحديد كيفية الاستجابة لأنماط طلب معينة. لا يفحص NGINX نظام الملفات حتى يصبح جاهزًا لتسليم الطلب ، وهذا هو سبب عدم دعم ملفات .htaccess .

الوحدات

يحتوي NGINX على نظام وحدة أيضًا ، ولكنه يختلف اختلافًا كبيرًا عن نظام Apache. لا يمكن تحميل الوحدات النمطية في NGINX ديناميكيًا ، وبالتالي يجب اختيارها وتجميعها في البرنامج الأساسي.
ستصبح NGINX أقل قدرة بكثير على التكيف مع العديد من المستخدمين نتيجة لذلك. هذا ينطبق بشكل خاص على المستخدمين الذين يترددون في صيانة برامجهم الخاصة خارج مخطط التعبئة القياسي لتوزيعهم. بينما تتضمن معظم حزم التوزيعات الوحدات النمطية الأكثر استخدامًا ، إذا كنت بحاجة إلى وحدة نمطية غير قياسية ، فسيتعين عليك إنشاء الخادم بنفسك من المصدر.

من ناحية أخرى ، لا تزال وحدات NGINX ذات قيمة كبيرة لأنها تسمح لك بتحديد ما تريده بالضبط من الخادم الخاص بك من خلال تضمين الميزات التي تريد استخدامها فقط. قد يعتقد بعض المستخدمين أيضًا أن هذا النهج أكثر أمانًا لأنه لا يمكن توصيل المكونات العشوائية بالخادم. إذا تم وضع الخادم الخاص بك في أي موقف يمكن فيه تصور ذلك ، فمن المؤكد أنه قد تم اختراقه بالفعل.

تتوفر العديد من الميزات نفسها في وحدات NGINX كما هي في وحدات Apache. يتوفر دعم الوكيل والضغط وتقييد المعدل والتسجيل وإعادة الكتابة وتحديد الموقع الجغرافي والمصادقة والتشفير والتدفق والبريد من خلال وحدات NGINX النمطية.

الدعم والتوافق والنظام البيئي والتوثيق

تكتسب NGINX شعبية حيث يستخدمها المزيد من الناس بسبب أدائها العالي ، ولكن لا يزال يتعين عليها اللحاق بالركب في بعض المجالات الحاسمة.

نظرًا لأن معظم عمليات التطوير والتوثيق المبكرة كانت باللغة الروسية ، فقد كان من الصعب العثور على وثائق مهمة باللغة الإنجليزية لـ NGINX في الماضي. تم تجسيد الوثائق مع تزايد الاهتمام بالمشروع ، وهناك حاليًا الكثير من الموارد الإدارية المتاحة على موقع NGINX ومن خلال أطراف ثالثة.

أصبح الدعم والتوثيق لتطبيقات الطرف الثالث متاحًا على نطاق واسع ، وبدأ مشرفو الحزم في تقديم خيارات للتكوين التلقائي لـ Apache و NGINX في بعض الظروف. عادةً ما يكون تكوين NGINX للعمل مع البرامج الأخرى أمرًا بسيطًا حتى بدون دعم ، طالما أن احتياجات المشروع موثقة (أذونات ، رؤوس ، إلخ).

مزايا NGINX

خادم الويب NGINX بسيط وخفيف الوزن وسريع. مصمم خصيصًا لمواقع الويب التي يتم تداولها بشكل كبير.

• يستخدم بنية غير محجوبة تستند إلى الأحداث وتستخدم وحدة معالجة مركزية وذاكرة أقل.
• يتضمن الكثير من خيارات التحسين والخدمة للمحتوى الثابت. ونتيجة لذلك ، فإنه يقدم محتوى ثابتًا أسرع 2.5 مرة ويستخدم ذاكرة أقل من Apache.
• يعمل بشكل رائع في نظام متعدد المعالجات.
• يتم منع هجمات DDoS بواسطة خيار تكوين مضمن.

عيوب NGINX

• لا يمكن معالجة المحتوى الديناميكي محليًا.
• عدد أقل من الوحدات المتاحة.
• يتم دعم أنظمة التشغيل Linux و Unix ، ولكن دعم Windows مقيد.
• لا يدعم NGINX ملف .htaccess المدعوم من قبل Apache.
• ندرة برامج مراقبة السجلات - ببساطة يحفظ السجلات في الملفات التي يجب التنقل فيها يدويًا.

لاستخدام Apache و NGINX معًا

بعد مراجعة مزايا وعيوب كل من Apache و NGINX ، يجب أن تكون قادرًا على تحديد الخادم الأكثر ملاءمة لاحتياجاتك. ومع ذلك ، يجد العديد من المستخدمين أن استخدام كلا الخادمين معًا يتيح لهم الاستفادة من مزايا كل خادم.

التكوين القياسي لهذا التعاون هو استخدام NGINX كوكيل عكسي أمام Apache. سيمكن هذا NGINX من معالجة جميع طلبات العملاء. هذا يستفيد من سرعة المعالجة السريعة لـ NGINX والقدرة على إدارة عدد كبير من الاتصالات في وقت واحد.

سيتم تقديم الملفات بسرعة وبشكل مباشر إلى العميل للحصول على محتوى ثابت ، والذي تتفوق فيه NGINX. ستقوم NGINX بتوكيل طلبات المحتوى الديناميكي ، مثل نصوص PHP ، إلى Apache ، والتي ستعالج النتائج وتوفر الصفحة المعروضة. يمكن بعد ذلك إعادة المواد إلى العميل عبر NGINX.

بالنسبة للعديد من المستخدمين ، يعمل هذا التصميم بشكل جيد لأنه يسمح لـ NGINX بالعمل كآلة فرز. سوف يتعامل مع أي طلبات يمكنه التعامل معها ويمرر الطلبات التي لا يعرف كيفية التعامل معها. يمكننا تقليل بعض عمليات الحظر التي تحدث عند احتلال عملية أو مؤشر ترابط Apache عن طريق تقليل عدد الطلبات التي يُطلب من خادم Apache معالجتها.

يمكنك توسيع نطاق هذا الترتيب عن طريق إضافة المزيد من الخوادم الخلفية حسب الحاجة. يمكن إعداد NGINX ببساطة لإعادة توجيه الطلبات إلى مجموعة من الخوادم ، مما يؤدي إلى تحسين أداء وأداء التهيئة للتسامح.

متى تستخدم Apache مقابل NGINX؟

يعد كل من Apache و NGINX ، كما هو موضح في هذه المقالة ، خوادم ويب قوية وقابلة للتكيف وشاملة. بالنسبة لمواقع الويب عالية الحركة ، فإن Apache هو الأفضل لتوفير مواد ديناميكية ، بينما NGINX هو الأفضل لتوفير محتوى ثابت أو تدفقات الوسائط. الأمر بهذه البساطة:

متى يمكنك استخدام اباتشي

• إذا كنت تستخدم خطة استضافة مشتركة.
• إذا كنت تقدر مجتمعًا مفيدًا به العديد من الموارد ، فهذا هو المكان المناسب لك.
• تحظى Apache بشعبية كبيرة بين مطوري الويب لأنها سهلة الإعداد.

متى يمكنك استخدام NGINX

• إذا كان لديك خادم VPS أو خادم مخصص.
• أنت مالك موقع ويب شهير به الكثير من المحتوى الثابت.
• إذا كنت ترغب في إدارة حركة المرور الواردة وتوزيعها على الخوادم الأولية التي تكون أبطأ.

Apache مقابل NGINX: أيهما يجب أن تختاره لخادمك في عام 2022؟

أيًا كان ما تقدمه شركة الاستضافة الخاصة بك هو الذي يجب عليك استخدامه. في كثير من الظروف ، لن يكون لديك خيار. يتبع العديد من موفري الويب نفس الإستراتيجية ، والتي يجب عليك اتباعها إذا كنت تختار بين Apache مقابل NGINX:

• يعد Apache اختيارًا جيدًا إذا كنت ترغب في استضافة خادم يتطلب إعدادًا ثابتًا أو إذا كنت تريد منح المستخدمين خيار تكوين.
• NGINX ، من ناحية أخرى ، هو السبيل للذهاب إذا كنت تريد أداء فائق السرعة وأمانًا قويًا وقدرة على إدارة التكوينات بدلاً من المستخدمين لديك.

بسبب بنيته الأساسية ، يمكن أن يستهلك Apache المزيد من ذاكرة الوصول العشوائي من حيث الأداء. في حالات الازدحام الشديد ، سيكون أداء NGINX أفضل ، خاصةً إذا كان هناك الكثير من المواد الثابتة التي يجب إدارتها.

وبالتالي قد يكون NGINX هو الحل الأمثل إذا كنت تعتمد على التخزين المؤقت لتخزين المحتوى وتقديمه. تذكر أن NGINX لا يمكنها توفير مادة ديناميكية ؛ لذلك سيتأثر أدائك بفاعلية الخادم الوكيل الذي يستخدمه خادمك.

استنتاج

كما ترون ، فإن Apache و NGINX قويان وقابلان للتكيف وقادران. إن تقييم احتياجاتك الفردية واختبار الأنماط التي تتوقع رؤيتها هما المعياران الأساسيان لاختيار الخادم المناسب لك.

من بين هذه المشاريع ، هناك اختلافات كبيرة في الأداء الخام والقدرات والوقت المستغرق لتنفيذ كل منها. ومع ذلك ، غالبًا ما تكون نتيجة لسلسلة من المفاضلات التي لا ينبغي تجاهلها. أخيرًا وليس آخرًا ، لا يوجد شيء اسمه خادم ويب واحد يناسب الجميع ، لذا اختر الخيار الذي يناسب احتياجاتك.