مقارنة أداء Thrift و Protocol Buffers و JSON و EJB وغيرها؟

StackOverflow https://stackoverflow.com/questions/296650

سؤال

نحن نبحث في حلول النقل/البروتوكولات وكنا على وشك إجراء اختبارات أداء متنوعة، لذلك فكرت في مراجعة المجتمع إذا كانوا قد قاموا بذلك بالفعل:

هل قام أي شخص بإجراء اختبارات أداء الخادم لخدمات الصدى البسيطة بالإضافة إلى التسلسل/إلغاء التسلسل لأحجام الرسائل المختلفة مقارنة EJB3 وThrift وProtocol Buffers على Linux؟

اللغات الأساسية ستكون Java وC/C++ وPython وPHP.

تحديث:ما زلت مهتمًا جدًا بهذا الأمر، إذا قام أي شخص بإجراء أي معايير أخرى، فيرجى إبلاغي بذلك.أيضا، عرض مرجعي مثير للاهتمام للغاية أداء JSON المضغوط مشابه / أفضل من المخازن المؤقتة Thrift / Protocol, ، لذلك أطرح JSON في هذا السؤال أيضًا.

هل كانت مفيدة؟

المحلول

وأحدث المقارنة المتاحة هنا في الادخار-protobuf-مقارنة يكي المشروع. وهو يتضمن العديد من المكتبات التسلسل الأخرى.

نصائح أخرى

وأنا في عملية كتابة بعض التعليمات البرمجية في مشروع مفتوح المصدر اسمه الادخار -protobuf-مقارنة مقارنة بين protobuf والادخار. أما الآن فإنه يغطي بعض الجوانب التسلسل، ولكن أنوي لتغطية أكثر من ذلك. نتائج (ل التوفير و <لأ href = "HTTP: //eishay.blogspot. وتناقش كوم / بحث / التسمية / protobuf "يختلط =" noreferrer "> protobuf ) في بلدي بلوق، سأضيف أكثر عندما سأحضر إليها. قد نظرتم الى رمز للمقارنة API، لغة وصف والشفرة التي تم إنشاؤها. سأكون سعيدا لمساهمات لتحقيق المقارنة أكثر تنوعا.

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

لما يستحق، وجدت الأداء PB أن يكون قليلا على فقت (عادة وليس من قبل واضعيه، ولكن الآخرين الذين لا يعرفون سوى الذي كتب عليه). مع الإعدادات الافتراضية أنها لم تغلب أسرع بديل نصية أكس. مع الوضع الأمثل (لماذا هذا التقصير لا؟)، وكان أسرع قليلا، مقارنة مع أسرع حزمة JSON. كان هسه سريع بدلا من ذلك، النص سلمان أيضا. كان تنسيق ثنائي Properietary (أي اسم هنا، كان الداخلية للشركة) أبطأ. كان جافا وجوه التسلسل السريع للرسائل أكبر، وأقل من ذلك لكائنات صغيرة (أي ارتفاع ثابت لكل عملية noverhead). مع حجم الرسالة PB كان الاتفاق، ولكن نظرا جميع المفاضلات ما عليك القيام به (البيانات غير وصفي النفس: إذا فقدت المخطط تفقد البيانات، وهناك مؤشرات وبطبيعة الحال، وأنواع القيمة، ولكن من ما لديك هندسة العكسية إلى أسماء الحقول إذا كنت تريد)، وأنا شخصيا سوف تختار فقط لحالات الاستخدام المحددة -، إلى جانب نظام كثب حساسة للحجم حيث واجهة / الشكل أبدا (أو نادرا جدا جدا) التغييرات

ورأيي في هذا هو أن (أ) غالبا ما يهم تنفيذ أكثر من مواصفات (من تنسيق البيانات) و (ب) نهاية إلى نهاية، والاختلافات بين أفضل من سلالة (لصيغ مختلفة) وعادة ما تكون ليست كبيرة بما فيه الكفاية لإملاء هذا الاختيار. وهذا هو، قد تكون أفضل حالا شكل + API / ليب / إطار اختيار لك مثل استخدام معظم (أو لديه أفضل أداة دعم)، والعثور على أفضل تنفيذ، ونرى ما اذا كان يعمل بسرعة كافية. إذا (وفقط إذا!) لا، والنظر في القادم أفضل بديل.

وفرع فلسطين. غير متأكد ما EJB3 هنا سيكون. ربما مجرد جافا التسلسل؟

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

