تستخدم تطبيقات الويب الآن على نطاق واسع ، و HTTP هو نصيب الأسد من جميع بروتوكولات النقل. دراسة الفروق الدقيقة في تطوير تطبيقات الويب ، معظمها يولي القليل من الاهتمام لنظام التشغيل حيث تعمل هذه التطبيقات فعليًا. فصل التنمية (Dev) والتشغيل (العمليات) جعل الأمور أسوأ. ولكن مع انتشار ثقافة DevOps ، يبدأ المطورون في تحمل مسؤولية إطلاق تطبيقاتهم في السحابة ، لذلك من المفيد جدًا لهم التعرف بشكل كامل على الواجهة الخلفية لنظام التشغيل. هذا مفيد بشكل خاص إذا كنت تحاول نشر نظام لآلاف أو عشرات الآلاف من الاتصالات المتزامنة.

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

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

Linux هو نظام تشغيل خادم ، وغالبًا ما يتم تشغيل تطبيقاتك على نظام التشغيل المحدد هذا. على الرغم من أنني أقول "Linux" ، إلا أنه في معظم الأوقات ، يمكنك افتراض أن جميع أنظمة التشغيل المشابهة لنظام التشغيل Unix بشكل عام مخصصة. ومع ذلك ، لم أختبر الكود المرافق على الأنظمة الأخرى. لذلك ، إذا كنت مهتمًا بـ FreeBSD أو OpenBSD ، فقد تختلف النتيجة. عندما أجرب شيئًا خاصًا بنظام Linux ، أشير إليه.

على الرغم من أنه يمكنك استخدام هذه المعرفة لإنشاء تطبيق من البداية ، وسيتم تحسينه بشكل مثالي ، إلا أنه من الأفضل عدم القيام بذلك. إذا كتبت خادم ويب جديدًا في C أو C ++ لتطبيق أعمال مؤسستك ، فقد يكون هذا آخر يوم لك في العمل. ومع ذلك ، فإن معرفة بنية هذه التطبيقات سوف تساعد في اختيار البرامج الحالية. يمكنك مقارنة الأنظمة المستندة إلى العمليات مع الأنظمة المستندة إلى سلاسل الأحداث والمستندة إلى الأحداث. سوف تتفهم وتقدر لماذا يعمل Nginx بشكل أفضل من Apache httpd ، لماذا يمكن لتطبيق Python المستند إلى Tornado أن يخدم عددًا أكبر من المستخدمين من تطبيق Python المستند إلى Django.

ZeroHTTPd: أداة التعلم

ZeroHTTPd هو خادم ويب كتبت من الصفر في C كأداة تدريب. لا يوجد لديه تبعيات خارجية ، بما في ذلك الوصول إلى Redis. نحن ندير إجراءات Redis الخاصة بنا. انظر أدناه لمزيد من التفاصيل.

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

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


ZeroHTTPd الصفحة الرئيسية. يمكن أن تنتج أنواع مختلفة من الملفات ، بما في ذلك الصور

تطبيق دفتر الزوار

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


دفتر الزوار تطبيق ويب ZeroHTTPd

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

يوضح الشكل التالي التطبيق عندما يطلب العميل (المتصفح) /guestbookURL .


آلية تطبيق سجل الزوار

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

البنيات خادم ZeroHTTPd

نحن نبني سبعة إصدارات من ZeroHTTPd مع نفس الوظيفة ولكن بنيات مختلفة:

• ممل
  
• خادم الشوكة (عملية فرعية واحدة لكل طلب)
  
• خادم قبل الشوكة (عمليات الشوكة المسبقة)
  
• خادم مع سلاسل الرسائل (موضوع واحد لكل طلب)
  
• خادم مع ما قبل الخيوط
  
• poll() بناء القائمة
  
• العمارة Epoll

نقيس أداء كل بنية عن طريق تحميل الخادم مع طلبات HTTP. ولكن عند مقارنة البنى مع درجة عالية من التوازي ، يزداد عدد الطلبات. نحن اختبار ثلاث مرات وننظر في المتوسط.

منهجية الاختبار

التثبيت لاختبار الإجهاد ZeroHTTPd

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

ما يفعله كل من هذه الخوادم

• load.unixism.net: هنا نقوم بتشغيل ab ، أداة Apache Benchmark. يولد الحمل اللازم لاختبار أبنية الخادم لدينا.
  
• nginx.unixism.net: في بعض الأحيان نريد تشغيل أكثر من مثيل لبرنامج الخادم. لهذا ، يعمل خادم Nginx بالإعدادات المناسبة كموازن تحميل قادم من ab إلى عمليات الخادم الخاصة بنا.
  
