et il me sembles que les daemon systèmes survivent bien sans utilisateur connecté.
Ben oui, mais dans systemd, la slice système (ie le/les cgroup(s) attribué au lancement de processus en mode service) n'a pas le même fonctionnement que les slices utilisateurs. Donc si tu lances un processus en tant qu'utilisateur et que pour une raison X ou Y tu veux le conserver bien que tu fermes ta session - tu l'as un peu dans l'os.
En ce qui concerne daemon() c'est un utilitaire "à la sauce" sysV init. En d'autres termes c'est un toolkit qui facilite le double fork et la migration des input/output depuis un pty/tty vers un autre.
a) C'est très compliqué à utiliser en cours de route (ie c'est pas facile de démoniser à la volée un processus qui n'a pas été prévu pour - notamment qui ne va pas migrer sa mémoire, environnement, threads etc. quand il va se prendre un fork dans les dent). daemon() est plutôt destiné à être utilisé au lancement du processus
b) systemd en a rien à faire de daemon(), le process aura été lancé depuis une slice utilisateur, donc il va rester dans son cgroup utilisateur. En d'autres termes, daemon() ou pas, ou moment ou la slice sera nettoyée (par exemple à la fermeture de session) le processus va gicler (c'est d'ailleurs bien là le soucis qui nous préoccupe aujourd'hui)
c) Si on fait avaler à systemd une slice dégénérée (ie une slice utilisateur qui est considérée par systemd comme une slice système - voire une slice mère de la slice système) ca passe. Par contre créer ce type de slice est complexe, non supportée et casse beaucoup de choses (logind par exemple - pour citer le truc le plus impactant). A part en expérimentation pour faire joujou, je déconseille vivement.
Ce que j'aime en haskell c'est le coté simple de la syntaxe à ce niveau, tu n'as pas à te préoccuper de qui va évaluer ton thunk, où qu'il soit évalué plusieurs fois.
Je te rassure en javascript on arrive à des résultats similaire avec des iterators.
ZFS procède aussi comme ceci quand la déduplication est activée, mais existe un mode de déduplication qui gère les collisions
Oui, enfin sauf que ZFS c'est pas du SHA1 mais du SHA256 par défaut et qu'il y a d'autres indicateurs qui évitent pas mal de collisions même sans verify. Par exemple les deux blocs doivent avoir la même taille (ZFS utilise des blocs de taille variable).
Grosso-modo quand tu essayes de faire de la haute disponibilité, de la continuité de service etc. tu te retrouves à devoir gérer des systèmes qui dysfonctionnent mais qui ne s'en rendent pas forcément compte. Il te faut donc des mécanismes qui permettent à un arbitre de prendre des décisions, typiquement tuer ou isoler une instance et un promouvoir une autre comme chef de file. Dans ce genre de cas il faut faire très attention à ce que l'instance dont tu cherches à te débarrasser ne puisse plus agir sur les ressources à présent gérées par l'instance que tu cherches à promouvoir.
Alors on commence par la fin :
J'utilise toujours ifconfig. Sur mes vms j'ai des cartes réseaux qui sont rajoutés dynamiquement, des VPN et des émulateurs ports com qui viennent se mettre par dessus en fonction des besoins et malgré plusieurs tentatives je ne vois pas comment gérer ce genres de choses avec ifup, ip et consors. Surtout que je n'ai pas forcément besoin de TCP/IP sur ces cartes, et que je ne veux pas surtout pas de link-local/mDNS.
Donc sur mes cartes dynamiques, c'est des sets de règles udev et des scripts à base d'ifconfig qui se lancent.
Par contre route, clairement je l'utilise quand j'ai besoin. ifconcig ne pas faire grand chose niveau route.
En ce qui concerne le lancement du wrapper, il est lancé par systemd dans le mode le plus bête possible (pas de surveillance, pas de restart, forcé dans un slice dégénéré avec des droits sur la majorité des cgroups etc.) Le fait que systemd ait été choisit par Debian m'impacte peu. Je vais utiliser les outils Debian dans la mesure du possible, mais très vite je diverge de ce qui est fourni. Pour Apache, Nginx, Postgres/PostGIS, postfix, Nagios/Zabbix, Java/Tomcat etc. J'utilise mes propres packages avec mes propres scripts d'init. Dans la majorité des cas les choix fait par Debian ne sont pas les choix optimaux pour ma production. Pour moi Debian est une base (et un très bonne base, j'aime vraiment beaucoup cette distribution) mais je n'ai aucune hésitation à m'écarter de cette base si ça m'apporte quelque chose.
En ce qui concerne systemd strictement, la réponse courte est que systemd a trop de lacunes par rapport aux systèmes d'init historiques pour me permettre de faire tout ce dont j'ai besoin. J'ai besoin de services dynamiques, j'ai besoin de pouvoir forcer certains démarrages en mode séquentiel sans pour autant qu'il y ait dépendance (i.e le service b doit se lancer après le service a et ce même si le service a échoue à se lancer - ce genre de condition sont très courantes quand on fait du fencing notamment) et par dessus tout j'ai besoin que des utilisateurs des machines distantes et des services puissent relancer d'autres services sans nécessairement avoir les droits root (et également sans avoir à créer des slices dégénérés tous les quatre matin)
Pour finir avec ton tutorial, je l'ai lu comme un exemple simple à compléter (que ce soit avec de l'ansible, du saltstack ou des recette cook) et j'ai bien conscience que la pédagogie va parfois à l'encontre de la propreté/qualité. La méthode qui consiste à donner un exemple qui fonctionne et que tout le monde comprend - avant d'expliquer pourquoi il ne faut jamais faire comme ça - est tout à fait valable.
C'est juste la réaction de Christophe B. avec notamment son "En plus j'aime bien comment tu gères systemd / finalement c'est pas si compliqué" qui m'a fait froid dans le dos.
Le problème c'est que si tu as 100 agents à collecter (et ça va vite de monter à 100 agents et plus) tu te retrouves avec 100 services
- Que tu dois maintenir/mettre à jour
- Que tu dois éventuellement monitorer à leur tour
- Que tu dois documenter
- Qui ne sont pas vraiment liés à Zabbix (ce sont des tunnels), mais qui ont un impact sur la production si ils tombent.
etc.
De plus je me met dans la peau de l'admin system qui reprend le truc (l'ancien admin est en fuite pour cause de compte en banque dans les iles sud américaines - et n'est absolument pas joignable ) , il va dans la config du service (donc plus Zabbix puisque SSH est intégré maintenant, mais un autre) et là il voit que les sondes sont accédées par 127.0.0.1:30000, 127.0.0.1:30002 … 127.0.0.1:30100. Il est content.
Il va alors chercher le truc qui ouvre le tunnel, et joie, santé, bonheur il tombe sur plus de 100 fichiers de services dans lib/systemd et etc/systemd (ben oui, il y a pas que Zabbix dans la vie). Si l'admin précédent a été très propre il va s'en sortir - par contre si il a été un peu brouillon ou un peu trop prudent on va avoir du NEW-ssh-tunel-XXXX-YYYY-test-DONT_ENABLE.service par paquets. Et vas-y de tester lesquels sont activés et lesquels sont éteints. Eventuellement il sera bon pour faire un tour sur le routeur/collecteur pour voir si il s'agit du lien OOB ou du monitoring spécifique d'un port pour un client.
Personnellement c'est typiquement un des cas ou j'envoie balader systemd (traduction je lui demande de lancer un wrapper et de ne surtout pas s'en occuper) et ou je passe des variables d'environnement (ou des fichiers de conf - ca marche aussi) dynamiquement à mon wrapper qui fait du coup office de pseudo gestionnaire de service.
Je centralise toute ma conf en un point, mon wrapper lance les tunnels, fait les test et finalement lance le collecteur.
Mais maintenant je me dis que je suis peut-être un dino, et que bien entendu tout admin de moins de 35 ans se ruera sur /etc/systemd et comprendra la conf en deux minutes.
D'avance toutes mes excuses, car je n'arrive pas à formuler ma question d'une façon qui ne sonne pas comme un troll - surtout vis à vis de mon passif concernant systemd.
Ma question est la suivante : quand tu dis
En plus j'aime bien comment tu gères systemd
Es-tu sérieux ou sarcastique ?
Pour moi le type d'automatisation mis en place par ghusson pour la mise en place des différents services et clients est le pire des cauchemars, que ce soit en terme de suivi, de maintenance, de reprise (le mec qui ne sait pas comment on a procédé il va un peu se gratter la tête pour comprendre) etc.
Ici le fait que tu calcul tes projections dans une direction ou dans une autre ça impact directement tes utilisateurs. C'est donc quelque chose que tu dois valider avec les utilisateurs ça concerne leur métier.
Je ne calcule pas mes projections d'une façon ou d'une autre, je créé des vues - il n'y a pas de calcul coté BDD. Une vue SQL par exemple c'est juste un test qui dit "si on te demande les données de TITI, renvoie à la place les données de TATA ". Et comme je n'ai pas envie de créer toutes les vues possibles et imaginables je fais une fonction à la place. Il n'y a aucun calcul spécifique métier qui est fait en base. Ce ne sont que des opérations de consolidation et d'agrégation génériques. Je n'ai rien besoin de valider avec mes utilisateurs si ce n'est l'interface qu'ils doivent utiliser. Plutôt que de leur dire tu fais
SELECT * from (
SELECT …
UNION SELECT …
UNION SELECT …
UNION SELECT …
JOIN
SELECT …
UNION SELECT …
…
ON …
) WHERE month=4 GROUP BY "CLIENT", "PRODUIT" HAVING SUM("CA") > 10000
Je leur dit tu fais
SELECT * FROM fonction_aggregat(['CLIENT','PRODUIT'], '{"month":"=4", "sumca":">10000"}')
Pour la base de données il n'y a aucune différence en terme SQL, il y a un petit surcout lors de la préparation de la procédure fonction_aggregat, mais qui est négligeable et qui se rembourse largement si la procédure est appelée plus d'une fois. Le surcout du parsing est infime, les I/O sont divisés par 10 par rapport à des requêtes classiques ou des vues, je peux forcer le plan d’exécution que je veux, la priorité, le temps CPU etc.
Et une fois de plus ça ne rempli pas d'autres rôle qu'une vue.
Ça ne demande rien de tout ça. Ça demande à créer des classes/fonctions en plus oui. Le reste est uniquement dépendant de ton besoin. Ce n'est pas parce que tu organise ton code pour qu'il soit distribuable qu'il faut le distribuer.
Mais pourquoi j'irais créer des fonctions (ou classes) de filtrage et de présentation de données dans mon code, alors que ça va pénaliser la base de données. Si je ressors la table entière, l'impact I/O va être délirant - si je fait une partie du filtrage coté BDD (WHERE ou HAVING) pourquoi j'irais mettre le reste du filtrage dans mon appli ? Filtrer et présenter les données c'est le boulot de la base, et elle va le faire beaucoup mieux, beaucoup plus vite (surtout en BDD relationnel) que mon appli qui voit devoir commencer par tout remapper avant de pouvoir finir le boulot.
Ton code s'exécute sans demander de temps CPU ?
OUI ! Le cout CPU des procédures que je cite est nul, voire négatif par rapport à une execution SQL brute de décoffrage. La première exécution va prendre quelques pouillèmes de millisecondes en plus (et encore une très grosse procédure) - toutes les exécutions suivantes seront plus rapide et moins consommatrice de CPU que l'équivalent SQL. La BDD n'aura plus à faire le préscan, à choisir entre le bitmap scan ou le seq scan ou les index, à définir la taille des rows de sortie, à dimensionner les flux etc. Tout ce travail aura été fait lors du premier appel, et les appels suivant seront plus rapides et moins gourmands que le SQL.
Quel est l'intérêt ? Tu peux calculer tes projections lors de l'alimentation de cette base. Si un changement de besoin interviens, tu peut détruire ta base de reporting et la reconstruire avec tes nouvelles projections.
Les données sont en flux continue depuis plusieurs sources. C'est pas parce qu'une source change que je vais détruire toute ma base et refaire toutes mes vues.
Elles sont juste une misère à tester :)
Par rapport à des milliers de vues, ou des milliers de requètes SQL plus ou moins propres et subtilement différentes dans le code de l'appli ? Mon choix est vite fait…
Très très bien pour le suivi haute resistance, scale moins bien que OpenTSDB sur les logs ceci dit. Par contre les insertions simultanées ou en conflit sont assez pénibles à gérer.
Après dans la catégorie "qu'est qu'il fout là celui-là ?" je recommande vivement PostgreSQL avec le cstore_fdw de citus. Moins puissant en insertion, par contre en WORM il dépote grave. Le truc est d'utiliser row_to_json pour faire des requètes sur des tables hétérogènes - et hop on a une vraie base yeSQL qui peut fonctionner comme une base noSQL si on insiste un peu.
Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction
GNI ? L'exemple que je donne c'est la réponse à un besoin exprimé par la direction au niveau base de données. La base de données elle même a probablement été créé pour répondre à un besoin exprimé par la direction (ou autre). Ça revient à dire que toute base de données qui sert à quelque chose au niveau fonctionnel serait en fait de la logique métier…
Sérieusement, l'exemple que je donne remplace des milliers de vues par une fonction ou procédure stockée. Les vues seraient de la logique métier selon toi ?
Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.
Pourquoi j'irai compliquer mon architecture, rajouter des scripts ou des datastore à droite à gauche si je n'en ai pas besoin ? Tu te plains plus haut de la dispersion des éléments logiques entre plusieurs endroits et ta solution consiste à disperser les éléments data à la place ?
Mon gars qui fait du reporting je préfère grandement qu'il ait une seule connexion via une seule interface plutôt que de le voir ouvrir une connexion à la DB, une autre à l'ETL et une troisième à un datastore quelconque pour pouvoir faire ses rapports.
J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.
Alors dans le désordre :
- Le lock : besoin très minime, c'est de la lecture seule. Si vraiment le besoin s'en fait sentir on peut créer un index sur un timestamp pour s'assurer que toutes les données étaient présentes à l'instant X et qu'aucune n'est arrivée en cours de route. Mais sur du reporting financier/marketing je ne pense pas que ce soit nécessaire (les chiffres de la dernière seconde intéressent peu de monde, généralement on fait ce type de reporting sur des données qui ont au moins 24h )
La tenue de charge en cas de forte demande/grosse quantité de données : Ce sera la même que celle de la base SQL ou NoSQL sous-jacente. Peut importe que ce soit via fonction, vue ou cube OLAP virtuel, si la base de données ne peut pas encaisser la charge d'une façon il y a peu de chance qu'elle puisse l'encaisser d'une autre. Et encore les fonctions et procédures seront plus performantes que les deux autres méthodes.
Le partitionnement ou les cluster : Je ne vois pas de cas ou cela pourrait avoir un impact négatif. Une fois de plus un traitement par fonction ou procédure sera nécessairement meilleur qu'un traitement séquentiel par requête ou par vue. ne serait-ce que parce que lors d'un traitement par fonction la BDD peut travailler en format binaire interne tout du long et ne doit faire la conversion format de sortie des données qu'à la toute dernière étape.
La durée des traitement et la saturation des I/O BDD : Une fois de plus les fonctions et procédures ne peuvent qu'améliorer l'existant sans rien bloquer autour. En plus on peut parfaitement faire une base dédiée reporting (donc sans impact sur la prod) et utiliser des procédures quand même sur cette base. Pour finir il est nettement plus simple de limiter les I/O et la consomation CPU d'une procédure définie que de tous les accès possibles et imaginables à des vues et des tables.
A titre d'information j'utilise ce type de techniques sur des centaines de millions de lignes (données géométriques, ça va très vite) avec des temps de réponses de l'ordre de la milliseconde. C'est un problème de design de base de données et de placement des index - l'utilisation ou non des procedures stockées n'a pas grande influence sur le résultat final.
C'est pourtant des databases du top 5 les plus utilisés (pour tout usage, pas forcément "générique") MongoDb est devant cassandra par exemple.
Ben comme MySQL en son temps. Mais quand on voit les solutions NoSQL disponibles, y compris en libre - on ne peut définitivement pas classer MongoDB dans la catégorie "Outil sérieux et professionnel".
Je ne vois pas comment tu peux avoir une opération complexe qui ne fais pas partie de ta logique métier…
Supposons que tu es une très grosse base, ou pleins de bases, qui contiennent pleins d'éléments différents en fonction des ventes, de la techniques, des investisseurs, des fournisseurs, des clients etc.
Supposons maintenant que quelqu'un veuille faire du reporting avec des données consolidées, parfois par année ou par mois ou encore par produit pour chaque sous ensemble des données précités.
Genre un top ten des clients les plus rentables pour le mois de mars 2015, ou une liste des taux d'incidents par produit en fonction du fournisseur.
Tu as le choix entre trois solutions :
- Choix 1) un super cube OLAP, mais ça ne marche que si les types de données demandés par la direction ne changent pas trop - sinon il faut refaire tous les rapports le jour ou on décide qu'il faut ajouter le respect ou non de ISO-TrucBidule sur tous les déploiements.
Choix 2) 8000+ vues, une pour chaque découpe. C'est la teuf à la maintenance aussi.
Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.
Par exemple une fonction getStatsBy(< col >) qui fournira toutes les infos consolidées possibles et imaginables avec consolidation sur la colonne spécifiée.
Clairement les procédures stockées ne doivent jamais contenir de logique métier, mais elles peuvent être extrêmement pratiques même sans ça.
Effectivement j'ai fais de la boue hier. Mea Culpa - pourtant je sais qu'il ne faut pas essayer d'écrire du code à une heure du mat quand on est claqué…
Ca m'apprendra.
var myPool {
Il manque le = ? Ou ça aurait dû être une définition de fonction ?
Il manque le =
mySocket.on('RST','DESTROY','CLOSE') {
J'imagine que ça aurait dû être mySocket.on(['RST', 'DESTROY', 'CLOSE'], function() {
Oui tout à fait.
La fonction raiseRetryEvent n'est pas définie ici, mais elle n'aura pas accès à curSocket, ce qui paraît bizarre. J'aurais plutôt attendu curSocket.Clients.map(curSocket.raiseRetryEvent.bind(curSocket)), histoire d'avoir d'utiliser une méthode rattachée à curSocket.
C'est une autre façon de faire - j'aime moins car ca duplique des méthodes dans chaque connexion, pour moi la méthode raiseRetryEvent est une méthode de myPool. Comme on est dans le scope, si la fonction n'a pas été surchargée par mySocket il n'y aura pas de soucis.
if(typeof result === 'function')
Ça peut suffire ici, mais il faut faire attention. Il y a beaucoup de choses qui peuvent passer au travers (les classes ES6 sont vues comme des fonctions IIRC, lodash traite aussi de certains cas particuliers : https://github.com/lodash/lodash/blob/4.6.1/lodash.js#L10020).
Certes si je joue avec des lib extérieures et que j'ai pas lu la doc. Mais là j'ai quand même supposément la maitrise de tout le code. J'ai donc le droit de dire que mes clients renvoie soit un callback, soit autre chose qu'une fonction, soit ne renvoie rien.
result(myPool.allocateConnection);
Sans l'implémentation de myPool.allocateConnection, c'est difficile à dire, mais je pense que ça devrait probablement être result(myPool.allocateConnection.bind(myPool));
Là par contre ce serait bizarre, certes je n'ai pas mis le code, mais on se doute que allocateConnection retourne un objet connexion, ou au moins une promesse de connexion à qui en fait la demande. Si le code est correct, il y a peu de chance qu'une telle fonction ait besoin de se référer explicitement à son scope parent.
Ceci étant j'ai voulu (trop) simplifier le code que j'écris d'habitude sur ce genre de cas. Ça plus la fatigue ça devient forcément brouillon.
C'est vrai que
var myCon = myPool.returnPromiseOfConnection(curSocket.Clients[index]);
result(myCon);
aurait été plus lisible.
L'appel à curSocket.cleanup devrait sûrement être en dehors de la boucle.
Clairement oui.
Bref, c'est un bel exemple que le JavaScript est un langage avec beaucoup de pièges.
Oui enfin le fautes de syntaxe et les oublis de keyword c'est de la fatigue pure. JavaScript n'est pas responsable de mes migraines nocturnes non plus.
Après je n'utilise presque jamais bind() dans mon code. Dans ma logique si il y a une fonction qui doit être appelée dans un scope précis, autant l'invoquer depuis ce scope précis. Les mécanismes d'event permettent souvent de faire ça sans grosses difficultés.
Et je pense que les 5 langages que j'ai cités dans mon journal s'en serait tous tirés bien mieux que ça sur cet exemple.
Si on met de coté le fait que j'ai pas exactement servi ma cause en écrivant du code à 1h00 du mat, j'ai un doute.
Elixir peut probablement écrire un code aussi compact et clair pour un codeur Elixir, parce que je sais que c'est possible en Erlang. Maintenant le jour ou il faut trouver un codeur Elixir (ou Erlang d'ailleurs) pour maintenir le bousin parce que le précédent est parti, ca va piquer.
Elm est pas vraiment fait pour ce genre d’âneries. Mais je serai curieux de voir la tête d'un gestionnaire de pool de websockets en Elm. Je n'arrive juste pas trop à avoir un exemple ou ce serait utile ou fun de le faire.
Crystal, je ne pense pas que le langage puisse créer un code aussi compact et lisible. Toute la partie gestion/transmission d'évènements risque d'être plutôt velue sauf erreur de ma part.
les autres je ne les connais pas du tout (non pas que je connaisse les 3 premiers - j'ai essayé mais j'ai pas insisté)
Oui on est d'accord, on peut écrire du code illisible et in maintenable dans n'importe quel langage. Mais en JavaScript a la possibilité de faire du code "propre" même sur des applications techniquement complexe. Ce qui n'est pas toujours possible dans tous les langages.
Un exemple tout bête, si une connexion est cassée, et qu'elle faisait partie d'un pool qui a été utilisé par plusieurs scopes qui sont en attente de réponse. Il faut donc prévenir tous les scopes concernées qu'il faut réessayer, certains vont répondre que c'est possible, d'autres que ce n'est pas possible. Une fois que toutes les fonctions auront répondus, ou après un temps d'attente maximum, il faudra filer une nouvelle connexion à celle qui peuvent réessayer et nettoyer celles qui ne peuvent pas - puis nettoyer proprement la socket pour libérer les descripteurs.
C'est le genre de truc qui rend fou à écrire dans la majorité des langages. Et je ne parle pas de le maintenir.
En JavaScript ça va donner un truc du genre :
var myPool {
...
mySocket.on('RST','DESTROY','CLOSE') {
var curSocket = this;
Promise.allSettled(curSocket.Clients.map(raiseRetryEvent)) //Send an event "retry" to all client of this socket
.timeout(15000) //wait 15 sec max before resolution
.then(function(results) {
results.forEach(function (result, index) {
if(typeof result === 'function') // callback sent from client
{result(myPool.allocateConnection);}
else
{curSocket.Clients[index].cleanup();} //client did not answer with a callback
curSocket.cleanup(); //We do not need to keep the socket alive any longer.
});
})
}
} 11 lignes niveau débutant plus à intermédiaire. Lisible même par des gens qui n'ont jamais fait de javascript de leur vie mais qui connaissent des langages avec une syntaxe similaire. Il n'y a guere que le Promise.allSettled qui peut faire se gratter la tête 30 secondes.
P.S le code est présenté de façon très moche, mais j'arrive pas à faire mieux…
Un article parmi d'autres qui évoquent certains problèmes de node/js The Node.js Event Loop is a Damn Mess
Mouai aussi.
Tous les problèmes évoqués ont des solutions. Certaines sont d'ailleurs évoquées dans le texte. Oui si on surcharge un certain type d'I/O sans prendre de précautions on peut exploser l'appli. Comme dans n'importe quel autre langage.
Mais bon en JavaScript
a) On a généralement beaucoup plus de marge avant que ça ne se produise. Un script JS accepte et traite les requêtes I/O a des vitesses démentielles pour le peu de code écrit par le dev.
b) On a systématiquement une pléthore de solutions :
- Trop de petites demandes en simultané ? Ben on lance une seconde, puis une troisième instance de la même appli, que ce soit avec de la proxification (nginx par exemple) ou via le forking natif node
- Le back-end n'arrive pas à suivre ? Ben on fait du state counting quand on rentre dans les promesses/event loops problématiques et on limite le nombre de connexions au backend.
- Certaines opérations de calculs prennent trop de temps CPU et pourissent le time sharing ? Ben on les exporte dans des workers.
-Certains backend n'ont pas la politesse de nous insulter ou de nous raccrocher au nez quand ils ne peuvent pas traiter la demande ? setTimeout() et c'est réglé.
-Trop de callbacks - on utilise des promesses A+
-Trop de promesses illisibles imbriquées les unes dans les autres ? Ben scope dédié avec un event loop.
-Une instance Node bouffe trop de mémoire ? Ben on ferme la création de nouvelles sessions (on laisse ça à d'autres instances) et on fait un graceful restart.
Etc.
Et très honnêtement citer PHP comme exemple du truc à faire ? Sur les threads par session ? On parle bien du langage qui oblige à mettre des entrées dans le cron toutes les X heures pour éviter les memory leak, et qui va bazarder toute la session si un seul évènement non interceptable se pointe ? PHP qui va prendre 2000 descripteurs, des heures de debug et l'aide d'un module Apache de rewriting pour faire un routage web correct en cas de forte charge ? Sérieusement ?
JavaScript a des défauts, beaucoup même, mais malgré les très gros progrès de PHP ces dernières années - il ne tient pas une seconde la comparaison avec NodeJS + Koa/Express.
La personne qui a écrit cette article ne donne pas d'exemples concrets (juste une analogie idiote qui revient à dire que chaque scope amènerait du temps CPU avec lui à l’instanciation GNI ???) - Mais à mon sens il s'agit d'un cas typique d'un mec qui veut faire du PHP/Java/Ruby/C++ ou autre en JavaScript, et qui se plaint que ça ne marche pas.
Cette phrase en particulier
Exceeding the stack size is so common because there is no good way for the programmer to slow down the influx of operations from the execution queue while all these unreturned function calls are performing work.
Pourrait difficilement être plus fausse. J'ai rarement vu de langage qui offrait autant de méthodes simples, lisibles et maintenables pour gérer les évènements asynchrones.
Personnellement j'adore JavaScript, c'est pour moi le langage le plus abouti qui soit à l'heure actuelle. Mais il faut bien comprendre que depuis le début il essaye de se faire passer pour ce qu'il n'est pas.
JavaScript est un langage prototypal, mono thread orienté vers la programmation événementielle. Et c'est tout. Pour tout un tas de raisons on lui a donné une syntaxe aussi proche du C++/Java que possible - alors qu'il est plutôt proche des langages fonctionnels. On va dire que ça a grandement aidé à son adoption (c'est pas Erlang ou Racket qui peuvent prétendre avoir réussi à séduire les foules même si ils sont meilleurs sur bien des points).
Maintenant il faut bien comprendre qu'il s'agit de maquillage. En JavaScript vous avez des Scopes (ou états si vous préférez) qui contiennent des paramètres qui peuvent eux mêmes être des scopes. Ces scopes se partagent un temps d’exécution sur un seul thread en utilisant des évènements pour se passer la main les uns aux autres. Voilà c'est tout. Il y a tout en haut des prototypes qui peuvent servir de moules, c'est pratique mais pas franchement essentiel. Ça évite de devoir se fader une lib en plus pour la gestion des tableaux et des chaines principalement.
Tout le reste, et ça inclue les notions de variables, d'objet, de fonction etc, ne sont que des postiches pour faire plaisir aux codeurs C/C++/Java.
Une fois qu'on a compris ça, on arrête de coder en JavaScript comme si il s'agissait d'un langage procédural, et ça va beaucoup mieux.
Après concernant la multitude de bibliothèque en pré-alpha, c'est vrai que npm+GitHub n'a pas simplifié la tache. On manque en Javascript d'une bibliothèque standard. Mais à moins que vous soyez en train de coder un shell ou un système d'init en JS (là on crache du sang, je confirme), on trouve toujours d'excellente libs qui facilitent le boulot dans des proportions hallucinantes. J'ai écrit une interface console pour le pilotage et le monitoring d'appareils via TL1 ou SNMP en quelques heures (et encore parce que je ne connaissais pas bien TL1).
Après il y a des limitations, pour la crypto, le temps réel (même mou) ou le calcul massivement parallèle (les workers c'est bien, mais jusqu'à un certain point), c'est clairement pas le bon langage.
Mais clairement un langage de script qui permet en quelques centaines de lignes d'encaisser et d'envoyer des millions de traitement par seconde tout en restant lisible et debugable et en prenant moins de 100Mo tout compris en exécution - il y en a quand même pas des masses.
Et ensuite il y a des produits dont je ne peux plus me passer en JavaScript. PEG js par exemple - ou D3 js même si il est parfois incohérent avec lui même - ou Blessed
Alors certes ce n'est pas le langage parfait, son plus gros défaut étant les comportement singulier de certaines fonctions suivant que vous soyez en mode exécution (normal) ou en mode évaluation (console de debug navigateur par exemple) CF Understanding delete
Mais les incohérences sont tellement faibles comparées aux autres langages, à moins de faire du Haskell, ca va être dur de trouver un langage raisonnablement moderne et ouvert sur l'extérieur (capable de gérer des I/Os de façon un poil intuitive) qui soit meilleur à ce niveau là.
Après oui, pas mal de gens ont du mal avec la gestion par évènements et se retrouve piégé dans un callback hell, ou à devoir faire des promesses de promesses. Et on est en train de créer des tonnes de sucre syntaxiques pour que les fans de C++/Ruby puissent utiliser leur habitudes de programmations sans dégommer les perfs.
Tant mieux si ça ramène des gens en plus sur le langage. Mais je suis très content en ES5 avec du Q(pour le prototypage)/Bluebird (pour la production), du lodash et les outils précités pour l'habillage.
Il y a des anti-corps correspondant au virus, comme à chaque fois ou presque.
Parce-que si on arrives à la tester, ça permettrait de travailler sur un échantillon beaucoup large que les seuls cas récents.
Ça permet de détecter l'infection de la mère, mais pas celle du nouveau né (qui utilise les anti-corps de la mère pendant au moins 3 mois). Donc ça n'est pas franchement utilisable pour des études.
Si la mère présente des anti-corps, on ne sait pas quand elle a été exposé (ça peut être des mois voire des années avant de tomber enceinte)
Le nouveau né ne présentera des anti-corps propre (ie pas ceux de la mère) qu'à partir de l'age de trois mois - et on saura déjà si il est microcéphale depuis un moment.
Il faudrait donc faire un suivi actif pour savoir quand les anti-corps apparaissent, mais à ce compte c'est plutôt plus simple de tester pour la présence du virus lui même.
Posté par Kaane .
En réponse au journal Debunking sur le virus Zika.
Évalué à 6.
Dernière modification le 15 février 2016 à 17:53.
le mode d'action ne correspond pas à ce que tu décris (cf wikipedia):
Parce que le mode d'action que je décris (IE une altération du développement du cartilage et des os pour la microcéphalie, une dégénérescence due à une réaction auto-imune contre le système nerveux central pour le syndrome de Guillain-Barré) n'a aucun sens dans le cas d'un moustique. Tu dis que l'effet sur l'homme est similaire à celui sur le moustique, le moustique ne possède même pas le type de cellules supposément affectés.
C'est comme de dire qu'un désherbant sélectif qui tue les pissenlits peut expliquer la chute des ongles chez l'homme parce que ça se ressemble comme effet.
Bien entendu que le mécanisme réel de l'insecticide n'a rien à voir avec l'effet chez l'homme. C'est bien le problème de ton argumentation d'ailleurs…
ok, c'est un peu confus, est-il possible d'avoir accès à cette enquête?
L'enquète est en cours, elle sera publiée par la WHO quand les conclusions seront confirmées. L'enquète précédente par le CDC data un peu. http://www.cdc.gov/mmwr/volumes/65/wr/mm6503e2.htm
1 - la mère porte le virus Zika, est-ce que l'enfant le porte automatiquement? Ratio?
Généralement la barrière placentaire n'est pas particulièrement efficace contre les virus. Ceci dit les cellules qui se reproduisent à toute allure d'un foetus ne sont pas des cibles très intéressantes pour un virus en général. Dans le cas de VIH, on estime que 10% des foetus sont infectés par la mère pendant la gestation si la mère est séropositive.
2 - si l'enfant le porte, combien de temps il faut pour qu'il se dissipe?
2 - le fœtus utilise les anti corps de la mère - il guérira en même temps qu'elle.
Je veux bien croire à la théorie du complot, MAIS le mode d'action de l'insecticide sur les insectes semblent proche de ce que l'on observe chez les microcéphalies observées.
Comment une affection des cartilages, du développement osseux et du système nerveux central pourrait-il être similaire entre l'homme et un insecte qui ne possède ni cartilage, ni os, ni système nerveux central ? Même si il y a un effet de l'insecticide (qui est utilisé depuis des années, notamment largement pour les épidémies de dengue ou de chikungunya) - il est très peu probable que l'action spécifique qu'il a sur le moustique soit reproductible chez l'homme.
Comment est-on sûr que l'insecticide n'affecte pas l'embryon?
Il est utilisé depuis des années sans que cet effet secondaire apparaisse, c'est généralement suffisant comme critère. Pour être exact comme on a eu le cas A ET non(B), personne n'a pris le soin de tester pour voir si A => B
Pourquoi ne pas simplement le dire? Et le prouver?
L'OMS est en train de faire une enquête complète - ce genre de choses prend du temps. On ne possède pas de simulateur de corps humain complet avec toutes les variations génétiques possibles et toutes les interactions imaginables entre protéines. Donc il ne reste que l'approche statistique - qui demande du temps.
C'est pur ça que je parle de confirmation d'hypothèse et pas de preuve. Il faudrait bien entendu des chiffres statistiquement significatifs pour confirmer quoi que ce soit.
Tout ce que je dis c'est qu'avoir la probabilité d'infection Zika, connaissant la pathologie microcéphalie n'apporte rien si on a pas une des probabilités pendantes (par exemple la probabilité d'infection zika, connaissant l'absence de pathologie microcéphalie)
Après j'ajoute que vu le mode d'action envisagée actuellement, il ne serait pas surprenant qu'il y ait un plus fort taux d'infectés zika chez les nouveaux nés sains que chez les nouveaux nés malades.
sur 404 microcéphalies au Brésil, seulement 17 (4,2 %) étaient positifs sur le virus Zika
D'après des premiers éléments d’enquêtes, l'influence du virus Zika sur la microcéphalie n'existe que pendant le début de la grossesse (avant les trois premiers mois, probablement pendant les trois premières semaines) - l’enquête sera terminée dans quelques semaines, mais il est normal si l'hypothèse est confirmé (i.e que le virus ne cause des déformations que si il est actif dans les trois premiers mois de grossesse ) que les nouveaux nés microcéphales et les mères ne soient plus porteur du virus 6 mois plus tard.
Il serait plus inintéressant d'avoir le taux de bébés non microcéphales infectés. Si ce nombre est sensiblement supérieur (par exemple si plus de 6% des bébés non microcéphales sont infectés) on irait dans le sens de la double confirmation d'hypothèse, à savoir :
- Zika a une influence
- Seulement sur les premiers mois de grossesse.
[^] # Re: Bug ferme chez tmux
Posté par Kaane . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 6.
Ben oui, mais dans systemd, la slice système (ie le/les cgroup(s) attribué au lancement de processus en mode service) n'a pas le même fonctionnement que les slices utilisateurs. Donc si tu lances un processus en tant qu'utilisateur et que pour une raison X ou Y tu veux le conserver bien que tu fermes ta session - tu l'as un peu dans l'os.
En ce qui concerne daemon() c'est un utilitaire "à la sauce" sysV init. En d'autres termes c'est un toolkit qui facilite le double fork et la migration des input/output depuis un pty/tty vers un autre.
a) C'est très compliqué à utiliser en cours de route (ie c'est pas facile de démoniser à la volée un processus qui n'a pas été prévu pour - notamment qui ne va pas migrer sa mémoire, environnement, threads etc. quand il va se prendre un fork dans les dent). daemon() est plutôt destiné à être utilisé au lancement du processus
b) systemd en a rien à faire de daemon(), le process aura été lancé depuis une slice utilisateur, donc il va rester dans son cgroup utilisateur. En d'autres termes, daemon() ou pas, ou moment ou la slice sera nettoyée (par exemple à la fermeture de session) le processus va gicler (c'est d'ailleurs bien là le soucis qui nous préoccupe aujourd'hui)
c) Si on fait avaler à systemd une slice dégénérée (ie une slice utilisateur qui est considérée par systemd comme une slice système - voire une slice mère de la slice système) ca passe. Par contre créer ce type de slice est complexe, non supportée et casse beaucoup de choses (logind par exemple - pour citer le truc le plus impactant). A part en expérimentation pour faire joujou, je déconseille vivement.
[^] # Re: pour implémenter : enrober dans une fonction
Posté par Kaane . En réponse au journal Haskell -- Évaluation paresseuse. Évalué à 0.
Je te rassure en javascript on arrive à des résultats similaire avec des iterators.
[^] # Re: Collision
Posté par Kaane . En réponse au journal zpaq : backup incrémental avec déduplication . Évalué à 4.
ZFS procède aussi comme ceci quand la déduplication est activée, mais existe un mode de déduplication qui gère les collisions
Oui, enfin sauf que ZFS c'est pas du SHA1 mais du SHA256 par défaut et qu'il y a d'autres indicateurs qui évitent pas mal de collisions même sans verify. Par exemple les deux blocs doivent avoir la même taille (ZFS utilise des blocs de taille variable).
# Les réponses classiques
Posté par Kaane . En réponse au sondage Quels sont les mots que vous employez le plus dans un contexte d'engagement ?. Évalué à 9.
"Chargez", "oui je le veux" et "sain de corps et d'esprit".
Pour les mots les moins utilisés :
"Protozoaire", "Hyperboloïde" et "Archéoptéryx"
[^] # Re: Merci
Posté par Kaane . En réponse au journal Zabbix, autossh, systemd. Évalué à 4.
Page Wikipedia
Grosso-modo quand tu essayes de faire de la haute disponibilité, de la continuité de service etc. tu te retrouves à devoir gérer des systèmes qui dysfonctionnent mais qui ne s'en rendent pas forcément compte. Il te faut donc des mécanismes qui permettent à un arbitre de prendre des décisions, typiquement tuer ou isoler une instance et un promouvoir une autre comme chef de file. Dans ce genre de cas il faut faire très attention à ce que l'instance dont tu cherches à te débarrasser ne puisse plus agir sur les ressources à présent gérées par l'instance que tu cherches à promouvoir.
D’où le terme de fencing - mise en enclos.
[^] # Re: Merci
Posté par Kaane . En réponse au journal Zabbix, autossh, systemd. Évalué à 1.
Alors on commence par la fin :
J'utilise toujours ifconfig. Sur mes vms j'ai des cartes réseaux qui sont rajoutés dynamiquement, des VPN et des émulateurs ports com qui viennent se mettre par dessus en fonction des besoins et malgré plusieurs tentatives je ne vois pas comment gérer ce genres de choses avec ifup, ip et consors. Surtout que je n'ai pas forcément besoin de TCP/IP sur ces cartes, et que je ne veux pas surtout pas de link-local/mDNS.
Donc sur mes cartes dynamiques, c'est des sets de règles udev et des scripts à base d'ifconfig qui se lancent.
Par contre route, clairement je l'utilise quand j'ai besoin. ifconcig ne pas faire grand chose niveau route.
En ce qui concerne le lancement du wrapper, il est lancé par systemd dans le mode le plus bête possible (pas de surveillance, pas de restart, forcé dans un slice dégénéré avec des droits sur la majorité des cgroups etc.) Le fait que systemd ait été choisit par Debian m'impacte peu. Je vais utiliser les outils Debian dans la mesure du possible, mais très vite je diverge de ce qui est fourni. Pour Apache, Nginx, Postgres/PostGIS, postfix, Nagios/Zabbix, Java/Tomcat etc. J'utilise mes propres packages avec mes propres scripts d'init. Dans la majorité des cas les choix fait par Debian ne sont pas les choix optimaux pour ma production. Pour moi Debian est une base (et un très bonne base, j'aime vraiment beaucoup cette distribution) mais je n'ai aucune hésitation à m'écarter de cette base si ça m'apporte quelque chose.
En ce qui concerne systemd strictement, la réponse courte est que systemd a trop de lacunes par rapport aux systèmes d'init historiques pour me permettre de faire tout ce dont j'ai besoin. J'ai besoin de services dynamiques, j'ai besoin de pouvoir forcer certains démarrages en mode séquentiel sans pour autant qu'il y ait dépendance (i.e le service b doit se lancer après le service a et ce même si le service a échoue à se lancer - ce genre de condition sont très courantes quand on fait du fencing notamment) et par dessus tout j'ai besoin que des utilisateurs des machines distantes et des services puissent relancer d'autres services sans nécessairement avoir les droits root (et également sans avoir à créer des slices dégénérés tous les quatre matin)
Pour finir avec ton tutorial, je l'ai lu comme un exemple simple à compléter (que ce soit avec de l'ansible, du saltstack ou des recette cook) et j'ai bien conscience que la pédagogie va parfois à l'encontre de la propreté/qualité. La méthode qui consiste à donner un exemple qui fonctionne et que tout le monde comprend - avant d'expliquer pourquoi il ne faut jamais faire comme ça - est tout à fait valable.
C'est juste la réaction de Christophe B. avec notamment son "En plus j'aime bien comment tu gères systemd / finalement c'est pas si compliqué" qui m'a fait froid dans le dos.
[^] # Re: Merci
Posté par Kaane . En réponse au journal Zabbix, autossh, systemd. Évalué à 3.
Le problème c'est que si tu as 100 agents à collecter (et ça va vite de monter à 100 agents et plus) tu te retrouves avec 100 services
- Que tu dois maintenir/mettre à jour
- Que tu dois éventuellement monitorer à leur tour
- Que tu dois documenter
- Qui ne sont pas vraiment liés à Zabbix (ce sont des tunnels), mais qui ont un impact sur la production si ils tombent.
etc.
De plus je me met dans la peau de l'admin system qui reprend le truc (l'ancien admin est en fuite pour cause de compte en banque dans les iles sud américaines - et n'est absolument pas joignable ) , il va dans la config du service (donc plus Zabbix puisque SSH est intégré maintenant, mais un autre) et là il voit que les sondes sont accédées par 127.0.0.1:30000, 127.0.0.1:30002 … 127.0.0.1:30100. Il est content.
Il va alors chercher le truc qui ouvre le tunnel, et joie, santé, bonheur il tombe sur plus de 100 fichiers de services dans lib/systemd et etc/systemd (ben oui, il y a pas que Zabbix dans la vie). Si l'admin précédent a été très propre il va s'en sortir - par contre si il a été un peu brouillon ou un peu trop prudent on va avoir du NEW-ssh-tunel-XXXX-YYYY-test-DONT_ENABLE.service par paquets. Et vas-y de tester lesquels sont activés et lesquels sont éteints. Eventuellement il sera bon pour faire un tour sur le routeur/collecteur pour voir si il s'agit du lien OOB ou du monitoring spécifique d'un port pour un client.
Personnellement c'est typiquement un des cas ou j'envoie balader systemd (traduction je lui demande de lancer un wrapper et de ne surtout pas s'en occuper) et ou je passe des variables d'environnement (ou des fichiers de conf - ca marche aussi) dynamiquement à mon wrapper qui fait du coup office de pseudo gestionnaire de service.
Je centralise toute ma conf en un point, mon wrapper lance les tunnels, fait les test et finalement lance le collecteur.
Mais maintenant je me dis que je suis peut-être un dino, et que bien entendu tout admin de moins de 35 ans se ruera sur /etc/systemd et comprendra la conf en deux minutes.
[^] # Re: Merci
Posté par Kaane . En réponse au journal Zabbix, autossh, systemd. Évalué à 3.
D'avance toutes mes excuses, car je n'arrive pas à formuler ma question d'une façon qui ne sonne pas comme un troll - surtout vis à vis de mon passif concernant systemd.
Ma question est la suivante : quand tu dis
Es-tu sérieux ou sarcastique ?
Pour moi le type d'automatisation mis en place par ghusson pour la mise en place des différents services et clients est le pire des cauchemars, que ce soit en terme de suivi, de maintenance, de reprise (le mec qui ne sait pas comment on a procédé il va un peu se gratter la tête pour comprendre) etc.
Suis-je le seul dans ce cas ?
[^] # Re: Facile!
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 7.
Je ne calcule pas mes projections d'une façon ou d'une autre, je créé des vues - il n'y a pas de calcul coté BDD. Une vue SQL par exemple c'est juste un test qui dit "si on te demande les données de TITI, renvoie à la place les données de TATA ". Et comme je n'ai pas envie de créer toutes les vues possibles et imaginables je fais une fonction à la place. Il n'y a aucun calcul spécifique métier qui est fait en base. Ce ne sont que des opérations de consolidation et d'agrégation génériques. Je n'ai rien besoin de valider avec mes utilisateurs si ce n'est l'interface qu'ils doivent utiliser. Plutôt que de leur dire tu fais
SELECT * from (
SELECT …
UNION SELECT …
UNION SELECT …
UNION SELECT …
JOIN
SELECT …
UNION SELECT …
…
ON …
) WHERE month=4 GROUP BY "CLIENT", "PRODUIT" HAVING SUM("CA") > 10000
Je leur dit tu fais
SELECT * FROM fonction_aggregat(['CLIENT','PRODUIT'], '{"month":"=4", "sumca":">10000"}')
Pour la base de données il n'y a aucune différence en terme SQL, il y a un petit surcout lors de la préparation de la procédure fonction_aggregat, mais qui est négligeable et qui se rembourse largement si la procédure est appelée plus d'une fois. Le surcout du parsing est infime, les I/O sont divisés par 10 par rapport à des requêtes classiques ou des vues, je peux forcer le plan d’exécution que je veux, la priorité, le temps CPU etc.
Et une fois de plus ça ne rempli pas d'autres rôle qu'une vue.
Mais pourquoi j'irais créer des fonctions (ou classes) de filtrage et de présentation de données dans mon code, alors que ça va pénaliser la base de données. Si je ressors la table entière, l'impact I/O va être délirant - si je fait une partie du filtrage coté BDD (WHERE ou HAVING) pourquoi j'irais mettre le reste du filtrage dans mon appli ? Filtrer et présenter les données c'est le boulot de la base, et elle va le faire beaucoup mieux, beaucoup plus vite (surtout en BDD relationnel) que mon appli qui voit devoir commencer par tout remapper avant de pouvoir finir le boulot.
OUI ! Le cout CPU des procédures que je cite est nul, voire négatif par rapport à une execution SQL brute de décoffrage. La première exécution va prendre quelques pouillèmes de millisecondes en plus (et encore une très grosse procédure) - toutes les exécutions suivantes seront plus rapide et moins consommatrice de CPU que l'équivalent SQL. La BDD n'aura plus à faire le préscan, à choisir entre le bitmap scan ou le seq scan ou les index, à définir la taille des rows de sortie, à dimensionner les flux etc. Tout ce travail aura été fait lors du premier appel, et les appels suivant seront plus rapides et moins gourmands que le SQL.
Les données sont en flux continue depuis plusieurs sources. C'est pas parce qu'une source change que je vais détruire toute ma base et refaire toutes mes vues.
Par rapport à des milliers de vues, ou des milliers de requètes SQL plus ou moins propres et subtilement différentes dans le code de l'appli ? Mon choix est vite fait…
[^] # Re: L'OS n'est pas le problème
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Je suit de loin riak qui a l'air très bien.
Très très bien pour le suivi haute resistance, scale moins bien que OpenTSDB sur les logs ceci dit. Par contre les insertions simultanées ou en conflit sont assez pénibles à gérer.
Après dans la catégorie "qu'est qu'il fout là celui-là ?" je recommande vivement PostgreSQL avec le cstore_fdw de citus. Moins puissant en insertion, par contre en WORM il dépote grave. Le truc est d'utiliser row_to_json pour faire des requètes sur des tables hétérogènes - et hop on a une vraie base yeSQL qui peut fonctionner comme une base noSQL si on insiste un peu.
[^] # Re: Facile!
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 6.
Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction
GNI ? L'exemple que je donne c'est la réponse à un besoin exprimé par la direction au niveau base de données. La base de données elle même a probablement été créé pour répondre à un besoin exprimé par la direction (ou autre). Ça revient à dire que toute base de données qui sert à quelque chose au niveau fonctionnel serait en fait de la logique métier…
Sérieusement, l'exemple que je donne remplace des milliers de vues par une fonction ou procédure stockée. Les vues seraient de la logique métier selon toi ?
Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.
Pourquoi j'irai compliquer mon architecture, rajouter des scripts ou des datastore à droite à gauche si je n'en ai pas besoin ? Tu te plains plus haut de la dispersion des éléments logiques entre plusieurs endroits et ta solution consiste à disperser les éléments data à la place ?
Mon gars qui fait du reporting je préfère grandement qu'il ait une seule connexion via une seule interface plutôt que de le voir ouvrir une connexion à la DB, une autre à l'ETL et une troisième à un datastore quelconque pour pouvoir faire ses rapports.
J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.
Alors dans le désordre :
- Le lock : besoin très minime, c'est de la lecture seule. Si vraiment le besoin s'en fait sentir on peut créer un index sur un timestamp pour s'assurer que toutes les données étaient présentes à l'instant X et qu'aucune n'est arrivée en cours de route. Mais sur du reporting financier/marketing je ne pense pas que ce soit nécessaire (les chiffres de la dernière seconde intéressent peu de monde, généralement on fait ce type de reporting sur des données qui ont au moins 24h )
La tenue de charge en cas de forte demande/grosse quantité de données : Ce sera la même que celle de la base SQL ou NoSQL sous-jacente. Peut importe que ce soit via fonction, vue ou cube OLAP virtuel, si la base de données ne peut pas encaisser la charge d'une façon il y a peu de chance qu'elle puisse l'encaisser d'une autre. Et encore les fonctions et procédures seront plus performantes que les deux autres méthodes.
Le partitionnement ou les cluster : Je ne vois pas de cas ou cela pourrait avoir un impact négatif. Une fois de plus un traitement par fonction ou procédure sera nécessairement meilleur qu'un traitement séquentiel par requête ou par vue. ne serait-ce que parce que lors d'un traitement par fonction la BDD peut travailler en format binaire interne tout du long et ne doit faire la conversion format de sortie des données qu'à la toute dernière étape.
La durée des traitement et la saturation des I/O BDD : Une fois de plus les fonctions et procédures ne peuvent qu'améliorer l'existant sans rien bloquer autour. En plus on peut parfaitement faire une base dédiée reporting (donc sans impact sur la prod) et utiliser des procédures quand même sur cette base. Pour finir il est nettement plus simple de limiter les I/O et la consomation CPU d'une procédure définie que de tous les accès possibles et imaginables à des vues et des tables.
A titre d'information j'utilise ce type de techniques sur des centaines de millions de lignes (données géométriques, ça va très vite) avec des temps de réponses de l'ordre de la milliseconde. C'est un problème de design de base de données et de placement des index - l'utilisation ou non des procedures stockées n'a pas grande influence sur le résultat final.
[^] # Re: L'OS n'est pas le problème
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
C'est pourtant des databases du top 5 les plus utilisés (pour tout usage, pas forcément "générique") MongoDb est devant cassandra par exemple.
Ben comme MySQL en son temps. Mais quand on voit les solutions NoSQL disponibles, y compris en libre - on ne peut définitivement pas classer MongoDB dans la catégorie "Outil sérieux et professionnel".
[^] # Re: Facile!
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 10.
Supposons que tu es une très grosse base, ou pleins de bases, qui contiennent pleins d'éléments différents en fonction des ventes, de la techniques, des investisseurs, des fournisseurs, des clients etc.
Supposons maintenant que quelqu'un veuille faire du reporting avec des données consolidées, parfois par année ou par mois ou encore par produit pour chaque sous ensemble des données précités.
Genre un top ten des clients les plus rentables pour le mois de mars 2015, ou une liste des taux d'incidents par produit en fonction du fournisseur.
Tu as le choix entre trois solutions :
- Choix 1) un super cube OLAP, mais ça ne marche que si les types de données demandés par la direction ne changent pas trop - sinon il faut refaire tous les rapports le jour ou on décide qu'il faut ajouter le respect ou non de ISO-TrucBidule sur tous les déploiements.
Choix 2) 8000+ vues, une pour chaque découpe. C'est la teuf à la maintenance aussi.
Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.
Par exemple une fonction getStatsBy(< col >) qui fournira toutes les infos consolidées possibles et imaginables avec consolidation sur la colonne spécifiée.
Clairement les procédures stockées ne doivent jamais contenir de logique métier, mais elles peuvent être extrêmement pratiques même sans ça.
[^] # Re: L'OS n'est pas le problème
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 10.
MongoDb ? Franchement, ce truc est encore plus bricolé que MySQL - et Redis comme base de données générique ? Vraiment ?
Restons sérieux trente secondes.
[^] # Re: Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 1.
Effectivement j'ai fais de la boue hier. Mea Culpa - pourtant je sais qu'il ne faut pas essayer d'écrire du code à une heure du mat quand on est claqué…
Ca m'apprendra.
Il manque le =
Oui tout à fait.
C'est une autre façon de faire - j'aime moins car ca duplique des méthodes dans chaque connexion, pour moi la méthode raiseRetryEvent est une méthode de myPool. Comme on est dans le scope, si la fonction n'a pas été surchargée par mySocket il n'y aura pas de soucis.
Certes si je joue avec des lib extérieures et que j'ai pas lu la doc. Mais là j'ai quand même supposément la maitrise de tout le code. J'ai donc le droit de dire que mes clients renvoie soit un callback, soit autre chose qu'une fonction, soit ne renvoie rien.
Là par contre ce serait bizarre, certes je n'ai pas mis le code, mais on se doute que allocateConnection retourne un objet connexion, ou au moins une promesse de connexion à qui en fait la demande. Si le code est correct, il y a peu de chance qu'une telle fonction ait besoin de se référer explicitement à son scope parent.
Ceci étant j'ai voulu (trop) simplifier le code que j'écris d'habitude sur ce genre de cas. Ça plus la fatigue ça devient forcément brouillon.
C'est vrai que
var myCon = myPool.returnPromiseOfConnection(curSocket.Clients[index]);
result(myCon);
aurait été plus lisible.
Clairement oui.
Oui enfin le fautes de syntaxe et les oublis de keyword c'est de la fatigue pure. JavaScript n'est pas responsable de mes migraines nocturnes non plus.
Après je n'utilise presque jamais bind() dans mon code. Dans ma logique si il y a une fonction qui doit être appelée dans un scope précis, autant l'invoquer depuis ce scope précis. Les mécanismes d'event permettent souvent de faire ça sans grosses difficultés.
Si on met de coté le fait que j'ai pas exactement servi ma cause en écrivant du code à 1h00 du mat, j'ai un doute.
Elixir peut probablement écrire un code aussi compact et clair pour un codeur Elixir, parce que je sais que c'est possible en Erlang. Maintenant le jour ou il faut trouver un codeur Elixir (ou Erlang d'ailleurs) pour maintenir le bousin parce que le précédent est parti, ca va piquer.
Elm est pas vraiment fait pour ce genre d’âneries. Mais je serai curieux de voir la tête d'un gestionnaire de pool de websockets en Elm. Je n'arrive juste pas trop à avoir un exemple ou ce serait utile ou fun de le faire.
Crystal, je ne pense pas que le langage puisse créer un code aussi compact et lisible. Toute la partie gestion/transmission d'évènements risque d'être plutôt velue sauf erreur de ma part.
les autres je ne les connais pas du tout (non pas que je connaisse les 3 premiers - j'ai essayé mais j'ai pas insisté)
[^] # Re: Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 4.
Mais j'en ai bien conscience.
Merci d'avoir reformaté le code en tout cas, c'est quand même plus lisible.
[^] # Re: Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 2.
Oui on est d'accord, on peut écrire du code illisible et in maintenable dans n'importe quel langage. Mais en JavaScript a la possibilité de faire du code "propre" même sur des applications techniquement complexe. Ce qui n'est pas toujours possible dans tous les langages.
Un exemple tout bête, si une connexion est cassée, et qu'elle faisait partie d'un pool qui a été utilisé par plusieurs scopes qui sont en attente de réponse. Il faut donc prévenir tous les scopes concernées qu'il faut réessayer, certains vont répondre que c'est possible, d'autres que ce n'est pas possible. Une fois que toutes les fonctions auront répondus, ou après un temps d'attente maximum, il faudra filer une nouvelle connexion à celle qui peuvent réessayer et nettoyer celles qui ne peuvent pas - puis nettoyer proprement la socket pour libérer les descripteurs.
C'est le genre de truc qui rend fou à écrire dans la majorité des langages. Et je ne parle pas de le maintenir.
En JavaScript ça va donner un truc du genre :
var myPool {
...
mySocket.on('RST','DESTROY','CLOSE') {
var curSocket = this;
Promise.allSettled(curSocket.Clients.map(raiseRetryEvent)) //Send an event "retry" to all client of this socket
.timeout(15000) //wait 15 sec max before resolution
.then(function(results) {
results.forEach(function (result, index) {
if(typeof result === 'function') // callback sent from client
{result(myPool.allocateConnection);}
else
{curSocket.Clients[index].cleanup();} //client did not answer with a callback
curSocket.cleanup(); //We do not need to keep the socket alive any longer.
});
})
}
}
P.S le code est présenté de façon très moche, mais j'arrive pas à faire mieux…
[^] # Re: Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 5.
Mouai aussi.
Tous les problèmes évoqués ont des solutions. Certaines sont d'ailleurs évoquées dans le texte. Oui si on surcharge un certain type d'I/O sans prendre de précautions on peut exploser l'appli.
Comme dans n'importe quel autre langage.
Mais bon en JavaScript
a) On a généralement beaucoup plus de marge avant que ça ne se produise. Un script JS accepte et traite les requêtes I/O a des vitesses démentielles pour le peu de code écrit par le dev.
b) On a systématiquement une pléthore de solutions :
- Trop de petites demandes en simultané ? Ben on lance une seconde, puis une troisième instance de la même appli, que ce soit avec de la proxification (nginx par exemple) ou via le forking natif node
- Le back-end n'arrive pas à suivre ? Ben on fait du state counting quand on rentre dans les promesses/event loops problématiques et on limite le nombre de connexions au backend.
- Certaines opérations de calculs prennent trop de temps CPU et pourissent le time sharing ? Ben on les exporte dans des workers.
-Certains backend n'ont pas la politesse de nous insulter ou de nous raccrocher au nez quand ils ne peuvent pas traiter la demande ? setTimeout() et c'est réglé.
-Trop de callbacks - on utilise des promesses A+
-Trop de promesses illisibles imbriquées les unes dans les autres ? Ben scope dédié avec un event loop.
-Une instance Node bouffe trop de mémoire ? Ben on ferme la création de nouvelles sessions (on laisse ça à d'autres instances) et on fait un graceful restart.
Etc.
Et très honnêtement citer PHP comme exemple du truc à faire ? Sur les threads par session ? On parle bien du langage qui oblige à mettre des entrées dans le cron toutes les X heures pour éviter les memory leak, et qui va bazarder toute la session si un seul évènement non interceptable se pointe ? PHP qui va prendre 2000 descripteurs, des heures de debug et l'aide d'un module Apache de rewriting pour faire un routage web correct en cas de forte charge ? Sérieusement ?
JavaScript a des défauts, beaucoup même, mais malgré les très gros progrès de PHP ces dernières années - il ne tient pas une seconde la comparaison avec NodeJS + Koa/Express.
La personne qui a écrit cette article ne donne pas d'exemples concrets (juste une analogie idiote qui revient à dire que chaque scope amènerait du temps CPU avec lui à l’instanciation GNI ???) - Mais à mon sens il s'agit d'un cas typique d'un mec qui veut faire du PHP/Java/Ruby/C++ ou autre en JavaScript, et qui se plaint que ça ne marche pas.
Cette phrase en particulier
Pourrait difficilement être plus fausse. J'ai rarement vu de langage qui offrait autant de méthodes simples, lisibles et maintenables pour gérer les évènements asynchrones.
# Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 10.
Personnellement j'adore JavaScript, c'est pour moi le langage le plus abouti qui soit à l'heure actuelle. Mais il faut bien comprendre que depuis le début il essaye de se faire passer pour ce qu'il n'est pas.
JavaScript est un langage prototypal, mono thread orienté vers la programmation événementielle. Et c'est tout. Pour tout un tas de raisons on lui a donné une syntaxe aussi proche du C++/Java que possible - alors qu'il est plutôt proche des langages fonctionnels. On va dire que ça a grandement aidé à son adoption (c'est pas Erlang ou Racket qui peuvent prétendre avoir réussi à séduire les foules même si ils sont meilleurs sur bien des points).
Maintenant il faut bien comprendre qu'il s'agit de maquillage. En JavaScript vous avez des Scopes (ou états si vous préférez) qui contiennent des paramètres qui peuvent eux mêmes être des scopes. Ces scopes se partagent un temps d’exécution sur un seul thread en utilisant des évènements pour se passer la main les uns aux autres. Voilà c'est tout. Il y a tout en haut des prototypes qui peuvent servir de moules, c'est pratique mais pas franchement essentiel. Ça évite de devoir se fader une lib en plus pour la gestion des tableaux et des chaines principalement.
Tout le reste, et ça inclue les notions de variables, d'objet, de fonction etc, ne sont que des postiches pour faire plaisir aux codeurs C/C++/Java.
Une fois qu'on a compris ça, on arrête de coder en JavaScript comme si il s'agissait d'un langage procédural, et ça va beaucoup mieux.
Après concernant la multitude de bibliothèque en pré-alpha, c'est vrai que npm+GitHub n'a pas simplifié la tache. On manque en Javascript d'une bibliothèque standard. Mais à moins que vous soyez en train de coder un shell ou un système d'init en JS (là on crache du sang, je confirme), on trouve toujours d'excellente libs qui facilitent le boulot dans des proportions hallucinantes. J'ai écrit une interface console pour le pilotage et le monitoring d'appareils via TL1 ou SNMP en quelques heures (et encore parce que je ne connaissais pas bien TL1).
Après il y a des limitations, pour la crypto, le temps réel (même mou) ou le calcul massivement parallèle (les workers c'est bien, mais jusqu'à un certain point), c'est clairement pas le bon langage.
Mais clairement un langage de script qui permet en quelques centaines de lignes d'encaisser et d'envoyer des millions de traitement par seconde tout en restant lisible et debugable et en prenant moins de 100Mo tout compris en exécution - il y en a quand même pas des masses.
Et ensuite il y a des produits dont je ne peux plus me passer en JavaScript. PEG js par exemple - ou D3 js même si il est parfois incohérent avec lui même - ou Blessed
Alors certes ce n'est pas le langage parfait, son plus gros défaut étant les comportement singulier de certaines fonctions suivant que vous soyez en mode exécution (normal) ou en mode évaluation (console de debug navigateur par exemple) CF Understanding delete
Mais les incohérences sont tellement faibles comparées aux autres langages, à moins de faire du Haskell, ca va être dur de trouver un langage raisonnablement moderne et ouvert sur l'extérieur (capable de gérer des I/Os de façon un poil intuitive) qui soit meilleur à ce niveau là.
Après oui, pas mal de gens ont du mal avec la gestion par évènements et se retrouve piégé dans un callback hell, ou à devoir faire des promesses de promesses. Et on est en train de créer des tonnes de sucre syntaxiques pour que les fans de C++/Ruby puissent utiliser leur habitudes de programmations sans dégommer les perfs.
Tant mieux si ça ramène des gens en plus sur le langage. Mais je suis très content en ES5 avec du Q(pour le prototypage)/Bluebird (pour la production), du lodash et les outils précités pour l'habillage.
[^] # Re: sur 404 microcéphalies au Brésil, seulement 17 (4,2 %) étaient positifs sur le virus Zika
Posté par Kaane . En réponse au journal Debunking sur le virus Zika. Évalué à 3.
Il y a des anti-corps correspondant au virus, comme à chaque fois ou presque.
Ça permet de détecter l'infection de la mère, mais pas celle du nouveau né (qui utilise les anti-corps de la mère pendant au moins 3 mois). Donc ça n'est pas franchement utilisable pour des études.
Il faudrait donc faire un suivi actif pour savoir quand les anti-corps apparaissent, mais à ce compte c'est plutôt plus simple de tester pour la présence du virus lui même.
[^] # Re: sur 404 microcéphalies au Brésil, seulement 17 (4,2 %) étaient positifs sur le virus Zika
Posté par Kaane . En réponse au journal Debunking sur le virus Zika. Évalué à 6. Dernière modification le 15 février 2016 à 17:53.
Parce que le mode d'action que je décris (IE une altération du développement du cartilage et des os pour la microcéphalie, une dégénérescence due à une réaction auto-imune contre le système nerveux central pour le syndrome de Guillain-Barré) n'a aucun sens dans le cas d'un moustique. Tu dis que l'effet sur l'homme est similaire à celui sur le moustique, le moustique ne possède même pas le type de cellules supposément affectés.
C'est comme de dire qu'un désherbant sélectif qui tue les pissenlits peut expliquer la chute des ongles chez l'homme parce que ça se ressemble comme effet.
Bien entendu que le mécanisme réel de l'insecticide n'a rien à voir avec l'effet chez l'homme. C'est bien le problème de ton argumentation d'ailleurs…
[^] # Re: Corrélations fortuites
Posté par Kaane . En réponse au journal Debunking sur le virus Zika. Évalué à 3.
http://xkcd.com/552/
[^] # Re: sur 404 microcéphalies au Brésil, seulement 17 (4,2 %) étaient positifs sur le virus Zika
Posté par Kaane . En réponse au journal Debunking sur le virus Zika. Évalué à 7.
Généralement la barrière placentaire n'est pas particulièrement efficace contre les virus. Ceci dit les cellules qui se reproduisent à toute allure d'un foetus ne sont pas des cibles très intéressantes pour un virus en général. Dans le cas de VIH, on estime que 10% des foetus sont infectés par la mère pendant la gestation si la mère est séropositive.
2 - le fœtus utilise les anti corps de la mère - il guérira en même temps qu'elle.
Comment une affection des cartilages, du développement osseux et du système nerveux central pourrait-il être similaire entre l'homme et un insecte qui ne possède ni cartilage, ni os, ni système nerveux central ? Même si il y a un effet de l'insecticide (qui est utilisé depuis des années, notamment largement pour les épidémies de dengue ou de chikungunya) - il est très peu probable que l'action spécifique qu'il a sur le moustique soit reproductible chez l'homme.
Il est utilisé depuis des années sans que cet effet secondaire apparaisse, c'est généralement suffisant comme critère. Pour être exact comme on a eu le cas A ET non(B), personne n'a pris le soin de tester pour voir si A => B
L'OMS est en train de faire une enquête complète - ce genre de choses prend du temps. On ne possède pas de simulateur de corps humain complet avec toutes les variations génétiques possibles et toutes les interactions imaginables entre protéines. Donc il ne reste que l'approche statistique - qui demande du temps.
[^] # Re: sur 404 microcéphalies au Brésil, seulement 17 (4,2 %) étaient positifs sur le virus Zika
Posté par Kaane . En réponse au journal Debunking sur le virus Zika. Évalué à 7.
C'est pur ça que je parle de confirmation d'hypothèse et pas de preuve. Il faudrait bien entendu des chiffres statistiquement significatifs pour confirmer quoi que ce soit.
Tout ce que je dis c'est qu'avoir la probabilité d'infection Zika, connaissant la pathologie microcéphalie n'apporte rien si on a pas une des probabilités pendantes (par exemple la probabilité d'infection zika, connaissant l'absence de pathologie microcéphalie)
Après j'ajoute que vu le mode d'action envisagée actuellement, il ne serait pas surprenant qu'il y ait un plus fort taux d'infectés zika chez les nouveaux nés sains que chez les nouveaux nés malades.
[^] # Re: sur 404 microcéphalies au Brésil, seulement 17 (4,2 %) étaient positifs sur le virus Zika
Posté par Kaane . En réponse au journal Debunking sur le virus Zika. Évalué à 4.
sur 404 microcéphalies au Brésil, seulement 17 (4,2 %) étaient positifs sur le virus Zika
D'après des premiers éléments d’enquêtes, l'influence du virus Zika sur la microcéphalie n'existe que pendant le début de la grossesse (avant les trois premiers mois, probablement pendant les trois premières semaines) - l’enquête sera terminée dans quelques semaines, mais il est normal si l'hypothèse est confirmé (i.e que le virus ne cause des déformations que si il est actif dans les trois premiers mois de grossesse ) que les nouveaux nés microcéphales et les mères ne soient plus porteur du virus 6 mois plus tard.
Il serait plus inintéressant d'avoir le taux de bébés non microcéphales infectés. Si ce nombre est sensiblement supérieur (par exemple si plus de 6% des bébés non microcéphales sont infectés) on irait dans le sens de la double confirmation d'hypothèse, à savoir :
- Zika a une influence
- Seulement sur les premiers mois de grossesse.