Guillaume Maillard a écrit 274 commentaires

G1 a encore quelques parties du GC qui requièrent de tout stopper, mais rien à voir avec les premiers GC où tout était fait pendant la pause.

G1 : 128 Go de Heap, en moyenne 250ms
(faut tout de même y aller fort pour allouer 128Go non stop :) )
Les GC ZGC et Shenandoah font encore mieux.
ZGC : moins d'une milliseconde pour 2To…
(Voir https://archive.fosdem.org/2018/schedule/event/zgc/attachments/slides/2211/export/events/attachments/zgc/slides/2211/ZGC_FOSDEM_2018.pdf )

(on peut donc donner raison à Hazelcast pour ceux qui n'utilisent pas ZGC, et remplissent la mémoire vive leur serveur avec 2To de heap)

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.

Quel cache ?
Ma phrase aurait pu être plus claire, je faisais référence à un cache que tu ferrais toi même avec une hash table ou équivalent, c'est à dire un cache local à l'application.

Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).
Pour la fragmentation, au contraire, plus l'espace mémoire disponible est grand, moins elle est un problème puisque mécaniquement les espaces contigus libre sont importants.

"faux problème"
Ce n'était pas de la rhétorique, je trouvais arbitraire de définir cela comme un problème, d'où mon explication du pourquoi ça ne pose pas de problèmes.

Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.

Encore une fois, écrire un driver pour un protocole binaire n'a rien de difficile (par rapport à un protocole ascii) si le protocole est documenté.
De plus tu n'as (quasiment) jamais à le faire car les principaux langages ont tous leurs drivers officiels.

J'avais envie de te dire que le fait que le driver VB n'existe pas pour MongoDB, n'est un manque pour personne, mais en fait, ce driver existe (https://consulity.net/content/consulity-InstallMongoDB.aspx), idem pour Cassandra. Les chiffres sont donc à ajuster.

De plus, sachant qu'il n'y a pas de driver pour COBOL pour ces bases NoSQL, quelle corrélation y vois tu?

Peut-être parce que l'informatique ce n'est pas qu'une unique question de logiciels

Oui, assurément mais, à mon humble avis, tu vas un peu loin sur les aspects de gestion de la vieillesse des systèmes, des aspects légaux,… tu as le même problème avec une automobile, un jour tu ne trouves plus les pièces, elle doit respecter des contraintes légales de sécurité…
Et vu le nombre de logiciels dans ma voitures, dois-je conclure que je fais de l'informatique en l'utilisant?

Le cache devient la clé de voûte

N'est ce pas dangereux si ce cache n'est pas persistent?
N'est ce pas dangereux si ce cache n'est pas transactionnel?

Le cache … sert à maintenir des connexions à des bases de données, à alerter sur une situation anormale

Tu parles toujours d'un service de cache comme Robert/Redis ?

Oups, encore quelques nouveaux points que je ne comprend pas:

Un cache ça sert à stocker le résultat d'un traitement pour y accéder plus rapidement. Tant que le traitement en question est significativement plus long que la lecture depuis cette base de données, ça peut rester pertinent.

Du coup, dans ce cas, les performances apportées par le service de cache ne serviront à rien car un cache local ferra le boulot, non?

un système d'exploitation préfère avoir 2 processus de 4Gio qu'un seul de 8

A quoi fais tu référence? Les performances sont meilleures si l'on utilise les processus à la place des threads, où de stabilité, de consommation mémoire ?
Je loupe surement quelques choses, car il "semble" (https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/) que les threads sont plus rapides à démarrer que les processus, et le temps de "context switch" est plus court pour les threads.

tu peux ne pas avoir le choix, comme je le disais plus haut avec PHP..

Il est possible de le faire en PHP, voir https://www.php.net/manual/en/book.shmop.php

tu peux vouloir que ton cache survive à un redémarrage de ton applicatif

Pourquoi pas, en effet (souvent les caches c'est le premier truc que tu veux virer au démarrage d'une appli pour être dans un état connu,donc à priori, stable).

tu peux vouloir que ton applicatif scale

Oui, mais on sort du cas "1 serveur", mes remarques n'étaient que sur ce cas d'utilisation.
On est bien d'accord qu'un cluster, Redis/Robert ont leur utilité.

simplifier la vie des développeurs pour ne pas avoir toi même à créer un client

Ce "problème" (ou "faux problème"), tu l'as pour les bases de données sous le nom de "driver" JDBC/ODBC/etc… développés et fournis par les développeurs des bases de données.

Borg est sans conteste LA solution à mettre en place pour qui cherche une sauvegarde cryptée.

C'est important de désactiver la compression au niveau ssh, les données chiffrées sont quasi incompressibles si le chiffrage est bon, inutile donc de ralentir le transfert pour rien (vu que les processeurs de NAS sont rarement très véloces).

Non, ce n'est pas ce que je voulais dire, dit autrement : l'argument de popularité pour justifier que quelque chose est bien ou bon, n'est pas un bon argument (mais un biais courant, cf https://fr.wikipedia.org/wiki/Argumentum_ad_populum).

C'est un peu brutal, de résumer par "les choses ne te plaisent pas tant pis pour toi",
quand aux problèmes précis de bande passante et processeur utilisées,
tu bifurques par "face à d'autres avantages", sans les mentionner ni les évaluer.
Idem pour la non difficulté de multi-thread'er et de gérer la concurrence d'une "map" dans le contexte d'un seul serveur.

Est ce que qu'on parle toujours informatique avec quelque chose d'aussi flou que :

"pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes"

Contrairement à ce que tu penses, cela m’intéresse de comprendre pourquoi on a arrive à des architectures logicielles compliquées pour des résultats catastrophiques sans que personne ne se remette en question (d'où les quelques exemples cités).

Si je comprend bien, une application avec des threads et faire attention à la consommation en bande passante et CPU, c'est considéré comme difficile à faire correctement ou long à écrire.
Du coup, est utilisée la solution la moins mauvaise, et tout le monde s'en félicite car c'est la plus utilisée ("auto congratulation" garantie).

N'as tu pas une petite liste dans un coin des technos/logiciels bien mauvais que tout le monde utilise?
Démontrant ainsi que la popularité n'a rien à voir avec la qualité?

Concernant Redis, les avantages présentés sont "la facilité d'implémentation par les clients qui résulte d'une diminution de bugs".
Dans le même genre, on a MySQL, LA base de données qui par défaut ne détectait pas d'erreur de type… si on insérait un entier dans un champs "VARCHAR", sans la moindre difficulté. Surement aussi "par facilité d'usage". A priori, toujours n°1 : https://www.eversql.com/most-popular-databases-in-2018-according-to-stackoverflow-survey/

Bref, l'idée n'est pas de donner des leçons ou d'arriver avec mes gros sabots; j'en ai juste un peu marre de voir l'informatique partir en vrille année après année, conséquence d'un "jenfoutisme" global, ou tout est histoire de mode, ou tout est recrée sans cesse en moins bien.

Aujourd'hui je peste parce que l'éditeur de texte par défaut d'Ubuntu prend 30 secondes pour enregistrer 20Mo, dans 5 ans, ça sera peut être en 5 secondes. Restons "optimistes".
Dans le genre, petite dédicace à Sage, éditeur à 1Md de CA, qui ne voit pas non plus le problème quand son logiciel phare de gestion prend 3 jours (oui, 3 jours) pour exporter une liste d'article de 3Mo.

"Ils ont considéré que le gain en performance ne valait pas les autres avantages" ?

Le cas de Redis est intéressant, la page doc se termine par :
"While comparable in performance to a binary protocol the Redis protocol is significantly simpler to implement in most very high level languages, reducing the number of bugs in client software."

C'est écrit donc c'est vrai?
Personne n'est donc plus "au courant" que par exemple le nombre 2 milliards, transféré en ascii va prendre 10 octets, et en binaire seulement 4 octets?
Et que dire du temps CPU pour convertir l'ascii ?

Je ne vois pas l’intérêt de Redis pour un seul serveur, une librairie faisant le même boulot, ne suffirait-elle pas?
A moins que l'on considère que l'appel d'une fonction est "comparable" à l'appel d'un service réseau.
Apres je conçois très bien que l'on puisse avoir différents processus souhaitant discuter avec une "map" unique. Mais autant minimiser le coût des 'appels'.

Bref, ce que fais Redis en réseau peut très bien être fait par une l'utilisation d'une librairie pour les besoins que tu précises (optimisation pour les gros volumes, fragmentation, …) sans requérir un service.

libRobert.so ? ;)

Merci pour cette réponse bien détaillée et étayée sur… la gestion des systèmes d'information.

Ce qui, pour moi et pour le Larousse, n'a RIEN à voir avec l'informatique.

C'est avec ce melimelo que l'on se retrouve avec tout un tas de gens qui pense faire de l'informatique quand ils utilisent Excel. Au final, le DSI c'est celui qui a su dépanner un PC et réinstaller le Windows sur le PC du patron.
Le même DSI qui va monter en "compétences" abreuvé de stratégie "isomorphe à l’organisation et aux circuits d’information formalisés et non-formalisés".
C'est encore pire dans les grosses boîtes, car ils sont formés à l'école pour cela.

J'ai pas mal d'exemples de clients, de conseils régionaux, banques, société du CAC40 et multinationales (dans lesquels j'ai bossé ou ai des amis dans ces structures); dans les faits on y trouve la pire informatique du monde, certains quittent à peine Windows XP, d'autres se font hacker dans les grandes largeurs, d'autres ont quasiment un serveur pour 10 employés (car le cloud c'est cool, les micro-services aussi…)
La crise sanitaire actuelle a aussi démontrée que les "grandes" DSI se montrent incapables de gérer le télétravail.

Je nuancerais aussi ton constat sur le besoin de performances, car sauf erreurs, Google, Amazon et Microsoft ont au total des millions de serveurs, ceux sont les plus gros consommateurs de bande passante et de CPU au monde.
Bref, ils ont la plus grande partie des serveurs produits, leur faire gagner 1% de performance ou diminuer la bande passante, c'est toucher le jackpot.
Tu comprends donc pourquoi je tique fortement sur le fait de recommander Python, qui peut être 30x plus lent que le C/C++/Rust/Java/C#… cf les benchmarks cités plus haut.
De plus, accepter de perdre 5% de performance ici et la, fait qu'au final (à force d'empiler les services, frameworks, librairies,…) on accepte que l'utilisation des ordinateurs se dégrade non-stop, alors que les performances du matériel soient en constante progression.

