barmic 🦦 a écrit 5212 commentaires

C'est moi où tu reproche à une base de données NoSQL de ne pas être ACID ?

Là, tu es carrément de mauvaise fois, MongoDB est très polyvalent, PostgreSQL l'est encore plus, et les deux sont dans la même niche: des bases de données.

C'est pas parce que ça stocke de la donnée que c'est la même chose. Envoyer un recommandé et un sms, c'est de "l'envoi de message" pourtant. C'est de la sémantique ce que tu tente de faire, mais quand tu sort d'ACID tu quitte le monde de la base de données tel que tu semble le comprendre, c'est comme si tu te mettais à stocker à la main sur disque ou via ftp. Si on ignore ça, on a le genre de surprises que tu décrit.

[PostgreSQL] convient très bien aussi pour faire du clé-valeur (bien que j'ai un faible pour Redis pour ce besoin)

Tu vois t'es encore entrain de comparer des choux et des patates. L'un ne stock rien sur disque et est là pour faire de la latence faible a un modèle de stalabilité… particulier. Là où l'autre écrira toujours tout sur disque fourni largement plus de garanties etc. Bon perso je trouve que redis est le roi du goodenought, mais c'est une autre histoire.

Postgre est une excellente base de données et ça se voit car son moteur est très flexible et tiens la dragée haute à des moteurs pensés directement pour cette flexibilité (je parle de rocksdb ou cockroachdb qui sont des moteurs qu'on utilise pas directement normalement) alors que pg existe depuis 25 ans. AWS s'en sert par exemple pour produire leur solution compatible mongodb (mais ils n'utilisent pas le support jsonb libre, ils ont leur propre truc à eux). Mais il ne faut pas croire pour autant que tout est gratuit son event/notify est anémique face à de vraies solution (pareil pour redis).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On stocke quelques Tio dedans sans problème particulier, on a plusieurs collections à plus de 20 millions de documents et qu'on met à jour à probablement plus de 2k/s sans problème particulier. Mongo n'aime vraiment pas avoir de gros documents ça le ralenti pas mal.

Je ne comprends pas trop les gens qui disent "j'étais avec X, oulala les galères, je suis passé sur Y (Y ayant rien à voir avec X), depuis ma femme est revenu !". mongo et postgre sont 2 outils très différents. Pour moi c'est vraiment comme dire "pour ma vis, j'utilisais une clef allen c'était une galère depuis que je me suis acheté une clef torx ma vie a changé, je la serre et la déserre avec plaisir". Ma machine à laver n'est pas meilleure que mon vélo.

Tous ces outils sont très bons. Ils ne sont juste pas fait pour les même usages. Souvent on est peu contraint et moins on est contraint moins la techno sous-jacente n'a d'importance. Quand on parle de grosse contraintes, il faut se rappeler que ce sont des techno utilisé pour d'énormes infra être petit à coté n'est pas une insulte (et je suis un tout petit à coté). Nous on utilise mysql/mongo/cassandra/infinispan selon le besoin et je n'irais pas dire que l'un dépasse les autres chacun vient avec ses avantages (ce que tout le monde a en tête) et ses inconvénients (qu'on a facilement tendance à oublier), mais si on ne prend pas en compte ses inconvénients ça pose des problèmes (et faut avoir du recul y compris sur ce qui est présenté par le vendeur de ses trucs).

Par exemple si mongo parle d'avoir des transaction par exemple, il faut pas se dire que c'est parti on refait comme en SQL. Tous ses outils et pg le premier tentent d’agrandir autant que possible leur surface d'utilisation, mais sauf cas particulier ça devrait rester à la marge (voir être ignoré) parce que ça remet en cause l'architecture de base du truc ce qui lui donnait un intérêt.

En plus avec PostgreSQL tu peux explicitement créer les indexes comme bon te semble, et profiter de toutes ses autres fonctionnalités.

Je ne te suis pas, de quoi parle-tu ? Mongo peut très bien avoir des indexes par contre postgre ne peux pas faire n'importe quoi avec du jsonb. Si par "toutes les autres fonctionnalités" tu entends "sauf ma majeure partie des fonctions relationnelles" ça en enlève un paquet et ça réduit fortement l'intérêt d'un moteur de base de données relationnelle à cela on ajoute un requêtage limité, de même pour les vues du coup. Clairement c'est pas fait pour la même chose.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Prêcher les "bonnes" pratiques sans donner d'exemples clairs n'est déjà pas très utile.

C'est pour ça que j'ai voulu prendre en un exemple, je voulais installer PHP et montrer ce que ça pourrait être, mais je n'ai pas eu le temps ce matin et je vais finalement m'abstenir.

J'aurais largement préféré qu'on me fasse des retours sur les problèmes rencontrés sur des architectures que je n'ai pas pu tester ou sur les paramètres particuliers d'Apache à surveiller, plutôt qu'entamer un débat sur "Faut-il coder avec moins de 3 indentations ?"

Très bien.

Niveau lisibilité, c'était autre chose… certains devs imprimaient les codes et dessinaient des accolades pour trouver les portions de code concernées.

La lisibilité c'est pas une question de testostérone. Tu n'es pas ton code et les remarques que j'ai pu faire sur ton code ne préjugé rien sur toi. Elles ne t'intéressent pas, très bien.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je me permet moi aussi de me taper l'incruste :)

Les fonctions permettent de gérer le niveau d'abstraction et de cloisonner un programme.

Si je prend l'un des plus haut niveau de profondeur du script :

// search for the pid with this inode in /proc/<pid>/fd  (need to be root)
$pid = "";
$process_name = "";
$process_cmdline = "";
if ($h1 = @opendir("/proc")) {
    $found = false;
    while (false !== ($file1 = readdir($h1))) {
        if (! $found) {
            if (is_numeric($file1)) {
                if ($h2 = @opendir("/proc/$file1/fd")) {
                    while (false !== ($file2 = readdir($h2))) {
                        if (! $found) {
                            if (is_link("/proc/$file1/fd/$file2")) {
                                $file3 = readlink("/proc/$file1/fd/$file2");
                                if (strpos($file3, "socket:[$inode]") !== false) {
                                    display("[..] Found inode for port $port in $file3 in /proc/$file1/fd");
                                    $status = file_get_contents("/proc/$file1/status");
                                    $status_ppid = "";
                                    $status_pid = "";
                                    $status_lines = explode("\n", $status);
                                    foreach ($status_lines as $line) {
                                        if (substr($line, 0, 4) == "Pid:") {
                                            $status_pid = trim(substr($line, 4));
                                        }
                                        if (substr($line, 0, 5) == "PPid:") {
                                            $status_ppid = trim(substr($line, 5));
                                        }
                                        if (substr($line, 0, 5) == "Name:") {
                                            $process_name = trim(substr($line, 5));
                                        }
                                    }
                                    if ($status_ppid == 1) {
                                        $pid = $status_pid;
                                    } else {
                                        $pid = $status_ppid;
                                    }
                                    $process_cmdline = readlink("/proc/$file1/exe");
                                    $found = true;
                                }
                            }
                        }
                    }
                    closedir($h2);
                }
            }
        }
    }
    closedir($h1);
}
if ($pid == "") {
    display("[!!] Fatal error : unable to find the main apache process pid in /proc for inode $inode");
    exit();
} else {
    display("[OK] Apache main process '$process_name' found : $process_cmdline (pid $pid)");
}

On a un savant mélange de manipulation de chaîne de caractères, de parcourt d'une arborescence et d'affichage. On a aussi des variables qui se balades à tous les niveaux.

Des fonctions permettent de s'abstraire de tambouille peut utile au fonctionnement globale (savoir comment on gère le format d'un fichier est indépendant de comment on va chercher ce fichier) (bon on est sur un cas pathologique où les conditions sont dans des if alors qu'ils pourraient être dans les while).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne pense pas[…]

Ton commentaire précédent ne parlait que d'infrastructure.

TLDR : Le seul retard réel existant en Europe est un retard d'investissement, et la volonté politique actuelle est une ennemie, pas une potentielle alliée.

Le fait d'avoir peu d'utilisateurs, ralenti la maturation des offres, réduit leur possibilité d'investissement, etc, etc. C'est même pas moi qui le dit c'est Octave Klaba¹ (patron d'OVH) et Quentin Adam² (patron de clevercloud). Ils n'affirment pas être au niveau des concurrents américains, ils disent qu'ils sont sur la voie qu'ils y travaillent et la seule façon de les aider c'est de les utiliser (pour ça, si c'est juste pour acheter des machines ils savent très bien en vendre).

Mais on est tout à fait d'accord pour le reste.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu confond cloud et hébergement et infrastructure. Une offre de cloud ce n'est pas une offre d'hébergement. Les gens ne vont pas chez AWS pour l'offre EC2 qui n'est pas géniale mais parce qu'ils ont besoin de différentes bases de données sans avoir envi d'avoir des compétences en interne pour installer/maintenir en condition opérationnel/monitorer/mettre à jour diverses bases de données, avoir accès à des ressources à la demande comme des GPU pour quelques jours ou quelques jours par mois, des outils de traitements automatique de langages naturels efficace, de faire du push mobile sans s'embêter avec google(qui en est à sa troisième API actuellement)/apple/huawei/…, etc etc. Ça coute peut être chère, mais moins qu'avoir les compétences en interne (il faut une bonne politique de recrutement, de formation, il faut plus de gens - parce qu'on gars qui sait tout faire ne pourra pas tout faire en même temps -, gérer la capitalisation des connaissances sur tout ses aspects,…) et c'est moins casse gueule. Il peut être intéressant de voir tout ce qui a était publié autour de netflix qui a démarré chez AWS pour se lancer rapidement, puis a tout mis en interne pour réduire les coûts avant de repartir chez Amazon quand ils ont vraiment grossi et qu'ils ont décidé de ce qui relevé de leur métier et ce qui n'en relevait pas.

Tant qu'on ne comprends pas la différence entre Azure et Gandi, on ne pourra pas tenter de concurrencer les gens d'aller voir le premier plutôt que le second.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Plus que la presse spécialisée qui recrache les discours commerciaux ? L'important ce qui t'es utile c'est :

• la performance mesurée
• la chauffe/consommation si tu monte ta machine

Détailler des bouts de spécifications ne fait que flatter l'égo du client un peu intéressé (moteur 16 soupapes, injection getho-blaster,…).

L'important c'est qu'au lieu de se transformer en zombie (« moi je suis team intel #pentiumM »), il faut s'arrêter, se demander ce qu'on va faire et trouver des benchmarks correspondants. Il y en a pleins.

S'attacher à des mesures de densité de transistors, finesse de gravure ou autre c'est intéressant pour des gens du domaine, qui s'intéressent à l'évolution technique pas à l'utilisateur final.

Tu ne compare pas les logiciels en fonction du nombre de ligne de code et tu ne crée pas une mesure de ligne de code "équivalent C" pour palier en fait que le nombre de ligne de code en C, python et haskell ne peut pas être comparé.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est possible, mais il faut faire attention à savoir quels sont les biais que l'on inclue dans l'analyse parce que tous les paramètres ne sont pas indépendants les uns des autres. De plus ils permettent de donner une indication pas une vision globale.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On en a déjà parlé ici, qui pointe vers ce lien. C'est loin d'être parfait mais ils y travaillent et c'est qui se fait de mieux que je sache (y pris hors mobile d'ailleurs).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis d'accord que c'est très confus. D'une part tu ne dis pas clairement l'objectif et d'autres part tu enchaîne les étapes sans les expliquer.

Tu ne décrit pas duplicity et ce qu'il t'apporte. Tu l'utilise avec ssh, mais c'est loin d'être la seule façon de faire et tu l'a choisi à la place de tar hors c'est ce qu'il utilise en interne.

La partie génération de clef, tu ne dis pas à quoi servent chaque clef. Tu commence en expliquant que tu t'es tromper en voulant tout faire d'un coup, mais tu dis ensuite autant faire tout d'un coup et tu décrit comment tout faire d'un coup.

En soit on comprend ce que tu dis et fais quand on connaît déjà tout ça. Donc je vois pas trop l'objectif du journal :

• tu c'est pour parler à des connaisseurs inutile d'entrer dans les détails
• si c'est pour aider quelqu'un qui ne connaît pas, séparer gestion des mots de passe et sauvegarde et décrire ce qu'on fait (et pourquoi) avant de le faire le semble nécessaire

En tout cas c'est super si tu es satisfait de la solution que tu as mis en place et tes content que traîner dans le coin t'ai aidé. C'est génial de vouloir partager continue !

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça tombe bien ce qui est dis c'est que ce qui est sous-traité n'est pas la partie traitement de données. Toutes les boîtes de développement logiciel n'utilisent pas exclusivement du logiciel à eux.

Toute la partie "suivi de leurs assurés" ne semble pas être géré de la même façon.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais je suis plutôt partisan des approches 'lean' où on évite des usines à gaz pour 2-3 fonctionnalités qui nous intéressent.

J'évite de penser de cette façon. Les mots clefs n'ont pas toujours du sens en soit. Est-ce que c'est lean d'avoir de la complexité un peu partout plutôt que de regrouper tout ce sujet à un seul endroit ? Ça dépend de pleins de choses.

Il est parfois plus rapide de coder une fonctionnalité que d'apprendre à utiliser (et maintenir, et déployer, etc) des outils complexes. Je ne suis pas non plus partisan de l'approche inverse que consiste à tout coder tout seul.

C'est aussi pas simple de faire un passage de l'un à l'autre. Mais pour l'exemple le fait de regrouper tout cette problématique au même endroit permet d'avoir un comportement homogène partout.

one-to-one

Voir le module elixir Registry.

Est-ce que c'est à l'émetteur de se soucier de la liste de ses destinataires ? C'est un choix. 'fin c'est un choix jusqu'à ce que tu ai un grand nombre de destinataires ou que la liste des destinataires soit très mouvant.

que tu ne peux pas retirer le destinataire

Grâce au mécanisme de supervision des processus, le module Registry ci-dessus gère parfaitement la connexion/reconnexion d'un client. Est-ce cela dont tu parles ?

Tu garde un couplage entre l'emmeteur et le destinataire. Le plantage/mise à jour du destinataire impose un travail en plus à l'émetteur.

Oui, sauf que mettre en œuvre une stratégie à base de timeouts, de retries, voire de files d'attentes différentiées se fait en quelques dizaines de lignes de code, à comparer à la configuration d'un outil comme RabbitMQ (+ configuration du code client).

Je me doute, mais elle a donc de potentiels bugs, doit donc être pensée complètement en amont (tu as bien moins de flexibilité lors de ton run). La configuration d'un client rabbitmq c'est quelques lignes (et vraiment on parle en ligne et pas en dizaines de lignes) quelque soit le langage. La configuration d'un rabbitmq c'est fait une bonne fois pour toute.

que tu ne peut pas lisser ta charge en empilant des messages dans une fille ou si tu le fait c'est plus fragile parce que la file est géré par le destinataire et pas commune à plusieurs instances du destinataire

Voir GenStage

Si j'ai bien compris c'est l'émetteur qui doit gérer la disponibilité ou non du destinataire.

GenStage gère très bien le back pressure.

C'est très cool, ça n'est pas naturel avec AMQP (ça l'est déjà bien plus avec kafka).

Mais la back pressure ce n'est pas forcément le lissage de charge. Tu peux avoir du code qui reçoit des requêtes à un débit qui est acceptable pour toi, mais qui doit transmettre à quelqu'un d'autres qui a plus de mal. Si c'est intermittent le fait de laisser un brocker stocker les messages pour les donner tranquillement au destinataire c'est pertinent. Si tu veux être élastique de scale les destinataires en fonction de ce que tu empile, tu dois faire la remonté d'alerte ou de monitoring à la main pour ensuite avoir une autre partie qui gère tes déploiement. Avec des brocker ça peut se faire avec un peu de conf et se faire sur tout ou partie du système sans modification du code.

Je n'ai rien contre RabbitMQ (écrit en erlang en plus :D ) mais j'ai vu plusieurs cas où son utilisation n'était pas justifiée et créait un overhead énorme, pas seulement en terme de latence mais surtout en terme d'intégration et de maintenance.

Moi je n'ai pas d'action chez eux. Je répond juste à ton message qui ne voyais pas d'intérêt. Tu te retrouve à tout faire à la main (avec une certaine simplicité mais l'ajout de différentes bibliothèques) et tu n'es plus agnostique. Et surtout tu fais un choix de où tu place les responsabilités (avec ce que ça implique dans un sens comme dans l'autre). Sans aller dans l'idée qu'il faut que tout soit toujours agnostique, je me fais de petits outils amqp qui ne sont pas avec le même langage que le reste et j'en suis bien content.

Après je ne te parle pas des workflows surprenant comme router du trafic environnement pour des tests/expérimentations/bench qui te permettent de récupérer du contenu d'un environnement pour le jouer localement ou sur un autre environnement sans avoir à ajouter du code dédié à ton expérimentation.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je sais pas pourquoi tu viens me chercher sur kubernetes, mais kerbernetes n'a pas besoin d'un stagiaire pour redémarrer quand ça plante (et on l'a pas attendu pour inventer les watchdogs).

