تمت مناقشة هذا المحتوى عدة مرات في مدونات cnblog. لقد قرأت بعض المعلومات في اليومين الماضيين ورأيت بعض مؤشرات الأداء البسيطة وناقشتها مع الجميع.
المقبس + المواضيع/ThreadPool
الأداء التقريبي: أقل من 1500 اتصال.
التنفيذ: اقبل المقبس واتركه لمؤشر الترابط لإدارته، وهو أمر غبي نسبيًا، ولكنه أيضًا أكثر فعالية لأنه طريقة متزامنة، وهو مناسب جدًا للتحكم فيه. والشيء الأكثر تقدمًا هو تسليمه إلى تجمع سلاسل الرسائل لإدارته، حيث تتم استضافة تجمع سلاسل الرسائل تلقائيًا بواسطة النظام، مما يوفر وقت سلاسل الرسائل العامة. بالنسبة للمشاريع الصغيرة العامة، هذا كافٍ تمامًا والتطوير بسيط. لكن انتبه إلى أنه إذا احتلت عدة مقابس سلاسل رسائل في تجمع سلاسل الرسائل لفترة طويلة وكان هناك العديد من الاتصالات الأخرى، فمن السهل الحصول على رسالة تفيد بأنه ليس لديك سلاسل رسائل كافية لاستخدامها. هاها، إنها فكرة جيدة أن تسمح لـSocket بعمل أقل وتستغرق وقتًا أقل. يعد التغيير إلى وحدة المعالجة المركزية الأسرع طريقة جيدة. بالإضافة إلى ذلك، إذا كانت هناك بعض مكونات تجمع مؤشرات الترابط الأفضل التابعة لجهات خارجية، فيمكنك أيضًا اختيار استخدامها، مثل SmartThreadPool.
المقبس + تحديد
الأداء التقريبي: ينخفض الأداء بعد أكثر من 1500 اتصال.
التنفيذ: التحديد هو نموذج شائع الاستخدام. إنه لاستقصاء مقبس واحد أو أكثر في وظيفة الحظر، ووضع المقبس المراد معالجته في قائمة IList. عند اكتمال الاستقصاء المحدد، سنقوم بعد ذلك بمعالجة المقبس في قائمة IList هذه بأنفسنا. لاستخدام محدد، يرجى الرجوع إلى MSDN. لا يمكن القول أن كفاءة التحديد عالية، لأنه عندما يكون هناك العديد من المقابس المراد معالجتها في قائمة الانتظار، فإن معالجة المقابس القليلة الأخيرة تعادل اجتياز جميع المقابس السابقة، وهو أمر غير اقتصادي للغاية.
المقبس + غير متزامن
الأداء التقريبي: حوالي 7500 اتصال عميل
التنفيذ: BeginXXXX، EndXXXX، نحن جميعًا على دراية به. في التحليل النهائي، لا يزال المقبس غير المتزامن يستخدم تقنية تجمع الخيوط، ويستخدم تجمع الخيوط لمعالجة الإدخال والإخراج غير المتزامن. وهذا يثير سؤالاً آخر، ما هي طريقة التنفيذ المستخدمة في تجمع مؤشرات الترابط الخاص بـ .NET؟ لقد رأيت شخصًا يقول قبل أن يتم تنفيذ تجمع سلاسل الرسائل الخاص بـ .NET باستخدام منافذ الإكمال. لا توجد طريقة لتأكيد ذلك من المعلومات التي وجدتها (آمل أن يخبرني أحد الأصدقاء بذلك). يعد المقبس غير المتزامن أكثر تعقيدًا من تدفق معالجة البرنامج المتزامن، كما أن التحكم في وظائف رد الاتصال غير المتزامن ليس بديهيًا مثل الطريقة المتزامنة. ولكن هناك شيء واحد أعتقد أنه يجب ملاحظته وهو أنه يجب استخدام وظيفة رد الاتصال بشكل خفيف ويجب ألا تتعامل مع عدد كبير جدًا من المعاملات، ويجب ترك معالجة البيانات المنقولة لسلاسل رسائل أخرى للمعالجة.
IOCP (منفذ الإكمال)
الأداء التقريبي: حوالي 20.000 إلى 50.000 اتصال عميل
. التنفيذ: هناك بعض IOCPs الزائفة ضمن .NET. لم أر أي أمثلة SOCKET مفتوحة تم تنفيذها باستخدام IOCPs الزائفة. تشير اتصالات العميل التي يتراوح عددها بين 20.000 إلى 50.000 والتي أتحدث عنها إلى حالة التطوير في ظل C++، وفي هذه الحالة، تتضمن التقنيات الأساسية التي يجب استخدامها مجمعات الذاكرة وخوارزميات الاستعلام وما إلى ذلك.
لا توجد معلومات للتحقق من الحد الأقصى لعدد الاتصالات التي يمكن أن يحققها IOCP الزائف، إذا كان أي شخص يعرف، يمكنك مناقشة الأمر. بالإضافة إلى ذلك، فإن العديد من البيانات المذكورة أعلاه مقتبسة من بعض المعلومات التي لم أجرّبها بنفسي، فأنا فقط أطرحها للمناقشة مع الجميع. أعتقد أن برنامج خادم عالي الأداء قد يتطلب تقنية لا تتعلق فقط بالنموذج الذي يجب استخدامه، ولكن أيضًا بالعديد من التفاصيل التي يجب الانتباه إليها، مثل معالجة الذاكرة، والخوارزمية التي يجب استخدامها، وما إلى ذلك. بالطبع، هذا هو فقط من حيث تكلفة البرمجيات سيكون هناك بالتأكيد استثمار في الأجهزة.