Pour la petite histoire, aujourd'hui un collègue a utilisé l'éditeur de texte par défaut de son Ubuntu (19.10) pour modifier un fichier SQL de 20Mo (sur un PC i5 gen9, 32 Go de RAM, SSD nVme), 40 secondes pour sauvegarder le fichier modifié de 10 caractères.
Je trouve cela lamentable, un PC d'il y a 20 ans permettait de modifier ce genre de minuscule fichier et de le sauvegarder en moins d'une seconde.
Les arguments de maintenabilité, d'adaptabilité et "d’orthogonalité avec la stratégie de déploiement des projets de diversité d'hyper-structurabilité homomorphe aux besoins opérationnels dans le cadre de la démarche qualité et d'adéquation du besoin intrinseque du profil utilisateur" (oui, je sais… c'est cadeau :) )… sont des inepties de ceux qui ne veulent pas admettre que c'est codé/designé par des quiches.
Un éditeur de texte correcte peut très bien être écrit avec un langage objet, être testé, avoir un code simple à comprendre et courte… ET sauvegarder un fichier de 20Mo en moins de quelques microseconde sur un SSD qui peut encaisser 2Go/s en écriture.

Concernant Robert, je ne peux que te souhaiter de prendre note des avis que tu as eu ici (documentation, performance, anglais…), ça ne nécessite qu'un peu d'investissement mais engendrera beaucoup de satisfaction (pour tous).