Après je ne sais pas si :

• laisser un stagiaire seul face à une prod est quelque chose de raisonnable surtout si redémarrer est la seule chose qu'il sait faire
• juger une techno à ce qu'un stagiaire présumé bête sait en faire est quelque chose de pertinent
• maintenir des travaux manuels facilement automatisables pour laisser du travail à des gens présumé ne rien comprendre est une bonne idée

Après chacun gère sa prod comme il l'entends.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La question n'est pas la taille, mais ce qu'on en fait :p

Tu as pas mal d'article qui en parlent même en français, je te met celui-là parce que je trouve que leur images permettent de bien comprendre : https://www.tomshardware.fr/le-7-nm-de-tsmc-compare-au-14-nm-dintel/

Après il faut vraiment comprendre qu'évaluer la puissance des CPU par leur fréquence, leur finesse de gravure ou leur nombre de transistors (c'était surtout pour les GPU ça), c'est un peu comme évaluer les coureurs du 100m par la taille de leur jambes, la circonférence de leur cuisses ou leur VO2 max. C'est pas dénué de sens, mais ça reste très très très approximatif.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Par contre, je n'ai jamais vu l'intérêt d'utiliser AMQP avec erlang: tu peux avoir l'équivalent d'un broker de service en quelques lignes de code, avec une latence qui n'a rien à voir avec un service externe (RabbitMQ).

