Contrairement à ce que tu penses, il est très facile de me convaincre, mais seulement avec des faits, des choses vérifiables.
En informatique on a la chance de pouvoir expérimenter à peu de frais et surtout d'avoir des systèmes complètements déterministes.
Bref, une explication technique, un bout de code, un résultat de benchmark, je suis preneur.
Un discours marketing ou un truc tiré de la "doc" d'un vendeur, non merci.
Quand Hazelcast dit que pour éviter d'avoir à utiliser plusieurs JVM (qui selon eux est un moyen d'éviter les problèmes de lags liés aux GC), ils préconisent leur solution "Hazelcast IMDG Enterprise HD", tu devrais te poser des questions.
Manque de bol, le Java et les performances, je peux t'en parler des heures (et te sourcer ou montrer par du code, tout ce que je j'avance). En 2001 j'ai commencé à faire du Java sérieusement avec la version 1.1.8 sur de l'embarqué (settopbox) avec 8Mo de mémoire et un processeur à 50MHz (et ca tournait nickel), je n'ai jamais arrêté de faire du Java depuis (en plus de bien d'autres langages).
Hazelcast fait références aux premiers GCs qui mettaient en pause la JVM, d'où un "lag" (voir https://www.baeldung.com/jvm-garbage-collectors pour les différents GC). Le problème est réglé depuis des années, avec par exemple le GC "G1". Aujourd'hui une application qui est ralentie par un GC est une application qui alloue à tout va avec une gestion de la mémoire mal ou pas pensée du tout.
Pour les protocoles texte vs binaire, effectivement je ne pense pas être convaincu que tout un tas de projets utilisent un protocole binaire et pas texte, car ils leurs développeurs aiment la complexité et introduire des bugs dans les "clients" (argument Redis).
Pour moi, il n'y a pas difficulté à utiliser un protocole binaire, et le gain en bande passante (entre x2 et x4) et en performance est tellement important que cela permet d'en faire plus avec un même matériel ou quantité d'énergie.
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Contrairement à ce que tu penses, il est très facile de me convaincre, mais seulement avec des faits, des choses vérifiables.
En informatique on a la chance de pouvoir expérimenter à peu de frais et surtout d'avoir des systèmes complètements déterministes.
Bref, une explication technique, un bout de code, un résultat de benchmark, je suis preneur.
Un discours marketing ou un truc tiré de la "doc" d'un vendeur, non merci.
Quand Hazelcast dit que pour éviter d'avoir à utiliser plusieurs JVM (qui selon eux est un moyen d'éviter les problèmes de lags liés aux GC), ils préconisent leur solution "Hazelcast IMDG Enterprise HD", tu devrais te poser des questions.
Manque de bol, le Java et les performances, je peux t'en parler des heures (et te sourcer ou montrer par du code, tout ce que je j'avance).
En 2001 j'ai commencé à faire du Java sérieusement avec la version 1.1.8 sur de l'embarqué (settopbox) avec 8Mo de mémoire et un processeur à 50MHz (et ca tournait nickel), je n'ai jamais arrêté de faire du Java depuis (en plus de bien d'autres langages).
Hazelcast fait références aux premiers GCs qui mettaient en pause la JVM, d'où un "lag" (voir https://www.baeldung.com/jvm-garbage-collectors pour les différents GC). Le problème est réglé depuis des années, avec par exemple le GC "G1". Aujourd'hui une application qui est ralentie par un GC est une application qui alloue à tout va avec une gestion de la mémoire mal ou pas pensée du tout.
Pour les protocoles texte vs binaire, effectivement je ne pense pas être convaincu que tout un tas de projets utilisent un protocole binaire et pas texte, car ils leurs développeurs aiment la complexité et introduire des bugs dans les "clients" (argument Redis).
Pour moi, il n'y a pas difficulté à utiliser un protocole binaire, et le gain en bande passante (entre x2 et x4) et en performance est tellement important que cela permet d'en faire plus avec un même matériel ou quantité d'énergie.