Je vais tenter de faire court. Dans mon post précédent, je n'ai fait que parler d'informatique (dont la définition est : théorie et traitement de l'information à l'aide de programmes mis en œuvre sur ordinateurs). En bifurquant vers les processus organisationnels, les aspects légaux,… et autres choses qui n'ont de rapport avec l'informatique que par la magie des discours commerciaux, on s'éloigne du sujet.

Je n'ai aucun doute sur le fait que tu fais cela avec beaucoup d'intelligence, mais ce n'est pas une raison pour chercher par tous les moyens à justifier des choix à l'encontre d'une bonne pratique de l'informatique (genre on s'en fout : des performances, de la bande passante utilisée, de l'accessibilité…).
De ce que je comprend maintenant ton système n'a d'utilité que si il est au centre d'une architecture multi-serveurs (sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide). Donc réservé aux gros déploiements.

Quand on a ce genre d'architecture, on cherche l'optimum, car perdre 5% de performances c'est payé quelques serveurs de plus pour "rien".
En pratique, un protocole non binaire, et qui cause en français c'est un magnifique gâchis de bande passante et de CPU.

Je m'étais dit de ne pas rajouter d'huile sur le feu vu le nombre de détracteurs ci-dessus… mais bon… j'ai un peu de temps à perdre.

Normal donc de se faire incendier quand on arrive avec une description longue d'un projet, qui au final, n'explique pas vraiment son intérêt puis assène post après post un discours idéologique en mode 'je sais tout'.