Le reroutage à chaud des messages par exemple, le monitoring, tout un tas de règles de gestions que tu peux ajouter au runtime pour que ce soit différent par environnement (taille limite des queues par exemple), tu peux aussi ne pas vouloir stocker un nombre important de messages dans la mémoire de ton processus applicatif, être agnostique des langages avec une pléthore de langages et outils déjà existant, maintenant ils font du log distribué à la kafka,… Je ne doute pas que ça soit pas très compliqué à faire en erlang, mais il faut prévoir les choses avant et c'est toujours de la complexité en plus.

Au final, que ce soit en 100% erlang ou avec des codes externes, les applications erlang sont très similaires à des micro-services, sans k8s/docker, des load balancer HTTP, des API REST, etc.

C'est pas la même granularité. On peut dire qu'OSGi c'était aussi des microservices avant l'heure. Mais ça a tout de même des différences importantes en terme de déploiement et de ce que ça implique.

Dans les architectures que je déploie, j'ai tendance à privilégier maintenant des RPC plus agnostique par rapport au langage (gRPC, protobuf sur CoAP, voir BERT, etc) mais en aucun cas un broker de message externe.

Ça veut dire que :

• tu ne fais que du requête/réponse
• des messages one to one
• que tu ne peux pas retirer le destinataire
• que c'est celui qui envoi le message qui doit gérer la stratégie de rejeu d'un message
• que tu ne peut pas lisser ta charge en empilant des messages dans une fille ou si tu le fait c'est plus fragile parce que la file est géré par le destinataire et pas commune à plusieurs instances du destinataire