• zerohttpd.unixism.net: هنا نقوم بتشغيل برامج الخادم الخاصة بنا على سبعة أبنية مختلفة ، واحدة تلو الأخرى.
  
• redis.unixism.net: يتم تشغيل البرنامج الخفي Redis على هذا الخادم ، حيث يتم تخزين الإدخالات في دفتر الزوار وعداد الزوار.

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

ما الذي نقيسه؟

يمكنك قياس مؤشرات مختلفة. نقوم بتقييم أداء كل هندسة في هذا التكوين ، مع تحميل الخوادم مع الطلبات على مستويات مختلفة من التزامن: يزداد الحمل من 20 إلى 15000 مستخدم متزامن.

نتائج الاختبار

يوضح الرسم البياني التالي أداء الخوادم على بنيات مختلفة بمستويات مختلفة من التزامن. المحور ص هو عدد الطلبات في الثانية الواحدة ، المحور س هو اتصالات موازية.







يوجد أدناه جدول بالنتائج.


يمكن أن نرى من خلال الرسم البياني والجدول أنه فوق 8000 طلب في وقت واحد ، لم يتبق سوى لاعبين اثنين فقط: الشوكة المسبقة و epoll. مع نمو التحميل ، يؤدي الخادم المستند إلى الاستطلاع أداءً أسوأ من الخادم المتدفق. تتنافس بنية ما قبل الخيوط مع epoll: هذا دليل على مدى تخطيط Linux kernel لعدد كبير من الخيوط.

شفرة المصدر ZeroHTTPd

شفرة المصدر ل ZeroHTTPd هنا . كل هندسة لديها دليل منفصل.

  ZeroHTTPd
 │
 ├── 01_iterative
 ├── ├── main.c
 ├── 02_ فوركينج
 ├── ├── main.c
 _p 03_preforking
 ├── ├── main.c
 ├── 04_threading
 ├── ├── main.c
 _p 05_prethreading
 ├── ├── main.c
 ├── 06_poll
 ├── ├── main.c
 ├── 07_epoll
 └── └── main.c
 ├── Makefile
 ├── العامة
 index.html
 │ └── tux.png
 └── القوالب
     └── سجل الزوار
         └── index.html 

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

لإنشاء الخوادم السبعة ، شغِّل تشغيل make all من دليل المستوى الأعلى - وستظهر جميع الإنشاءات في هذا الدليل. تبحث الملفات التنفيذية عن الأدلة العامة والقوالب في الدليل من حيث يتم تشغيلها.

Linux API

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

الأداء وقابلية التوسع

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

وحدة المعالجة المركزية ومهام الإدخال / الإخراج

أخيرًا ، هناك دائمًا نوعان ممكنان من المهام في الحوسبة: I / O و CPU. تلقي طلبات عبر الإنترنت (شبكة I / O) ، وصيانة الملفات (الشبكة والقرص I / O) ، والتواصل مع قاعدة البيانات (الشبكة والقرص I / O) كلها إجراءات I / O. يمكن لبعض استعلامات قاعدة البيانات تحميل وحدة المعالجة المركزية قليلاً (الفرز ، وحساب متوسط ​​نتائج مليون ، إلخ). تقتصر معظم تطبيقات الويب على الحد الأقصى الممكن للإدخال / الإخراج ، ونادراً ما يتم استخدام المعالج بكامل طاقته. عندما ترى أن بعض وحدات المعالجة المركزية (CPU) تستخدم الكثير من وحدات المعالجة المركزية (CPUs) ، فمن المحتمل أن يكون هذا علامة على ضعف بنية التطبيق. قد يعني هذا أن موارد وحدة المعالجة المركزية يتم إنفاقها على التحكم في العملية وتبديل السياق - وهذا ليس مفيدًا تمامًا. إذا كنت تفعل شيئًا ما مثل معالجة الصور أو تحويل الصوت أو التعلم الآلي ، فإن التطبيق يتطلب موارد وحدة المعالجة المركزية قوية. ولكن بالنسبة لمعظم التطبيقات ، هذا ليس كذلك.

المزيد عن هياكل الخادم

1. الجزء الأول. الهندسة المعمارية التكرارية
2. الجزء الثاني خوادم الشوكة
3. الجزء الثالث. خوادم ما قبل الشوكة
4. الجزء الرابع خوادم مع المواضيع
5. الجزء الخامس. خوادم مع الخيط قبل الإنشاء
6. الجزء السادس. الاستطلاع بناء العمارة
7. الجزء السابع. العمارة Epoll