Pas la peine d'en remettre une couche sur le français, les explications ont étés claires:

• l'ascii est à préféré car évite les problème de clavier, d'encodage, est plus compacte et rapide à traiter (1 octet = 1 caractère).

• le français n'est pas universel en informatique

En revanche le coup du "développeur contemporain", c'est d'un non-sens terrible.
"développeur à la mode" ou "développeur inexpérimenté", pourquoi pas.

• Python n'a rien d'un langage performant, voir https://github.com/kostya/benchmarks pour s'en convaincre. Pour la clarté du code, vu que les "espaces" ont une significations, on repassera.

• Rust produit du code compilé comme des centaines de langages, le fait qu'il soit à la mode et que MS l'utilise ne prouve rien ( argumentum ad populum ), sauf qu'il est à la mode dans son petit monde. La dernière fois que j'ai regardé Rust, il n'existait pas de spécification formelle du langage. On est loin de la maturité des C/C++/Java/etc…

• LISP est langage de niche qui permet de faire des choses extrêmement avancé en quelques lignes, mais dès que l'on veut faire des choses 'communes' avec d'autre environnements comme : du réseau, une interface graphique, charger une image, jouer un son, on est content de ne pas s'en servir.

Le choix d'un langage devrait dépendre du besoin et d'une réflexion technique, pas de la mode.

Bref, avant de s'extasier devant tel ou tel langage, je serais déjà content qu'un développeur "contemporain" maîtrise les aspects bas niveau (architecture, gestion des caches, latence..) des entités avec lesquels il interagit…afin de comprendre que parser du JSON à 2Go/s n'est pas de la science fiction.

L'esprit critique c'est bien, on peut parler des heures de zététique aussi si tu veux.

Tout ce que je dis c'est que s'inscrire pour bénéficier gratuitement des milliers d'heures de travail, c'est pas la fin du monde. Créer un Prestashop a coûté plusieurs millions d'euros, tu n'as rien à payer pour t'en servir ou l'adapter.

Pour en revenir aux points évoqués, et pas vraiment dans le sujet.
1. oui un ecommerce ne fait pas forcement gagner de l'argent, mais utiliser un ecommerce opensource fait économiser beaucoup d'argent.
2. Prestashop c'est pas non plus la joie côté finance, début 2019, l’entreprise a licencié 4% de ses effectifs.

Si tous les propriétaires d'un ecommerce avaient daigné donner 10€ chacun par an (ce qui est peanuts au regard de l'outil qui est le coeur de l'activité d'un "e-commercant"), la situation financière de l'éditeur serait pérenne.
On peut transposer la situation à d'autres succès, comme vlc (3000€ de don par mois, 3 milliards de téléchargement au total…) et toujours de centaines de personnes pour se plaindre de ci ou ca.
(on peut aussi parler de LibreOffice, 125 000 € de don par an…)
Bref, se plaindre va un temps, si on ne donne pas les moyens aux projets opensource, il ne faut pas s'étonner des travers marketing, de bugs, manque de polish, ou disparition d'un tas d'outils.

Et alors? C'est le choix des développeurs de PHP, pas celui de Prestashop.
Les développeurs sont libres, tout comme leur code, le minimum c'est de respecter cela.

Il faut vraiment vous faire la liste des projets libres à succès qui ont disparus car dès qu'il faut dépenser un euro pour un logiciel libre qui en fait gagner des milliers/qui vous fait gagner du temps/ vous simplifie la vie, il n'y a plus personne?

Carrément trop dur comme démarche pour pouvoir télécharger gratuitement d'un logiciel qui a demandé des milliers d'heures de travail chaque année et qui va vous permettre de gagner de l'argent sans rien n'y connaître en informatique…

oui, mais pas des langages de programmation.

Juste une petite note pour préciser que les entreprises utilisent des logiciels de gestion commerciale pour faire leurs factures. Utiliser LibreOffice et cette extension risque de ne pas être très pratique.

J'en profite pour vous annoncer que la prochaine version d'OpenConcerto (ERP OpenSource) intégrera Factur-X en standard lors de la création d'une facture.

Super initiative, si le projet aboutit, ça va faire un carton!
Tu peux me compter dans les premiers acheteurs.

Un FPGA libre sur un PCB avec hdmi et 2 ports USB fera le bonheur des libristes fan de retrogaming/retrocomputing.

En pratique, qu'est ce qu'il est pratique de faire du point de vue d'une application Java avec D-Bus?
J'imagine que le cas d'utilisation doit être plus intéressant que d'afficher une notification dans Gnome, non?