Du coup oui je comprends que tu n'es pas besoin de broker de messages :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je sais pas. Je ne sais pas quel niveau de sophistication existe là dessus. Je sais qu'ils font du WAF (mais OSEF quand on distribue des ressources statiques), mais je ne sais pas ce qu'ils font dans le détail pour du ddos.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour préciser, je ne dis pas qu'il ne faut pas aller chez OVH. Juste qu'il faut savoir que ce n'est pas la même chose et dans quoi on s'embarque. Si on présente OVH comme équivalent ça va faire tout drôle et décrédibiliser la démarche.

D'ailleurs je trouve dommage de sortir systématiquement OVH en mode jocker de celui qui doit bien savoir faire. Il y a d'autres acteurs scaleway, gandi, ikoula, clevercloud, hidora, scalingo,… Ça me donne un peu l'impression de "je connais pas le domaine, mais j'ai un jocker" et je trouve que ça questionne. Si ceux qui sont partisans de cloud souverains/indépendance vis à vis des autres puissances économiques n'ont pas une vision plus détaillées pourquoi ceux qui organisent leur projet plus par le coût que par la vision politique en sauraient davantage ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On est en retard en Europe. CÇa n'est pas irrécupérable, mais ça demande une volonté politique. Il faut accepter de payer plus chère pour moins bien des acteurs locaux pour que plus tard, ils soient au niveau.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pas que je sache. OVH sait très bien te fournir des machines, mais je ne crois pas qu'ils aient un service qui ressemble de près ou de loin à à ce que proposent cloudflare, c'est-à-dire une solution où tout la répartition de charge côté client est gérée pour toi, tout le monitoring est géré pour toi et tout ça pour un prix relativement peu cher. En effet pour cloudflare la répartition de charge consiste à ajouter une configuration sur leur cluster et pas à te dédier des machines pour toi de même pour le monitoring. Et toutes les opérations pour roller tes serveurs frontaux est une question que tu ne te pose même pas. Enfin je ne sais pas de quelle charge on parle, mais l'ouverture de connexions TLS peut devenir un véritable problème et ça reviens très chère de le gérer soit même.

