ما مدى سرعة RMI؟

Question

لقد رأيت السؤال: التواصل بين اثنين من تطبيقات سطح المكتب Java منفصلة (الإجابة: JGroups) وأنا أفكر في تنفيذ شيء مع Javagrups أو RMI المستقيم ولكن السرعة من الجوهر. أنا لا أرسل كميات كبيرة من البيانات حولها (محتوى رسائل MIDI ، لذلك 3 بايت لكل منها ، لا أكثر من قول رسالتين كل ثلاثة مللي ثانية) وسيكون كل هذا على نفس الجهاز. هل من المعتقد أن RMI/JGROUPS على نفس الآلة المادية ستكون بطيئة؟

(فكرتي هي أنني لا أستطيع تحمل أكثر من 1 مللي ثانية من الكمون ، لأنني حصلت بالفعل على بعض ، لكنني لست متأكدًا من أفضل طريقة التحدث عن السرعة في هذا السياق.)

أعتقد أن سؤالي الحقيقي هو: هل هناك أي خيارات للتواصل interapp في Java تمر بشيء أسرع من TCP/IP؟ أعني الأشياء التي تم تنفيذها بالفعل في Java ، وليس إمكانيات JNI التي أحتاج إلى تنفيذها :)

أعلم ، لا تحسن مبكرًا وكل ذلك ، ولكن أيضًا أفضل من آسف.

Answer 1

هل هناك أي خيارات للتواصل interapp في Java تمر بشيء أسرع من TCP/IP؟

ليس بشكل كبير ... afaik.

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

طريقة الحصول على إنتاجية أكبر هي التركيز على ما يلي:

• تقليل عدد RPCs التي يتطلبها التطبيق ؛ على سبيل المثال ، من خلال الجمع بينهم ليكونوا أكثر الحبيبات الخشنة ، و

• النظر في طرق لتحويل التفاعلات المتزامنة إلى تفاعلات غير متزامنة ؛ على سبيل المثال ، استخدام الرسائل المستندة إلى التقنيات القائمة على RPC.

Answer 2

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

ومع ذلك ، بافتراض أن السرعة ليست مهمة تمامًا ، يمكنك إجراء مكالمات Java RMI في حوالي 500 ثانية صغيرة واستخدام RPC المشفرة المخصصة ، يمكنك إجراء مكالمات على الاسترجاع في حوالي 24 ثانية صغيرة. حتى تمرير البيانات بين مؤشرات الترابط في نفس JVM يمكن أن تأخذ 8 ثوانٍ صغيرة.

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

ملاحظة: أنا أتحدث عن ثانية صغيرة هنا ، وليس ميلي ثانية. أود أن أتجاهل أي خيارات تستغرق عدة مللي ثانية لأغراضك.

Answer 3

هذا المعيار يبلغ عمره حوالي عامين تقريبًا ، لكنه يدل على أن حل Java الشهير الوحيد بشكل أسرع من RMI هيسيان 2(الذي لا يزال في بيتا أعتقد).

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

Answer 4

هل من المعتقد أن RMI/JGROUPS على نفس الآلة المادية ستكون بطيئة؟

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

ما يلي هو الوقت الذي يتم فيه الاستغناء عن المللي ثانية باستخدام Nanotime في نفس JVM لإرسال السلسلة "123" باستخدام RMI وعلى الخادم CONSS مع "ABC" للحصول على "123ABC" وإعادتها.

بارد JVM: حوالي 0.25 مللي ثانية زمن انتقال

0.250344
0.262695
0.241540
0.282461
0.301057
0.307938
0.282102

دافئ JVM: حوالي 0.07 مللي ثانية زمن انتقال.

0.87916
0.72474
0.73399
0.64692
0.62488
0.59958
0.59814
0.66389

لذلك ستكون جيدًا في غضون 1 مللي ثانية إذا كان خادم RMI والعميل يعمل محليًا.