effectivement la modification des modèles est délicate et ils ne sont pas terribles et ils ne comportent pas, pour les factures, de zone avec l'IBAN ;

Nous avons pourtant fait en sorte que la modification soit simple (modèle OpenDocument) modifiable en WYSIWYG avec LibreOffice et paramétrage en XML.
Le reste c'est surtout une histoire de goût, si on avait mis l'IBAN par défaut, on aurait des centaines questions de personnes sur comment le retirer. Nous avons donc mis le minimum, avec un style le plus simplet et passe partout.

j'ai un affichage pourri, une histoire de polices de caractères (?) ;
Oui, certaines distributions font un peu n'importe quoi sur l'intégration de Java et des polices.

je ne peux pas le désinstaller complètement (j'ai essayé tout ce que je savais pourtant), à la limite le remettre à zéro me suffirait, mais je n'ai pas trouvé comment ;

Il n'y a rien à désinstaller vu que rien n'est installé dans le système,
pour repartir de zéro, vous pouvez effacer votre base de données (OpenConcerto.h2.db), le logiciel s'occupera de la recréer.

un commercial obligatoire pour une petite structure c'est pénible.

C'est plutôt bien pour un client de savoir qui lui a fait le devis, TIPS : notez qu'il se remplit en automatique si vous liez un commercial a votre utilisateur.

supprimer les mentions à OpenOffice, plus développé depuis 2014, et ne garder que la référence au format OpenDocument (quitte à indiquer quels logiciels travaillent avec, LibreOffice, Gnumeric, Excel, etc.), je précise d'ailleurs ce que format n'est pas le format d'OpenOffice ou de LibreOffice comme xlsx est le format d'Excel, c'est un format ouvert qui est le format natif des suites libres mais qui ne leur est pas propre, par ailleurs les suites MS Office pour Windows ouvrent et travaillent ces formats depuis 2007 pour la version Windows et, pour autant que je sache, depuis 2016 pour la version OS X ;

Nous gardons la référence à OpenOffice car il est le plus connu de la bande :)

dans les Préférences globales, corriger "Gestion des piéces commericales" et remplacer par "gestion des pièces commerciales", curieusement (ou pas) le panneau de paramétrage associé est écrit correctement.

Oups. Typo corrigé de notre côté.

Merci pour votre retour.

Complexe? En monoposte, il suffit d'extraire l'archive tar.gz et de double cliquer sur le .sh …

Quel est le problème de "qualité" rencontrez-vous? L'impression se fait en 300dpi, nous n'avons pas retour de problèmes particuliers.

Pour l'export en JSON, qu'entendez vous par là ? Exporter une facture en JSON ? Pour quel usage?

Si vous avez des propositions, n'hésitez pas, ici ou dans le forum.

Oui, bien sûr tout dépend des fonctionnalités recherchées, nous avons des clients de plus de 200 personnes qui sont très contents d'OpenConcerto.

Quand je lis "développent fermé", je tousse… la licence est libre : GNU GPL et nous hébergeons un dépôt subversion accessible librement et anonymement.

Si vous ne voyez pas plus de contributions externes, c'est simplement que malheureusement le monde des logiciels de gestion est peu réceptif au concept de partage pour des questions d'avantage concurrentiel. Il y a pas mal de clone/renommage d'OpenConcerto en circulation, nous n'y pouvons pas grand chose.

De notre côté, comme vous le soulignez, nos développements sont disponibles sous licence libre.

(Et évidement, nous ne travaillons pas gratuitement, je ne connais pas d'ingénieurs prêts à travailler non stop sur un logiciel de gestion pour 0 € de l'heure.
Seul le coût de la licence est à 0€ pour les utilisateurs, ce qui est déjà pas mal, non? Impossible de faire mieux sans faire couler à pic notre société)

Une sorte d'apologie de la "hype" en fin de compte?
J'ai comme l'impression que certains se font plaisir au grès des tendances, la "mode",
des surcouches, des abstractions tout en discréditant toutes ces vielles technologies de plus d'un an.

Je comprend qu'il y ait un haut besoin de redondance quand on commence à hyper complexifier les choses, mais plutôt que de simplifier j'ai l'impression que tout converge vers le "on va répartir la charge et tout redonder" au lien de fiabiliser et de simplifier.

Bref, on en a pas fini de voir des pages web de plus de 1Mo et des "frontends" qui n'encaisse pas plus de 100 req/s….