Tout ça pour dire que la différence entre une solution dédiée clef en main et "je te file des machines débrouille toi", c'est que ça peut te revenir bien plus chère (tarification qui suit la charge vs tarification indexée sur la charge maximale que tu prévois, maintenance en plus, compétences en plus à avoir dans l'équipe).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

soit le point d'entrée risque d'affamer les autres processus, et la librairie erlang pour écrire ces NIFs fournit des primitives pour rendre la main à l'ordonnanceur, qui décidera ou non d'ordonnancer un autre processus.

C'est ça qui me semble rapidement poser problème. Ce qui va pousser à utiliser du C c'est pour être CPU intenssive ou pour t'interfacer avec du matériel ou du code qui ne tourne pas sur beam. Un code de calcul par exemple que tu ne peux ou ne veux pas retoucher pour l'ordonnanceur erlang (et ce n'est pas forcément simple de savoir quand c'est pertinent de se préempter ça peut ruiner les perf). D'où ma question pour la seconde solution. Après c'est questionnable il peut être plus intéressant de vraiment séparer et d'avoir des interactions à coup message queue entre les 2 (pas forcément amqp).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oh je suis bien content d'avoir posé ma question du coup :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Merci pour tes précisions.

En ce qui concerne les perfs des I/O, c'est effectivement une limitation d'erlang.

