À quelle vitesse RMI peut-il être?

Question

J'ai vu la question: Communication between two separate Java desktop applications (réponse: JGroups) et je pense à implémenter quelque chose avec JavaGroups ou RMI mais la vitesse est essentielle. Je n'envoie pas de grandes quantités de données (contenu de messages MIDI, donc 3 octets chacun, pas plus de deux messages toutes les trois millisecondes) et tout sera sur la même machine. Est-il stupide de penser que RMI/JGroups sur la même machine physique sera lent?

(Ma pensée est que je ne peux pas se permettre plus de 1ms de temps d'attente, puisque je l'ai déjà eu quelques-uns, mais je ne suis pas sûr de savoir comment mieux parler de la vitesse dans ce contexte.)

Je suppose que ma vraie question est: y at-il des options pour la communication interapp en Java qui passent par quelque chose de plus rapide que TCP/IP? Je veux dire des choses déjà implémentées en Java, pas des possibilités JNI que je devrais implémenter :)

Je sais, ne pas optimiser tôt et tout ça, mais aussi mieux prévenir que guérir.

Answer 1

Existe-t-il des options de communication interapp en Java qui passent par quelque chose de PLUS RAPIDE que TCP/IP?

Pas de manière significative ... AFAIK.

Mais je pense que vous y réfléchissez mal. En supposant que vous déplacez de petits messages, le principal tueur de performance sera les frais généraux de faire un appel plutôt que la vitesse à laquelle les octets sont déplacés. Ces frais incluent le temps nécessaire pour effectuer des appels système, pour changer les contextes de processus côté client et serveur, pour traiter les en-têtes des paquets de messages dans le noyau et pour router les paquets. Et toute interaction synchrone de type RPC implique de faire un appel dans l'attente de la réponse; c'est-à-dire l'application -> serveur -> temps aller-retour.

La manière d'obtenir un plus grand débit est de se concentrer sur les points suivants:

• réduisant le nombre de RPCs requis par l'application; par exemple. en les combinant pour avoir une structure plus grossière, et

• d'examiner les moyens de transformer des interactions synchrones en interactions asynchrones; par exemple. en utilisant des technologies basées sur les messages plutôt que sur les RPC.

Answer 2

This benchmark est d'environ deux ans, mais il montre que la seule solution populaire Java Remoting plus rapide que RMI est Hessian 2 (qui est encore en beta je crois). Toutefois, si vos messages sont uniquement composés d'octets à un seul chiffre, l'utilisation d'une solution d'accès distant semble être excessive, en particulier si les processus sont sur la même machine. Je recommande de les consolider en un seul processus si possible. Vous pouvez également envisager d'utiliser plain old Java sockets.

Answer 3

Si la vitesse est de l'essence, vous devriez faire l'appel dans le même fil. Vous n'obtiendrez pas aussi vite que cela en utilisant un réseau. Cependant, en supposant que la vitesse ne soit pas très importante, vous pouvez effectuer des appels Java RMI en environ 500 micro-secondes et en utilisant RPC codé personnalisé, vous pouvez faire des appels sur le bouclage en environ 24 micro-secondes. Même le transfert de données entre threads dans la même JVM peut prendre 8 micro-secondes.

Vous devez décider combien de temps vous êtes prêt à autoriser pour passer un appel réseau. Vous devez également décider si l'heure de début de l'appel est critique ou si vous devez renvoyer un résultat. (Souvent, ce dernier a le double de la surcharge)

Note: Je parle de micro-seconde ici, pas de milli-secondes. Je voudrais ignorer toutes les options qui prennent plusieurs millisecondes pour vos besoins.