Ce qui suit est une comparaison de plusieurs protocoles de communication couramment utilisés et des performances des protocoles en langage Java
1.RMI
Appel RMI Comme prévu, RMI est bien sûr le plus rapide, prenant le moins de millisecondes dans presque tous les cas. Surtout lorsque la structure des données est complexe et que la quantité de données est importante, l'écart avec les autres protocoles est particulièrement évident. Afin de tirer pleinement parti des performances de RMI, nous avons créé une classe de test distincte sans utiliser Spring, en utilisant le formulaire RMI d'origine (héritant de l'objet UnicastRemoteObject) pour fournir des services et effectuer des appels à distance, et comparer l'efficacité avec le RMI de Spring fourni par POJO. Les résultats montrent que les deux sont fondamentalement identiques et que le service fourni par Spring est légèrement plus rapide. On pense initialement que cela est dû au fait que les mécanismes de proxy et de mise en cache de Spring sont relativement puissants, ce qui permet de gagner du temps lors de la réacquisition des objets.
2. Hessian
Hessian appelle le serveur de résine de la société Caucho, qui est connu comme le serveur le plus rapide et jouit d'une certaine réputation dans le domaine Java. En tant que composant de la résine, la conception de Hessian est également très simple et efficace, et le fonctionnement réel l'a prouvé. En moyenne, Hessian est environ 20 % plus lent que RMI, mais cela ne peut se refléter que lorsque la quantité de données est particulièrement importante et que la structure des données est complexe. Lorsqu'il y a des quantités de données moyennes ou petites, Hessian n'est pas plus lent que RMI. L'avantage de Hessian est qu'il est rationalisé et efficace, qu'il peut être utilisé dans plusieurs langues et que les spécifications du protocole sont publiques. Nous pouvons développer des implémentations de ses protocoles pour n'importe quelle langue. Les langages actuellement implémentés incluent : java, c++, .net, python et ruby. Il n’y a pas encore d’implémentation de Delphi. De plus, Hessian s'intègre très bien au serveur WEB. Grâce à la fonction de serveur WEB, il aura de grands avantages dans la gestion des accès simultanés d'un grand nombre d'utilisateurs. garanti par un serveur WEB mature. RMI lui-même ne fournit pas de serveur multithread. De plus, RMI doit ouvrir un port de pare-feu, mais pas Hessian.
3.Jurlap
Jurlap et Hessian sont tous deux des produits open source de la société caucho, mais Hessian utilise le format binaire, tandis que Burlap utilise le format XML. Les résultats des tests montrent que l'efficacité de Burlap est toujours acceptable lorsque la structure des données n'est pas complexe et que la quantité de données est moyenne, mais si la quantité de données est importante, l'efficacité chutera fortement. En moyenne, le temps d'appel de Burlap par milliseconde est trois fois supérieur à celui de RMI. Je pense qu'il y a deux raisons à sa faible efficacité. La première est qu'il y a trop de contenus de description de données XML et que le volume de transmission de la même structure de données est beaucoup plus important. D'un autre côté, comme nous le savons tous, l'analyse XML est relativement importante. gourmand en ressources, en particulier Cela est particulièrement vrai pour les gros volumes de données.
4.HttpInvoker
HttpInvoker est la méthode d'appel à distance JAVA fournie par Spring Framework, qui utilise le mécanisme de sérialisation de Java pour gérer la transmission d'objets. À en juger par les résultats des tests, son efficacité est toujours acceptable, fondamentalement la même que celle du RMI. Cependant, il ne peut être utilisé que pour la communication entre les langages JAVA, et le client et le serveur doivent utiliser le framework SPRING. De plus, HttpInvoker n’a pas été testé en pratique et il n’existe actuellement aucun projet appliquant ce protocole.
5.web service
Ce test a sélectionné le composant AXIS d'Apache car l'implémentation d'AXIS est relativement mature et établie dans le domaine du WEB SERVICE. Afin de tester uniquement l'heure de transmission, de codage et de décodage des données, le client et le serveur utilisent la mise en cache, et l'objet ne doit être instancié qu'une seule fois. Cependant, les résultats des tests montrent que l'efficacité du service Web est encore 10 fois plus lente que celle des autres protocoles de communication. Si l’on prend en compte le transfert de plusieurs références pointant vers le même objet, les services web sont encore plus en retard. Parce que RMI, Hessian et d'autres protocoles peuvent transmettre des références, et le nombre de références d'un service Web dépend du nombre de copies d'entités d'objet dont il dispose. La trop grande quantité d'informations redondantes transmises par le service Web est l'une des raisons de sa lenteur. Monitoring a constaté que pour la même demande d'accès décrivant les mêmes données, la quantité de données renvoyées par le service Web est 6,5 fois supérieure à celle du protocole Hessian. De plus, le traitement du WEB SERVICE prend également beaucoup de temps. L'analyseur XML actuel n'est généralement pas efficace et le traitement des beans XML <-> D'après les résultats des tests, les appels à distance sont plus rapides que les appels locaux, ce qui montre également que le temps est principalement consacré à l'encodage et au décodage des fichiers XML. C'est plus grave que les informations redondantes. Les informations redondantes n'occupent que la bande passante du réseau et la consommation de ressources de chaque appel affecte directement la capacité de charge du serveur. (Les ingénieurs MS ont dit un jour que WEB SERVICE ne peut pas charger plus de 100 utilisateurs simultanés.) Au cours du test, il a également été constaté que le codage des services Web n'est pas très pratique. Pour les types non basiques, les classes de sérialisation et de désérialisation doivent être enregistrées une par une. un, qui est très difficile, la génération de stub est plus fatigante et pas aussi fluide et concise que le traitement spring + RMI/hessian. De plus, le service Web ne prend pas en charge les types de collections et ne peut utiliser que des tableaux, ce qui n'est pas pratique.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!