Ce n'est pas ce que je voulais dire. Je disais qu'il me semble que c'est un modèle de programmation surtout fait pour des programmes I/O bound (et même latence bound). Les threads légers sont conçu (il me semble, hein) pour gérer des I/O concurrentes et pas pour de la parallélisation. Si je prend par exemple la génération d'une rainbow table (premier truc qui me vient en tête cpu bound parallélisable) il n'y a pas d'intérêt (en tout cas en terme de perf) de spawn un thread léger par entrée plutôt que d'itérer avec un threads système par cpu.

erlang intègre la possibilité de mapper des fonctions erlang sur des fonctions écrites en C. C'est même considéré comme une bonne pratique pour peu que le code soit circonscrit, bien testé :P et interagisse avec les scheduler pour ne pas bloquer les autres processus (lire Respecting the scheduler in erlang NIFs.

J'ai pas encore lu le lien, mais ça me parait très casse gueule. Il n'y a pas de raison particulière qu'une bibliothèque C respecte le scheduler erlang… Il n'y a pas moyen de plutôt faire interagir ça avec un passage de message ? Tu as du code erlang/C qui attend/envoi des messages et qui se fout du scheduler erlang et le reste du programme vie sa meilleure vie ? Ça demande soit des api particulières (par exemple avec un binding C du protocole udp des messages) soit de pouvoir créer un thread qui ne soit pas géré par l'ordonnanceur erlang.