عند التي تم القيام به، كنت أتصور هل يمكن بناء نفسها الرسائل في التوفير ثم قارن الأداء.

وبعبارة أخرى، ليس لدي البيانات لديك حتى الآن - ولكن نأمل في الاسبوعين المقبلين ...

إذا كان أداء الشبكة الخام هو الهدف، فلا شيء يتفوق على IIOP (راجع RMI/IIOP).أصغر مساحة ممكنة - بيانات ثنائية فقط، بدون علامات على الإطلاق.التسلسل/إلغاء التسلسل سريع جدًا أيضًا.

نظرًا لأنه IIOP (أي CORBA)، فإن جميع اللغات تقريبًا لها روابط.

ولكن أفترض أن الأداء ليس هو فقط الشرط، أليس كذلك؟

لدعم وجهة نظر فلاديمير حول IIOP، إليك اختبار أداء مثير للاهتمام، والذي من شأنه أن يوفر بعض المعلومات الإضافية حول معايير Google، لأنه يقارن بين Thrift وCORBA.(Performance_TIDorb_vs_Thrift_morfeo.pdf // الرابط لم يعد صالحا) للاقتباس من الدراسة:

  • التوفير فعال للغاية مع الصغيرة البيانات (الأنواع الأساسية كعملية الحجج)
  • عمليات نقل التوفير ليست فعالة مثل CORBA مع المتوسطة و البيانات الكبيرة (البنية والمعقدة > أنواع > 1 كيلو بايت).

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

ومن المثير للاهتمام أن Thrift IDL يتطابق بشكل وثيق مع CORBA IDL، وهو أمر لطيف.لم أستخدم Thrift، فهو يبدو مثيرًا للاهتمام خاصة بالنسبة للرسائل الصغيرة، وكان أحد أهداف التصميم هو التثبيت الأقل تعقيدًا، لذا فهذه هي المزايا الأخرى لـ Thrift.ومع ذلك، فإن CORBA له سمعة سيئة، وهناك العديد من التطبيقات الممتازة مثله omniORB على سبيل المثال، التي تحتوي على روابط لـ Python، وهي سهلة التثبيت والاستخدام.

تم التعديل:لم يعد رابط Thrift وCORBA صالحًا، لكنني وجدت ورقة بحثية أخرى مفيدة من CERN.قاموا بتقييم البدائل لنظام CORBA الخاص بهم، وأثناء قيامهم بذلك تقييم الادخار, ، ذهبوا في النهاية مع ZeroMQ.في حين كان أداء Thrift هو الأسرع في اختبارات الأداء، حيث بلغ 9000 msg/sec مقابل 9000 msg/sec.8000 (ZeroMQ) و7000+ RDA (المعتمد على CORBA)، اختاروا عدم اختبار التوفير بشكل أكبر بسبب مشكلات أخرى أبرزها:

لا يزال منتجًا غير ناضج مع تنفيذ عربات التي تجرها الدواب

لقد قمت بإجراء دراسة حول تكامل Spring-Boot ومصممي الخرائط (يدويًا وDozer وMapStruct) وThrift وREST وSOAP وProtocol Buffers في وظيفتي.

جانب الخادم: https://github.com/vlachenal/webservices-bench

جانب العميل: https://github.com/vlachenal/webservices-bench-client

لم يتم الانتهاء منه وتم تشغيله على أجهزة الكمبيوتر الشخصية الخاصة بي (يجب أن أطلب خوادم لإكمال الاختبارات) ...ولكن يمكن استشارة النتائج على:

كنتيجة :

  • يوفر Thrift أفضل أداء وسهل الاستخدام
  • خدمة الويب RESTful مع نوع محتوى JSON قريبة جدًا من أداء Thrift، وهي "متصفح جاهز للاستخدام" وأنيقة جدًا (من وجهة نظري)
  • يتمتع SOAP بأداء ضعيف جدًا ولكنه يوفر أفضل تحكم في البيانات
  • تتمتع مخازن البروتوكول المؤقتة بأداء جيد ...حتى 3 مكالمات متزامنة...وأنا لا أعرف لماذا.من الصعب جدًا استخدامه:أستسلم (في الوقت الحالي) لكي يعمل مع MapStruct ولا أحاول مع Dozer.

يمكن إكمال المشاريع من خلال طلبات السحب (إما للإصلاحات أو لنتائج أخرى).

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top