C'est comme ça que bosse elm toute interaction avec du js se fait par envoi de message et il y a une api js d'envoi/réception de message. Je trouve ça très propre.

En tout cas merci je vais regarder les liens que tu m'a donné.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Souhaitons qu'au-delà du marketing, Intel arrivera à se relancer dans la course aux CPU et même qu'il nous étonnera avec son arrivée prochaine sur le marché des GPU.

C'est rigolo de se moquer du marketing en utilisant des arguments marketing…
Déjà parce que le 7nm de TSMC ne mesure pas la même chose que le 7nm intel. Ensuite parce que c'est un chiffre dont on se fout. Il n'est pas complètement hors-sol, mais faut se rappeler que ce n'est qu'un moyen d'avoir de la performance ou de la basse consommation tout comme peu l'être des changements dans l'architecture du CPU. Choisir de mettre en avant cette valeur plutôt qu'autre chose est un choix purement marketing qui a eu lieu quand après avoir plafonné sur la fréquence puis rapidement sur le nombre de cœur, ils avaient besoin d'un "truc" à donner pour se représenter une évolution (comme le nombre de bits des consoles 8/16/32/64).

Je ne dis pas ça pour remettre en question ton avis sur intel, mais pour mettre en évidence que cette histoire de finesse de gravure (qui est bien plus complexe qu'une mesure comme ça) est avant tout marketing.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

une gestion explicite du temps.

C'est à dire ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comment est-ce que les threads légers peuvent utiliser plusieurs nœuds de calcul ? L'ordonnanceur noyau prend un thread système d'un processus et lui donne un temps d'exécution sur un CPU. Il ne voit pas les threads légers et ne peut donc les exécuter en parallèle sur des cores distincts.

Je crois savoir que go crée un thread système/cpu et associe les threads légers à ces threads systèmes¹.

Si beam fait pareil il n'y a pas de problème si le profile de travail n'est pas homogène entre les paquets de threads légers par exemple ? C'est un truc au quel il faut faire attention ? Par exemple ne pas créer tous les threads cpu intensive au même moment ou quelque chose du genre ?

Tu parle de passage de messages constant ça me parait aller à l'encontre de la démarche d'erlang, l'objectif du passage de message c'est d'avoir un couplage faible et de gérer les latences élevées par exemple parce que tu ne sais pas si le destinataire de ton message est sur le même thread léger/instance que toi. Si dans bien des cas c'est très performant si on souhaite que ce soit transparent il faut pas trop s'appuyer sur cette performance au risque d'avoir des problèmes quand on quitte les tests sur sa machine et qu'on passe dans un environnement cluster.

Il me semble que s'orienter vers des threads léger est surtout utile pour des workloads qui nécessitent un très grand nombre de petits I/O. C'est à dire quand ce qui freine l'application c'est la latence des I/O et pas le temps de calcul par exemple. En effet l'ordonnanceur en espace utilisateur ne préempte pas les threads léger et va s'appuyer sur leurs I/O pour les commuter. Ça ne paraît pas idiot pour des télécoms et pour rabbitmq d'avoir ce genre de besoins d'ailleurs.

Tu as des retours sur comment c'est implémenter et sur dans quel cas ça marche moins bien ?

---

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll