Joris Dedieu a écrit 1614 commentaires

Systemd ne comprend pas HAProxy qui à une façon particulière de se recharger. On ne parle pas de redemarrer - stop puis start - mais de se recharger de façon transparente pour les clients.

Un gars à proposé un patch qui consiste à conserver un processus qui ne fait rien d'autre qu'attendre que haproxy termine. Cela permet de berner systemd.

• C'est un hack horrible
• Ça montre que systemd pose des problèmes qui n'existaient pas les autres init (ce n'est pas forcement une critique).
• Ça pose la question de savoir (de façon fort trollesque) s'il faut modifier les logiciels pour les adapter à systemd.

J'ai oublié de précisé tellement j'étais mort de rire que ce patch n'est pas de l'auteur. Il s'agit d'une contribution qui pour l'heure n'est pas commitée.

Un daemon unix est sensé recharger sa configuration quand on lui envoie le signal SIGHUP,

En l'occurrence ça n'a pas d'objet ici. HAProxy, ne peut pas recharger sa config. Ce n'est pas un bug c'est un choix, pris en connaissance de cause. On peut toujours critiquer ce choix ou en discuter , mais je ne vois pas en quoi il concerne init.

Quand au chroot, c'est un faux argument, systemd n'a aucun problème avec les daemons chrootés correctement écrits, par exemple: Bind, Postfix, OpenSSH, Avahi, etc… idem quant aux daemons tournant dans un chroot.

Il faut comparer ce qui est comparable. HAProxy a un design a un seul process.

pourquoi ne pas corriger la conception défectueuse de HAProxy

Quelle conception défectueuse ? En quoi le fait d'envoyer des signaux à un process pour déclencher une action (ici s’arrêter proprement) poserait un problème. Comme tout daemon pouvant être chrooté, HAProxy est susceptible de ne pas pouvoir relire sa config. Un reload consiste donc à remplacer le process proprement par un autre en essayant de ne pas droper de clients au passage.

Un peu plus lin dans le man on a :

       - SIGUSR1
              Tells  the daemon to stop all proxies and exit once all sessions
              are closed. It is often referred to as the "soft-stop" signal.

       - SIGTTOU
              Tells the daemon to stop listening to all sockets.  Used  inter-
              nally by -sf and -st.

       - SIGTTIN
              Tells  the  daemon  to  restart listening to all sockets after a
              SIGTTOU. Used internally when there was  a  problem  during  hot
              reconfiguration.

       - SIGINT and SIGTERM
              Both signals can be used to quickly stop the daemon.

       - SIGHUP
              Dumps  the  status  of  all  proxies  and servers into the logs.
              Mostly used for trouble-shooting purposes.

       - SIGQUIT
              Dumps information about memory pools into the logs. Mostly  used
              for debugging purposes.

       - SIGPIPE
              This  signal  is  intercepted  and  ignored  on  systems without
              MSG_NOSIGNAL.

Bref, tu peux utiliser les signaux pour piloter ton daemon. Quel défaut de conception !

J'utilise awesome et screen. L'intérêt principal et de pouvoir retrouver mes sessions ssh quand ma connexion internet plante ou d'avoir mon environnement prêt quand je dois intervenir de nuit.
Je lance un urxvt‚ je me connecte a un serveur‚ je récupère mon screen et hop le tour est joué.

En plus ça m'evite de laisser traîner des nohup.out partout.

Bonjour,
Il y a un effort de pour maintenir thttpd vivant (http://opensource.dyc.edu/sthttpd). Je pense qu'ils serait intéressant que tu proposes certains de tes patchs.

Je vais sur ma page personnelle me branler m'extasier devant mon karma.

Il y a aussi qu'aux USA on croit et on mise sur les startup qui deviennent le gros d'aujourd'hui et de demain

Sans invalider ce que tu dis, il ne faut pas non plus évacuer la question financière. Sans être spécialiste de ces questions complexes, quand tu vois qu'une crise financière d'origine Américaine est devenue une crise de la dette Européenne, tu es en droit de te demander à quel point nous finançons via la magie monétaire une partie des dépenses des EU.

Par ailleurs est-ce typiquement Français ou Européen ? Ou mondial ? Quels sont les pays qui arrivent à créer géants à +1 milliard d'euro ?

Au niveau Européen, on a le PIB par habitant le plus élevé au monde, un taux d'endettement moindre que les EU ou le japon et pourtant un manque chronique de pognon. Financer même la recherche à implications immédiates devient difficile. Je ne minimise pas l'incurie de nos dirigeants successifs mais il me semble qu'il y a une question structurelle plus profonde liée au système monétaire international.

jamais eu l'intention d’abandonner son architecture unifiée au profit de DRI/KMS.

Pourtant c'est cette partie qui est vraiment importante. La fin du matériel géré directement par X c'est quand même un sacré progrès dans la propritude du truc.

nVidia a montré depuis des années sa motivation pour sortir un driver de qualité pour ses chipsets sous linux.

Pour préciser, nvidia sort un driver pour X. Celui-ci est porté sous diverses plate-formes (a ma connaissance, Linux, Solaris, FreeBSD). Je pense qu’économiquement pour Nvidia, Solaris reste encore le marché le plus juteux (On pense aux fermes de serveurs pour le rendu 3D des films …).

notamment schizophréne, en France, parmi la population de schizophrènes, on a 60% de fumeurs de cannabis.

Je pense que tu confonds allègrement la cause et l'effet.

Mais c'est pas en leur foutant une machine pourrie que tu vas en faire des bons ingénieurs…

Parce qu'un ingénieur c'est toujours une garantie de qualité du code, c'est sûr :)

Enfin bref de toute facon on est au niveau hello world là.

Tu peux préciser ?

Bien évidement je parlais des machines sur lesquelles tu effectues la validation du code, les tests. Je parle pas de ta jolie station de travail dont je me fiche. Valider le code dans des conditions plus strictes que la prod, pour une application destinée à se faire défoncer sur le web, c'est quand même pas trop demandé ? non ? Mais de toute façon avec les devs c'est toujours pareil. Dès qu'on parle de limiter les ressources, c'est l'adminsys qu'est un gros nul.

C'est tellement grossier comme métrique qu'elle ne sert à rien;

Elle sert à montrer qu'il n'y a en aucun cas 1 million de ligne de code.

mais il fait plus d'un million ligne de code!

git clone http://anongit.freedesktop.org/git/systemd/systemd.git
cd systemd/
find . -type f  | xargs wc -l
...
  259880 total

260000 lignes en contant les scripts les man, la doc. C'est déjà énorme soit, mais il faut pas abuser non plus.

Limiter les ressources sur les machines des devs ca ne sert vraiment pas à grand chose.

Ça te permet quand même de voir si tu as un script qui bouffe de la mémoire, ou est trop long à s'éxécuter ou part dans une boucle d'appels infinie. Ce n'est pas sensé remplacer des tests on est bien d'accord. Mais être dans un environnement strict quand tu développes ne me semble pas un aberration. C'est un peut comme compiler avec -Werror ou exécuter ton code avec valgrind. Bref s'impose un contexte dans lequel tout débordement est fatal.

Un autre exemple tout simple, le cache des objets statiques

Je ne comprends pas ton exemple. Pourquoi ne pas changer le nom du fichier et la valeur de la variable qui le contient tout simplement ? Je ne vois guère de cas ou cela s'avérer impossible.

• toute sortes de minifications et groupements
• il peux "inliner" du js/css/images directement dans le html
• si vous avez spécifié le with/height d'une image dans le source, il peut réencoder l'image aux bonne dimensions/ ou changer son format.

Pourquoi pas dans ce cas une approche de type compilateur, effectuant ces opérations une fois pour toute. C'est exactement comme pour la compression. Pourquoi la faire à la volée sur des ressources statiques qu'il est tellement simple de compresser à la main ? Il suffit ensuite que le serveur choisisse fichier.defalte, fichier.gz ou fichier suivant ce que demande le client.

L'effort de google pour diminuer ses frais de bande passanterendre le web plus rapide est vraiment louable. Ceci dit il pose quand même un léger problème dans la façon partielle (pas partiale) dont il est abordé. Pour beaucoup de Geeks à IPhone5webmasters ce que dit google est parole d'évangile et doit être appliqué sans se poser de question. Ceci dit google n'est pas responsable de ce fait et ce n'est donc pas son procès que je fais ici.

Pour moi, modeste administrateur système ce qui fait la qualité et la rapidité d'un site web peut se résumer en deux points :

1) Son workflow

Un site web est une application et mérite d'être considérée comme telle. Et en tant que telle, il lui faut suivre un cycle de vie rigoureux comprenant notamment, une gestion des versions, des tests, une procédure de publication, un suivie des bugs, bref toutes les choses qu'on fait normalement et naturellement pour n'importe quelle application. C'est bien sûr souvent le cas lorsqu'il s'agit d'applications critiques développés pour des clients qui ont l'habitude de mener des projets informatiques, ou simplement par des gens sérieux qui savent ce qu'ils font. Mais beaucoup de web agencies ne fonctionnent pas ainsi. Le workflow le plus souvent constaté est :

• On développe une charte graphique.
• On colle un CMS sur la prod.
• On colle quelques plugins.
• On passe en prod et on oublie le truc jusqu'à survenue d'un problème.

Lorsque le problème survient :

• On essaye de faire une mise à jour du CMS directement sur la prod.
• On restaure un backup.
• On achète de plus gros serveurs jusqu'à ce que ça marche.
• On débute un nouveau projet en changeant de CMS

L'alibi le plus couramment admis est qu'il s'agit d'un CMS et donc que tout le wokflow de développement est assuré par ailleurs. Pourtant au quotidien je constate que là ou il faut un modeste serveur à certain pour faire tourner des dizaines de sites, certains peinent à en faire fonctionner un seul sur un cluster (toute chose égale par ailleurs) ou encore que l'absence de tests avec des données dans la base est sans doute la cause la plus fréquente de plantage. Notamment avec MySQL qui a des effets de seuil important.

Pour faire un site web rapide et de qualité, il faut donc :

• avoir un environnement de dev séparé de la prod.
• utiliser un gestionnaire de version.
• utiliser un gestionnaire de bugs.
• écrire un jeu de test cohérent avec l'activité finale (et surtout un jeu de données conséquent).
• suivre les résultats des tests pour en déduire des régressions.

2) Le ressources

La rapidité de la réponse renvoyée par un serveur web dépend avant tout de deux paramètres qui sont, le temps d'exécution du script et son empreinte mémoire. C'est peut être con à dire mais un script qui s'exécute vite permet au serveur de répondre rapidement. Moins un script occupe de mémoire, plus il peut être exécuté simultanément un grand nombre de fois et avec plus d'efficacité.

Pour cela quelques conseils :

• le contextes de dev doit limiter les ressources plus fortement que le contexte de prod

Par exemple pour php, il est de bon ton de travailler en dev avec un memory_limit et un max_execution_time plus bas que sur la prod ainsi qu'avec l'open_basedir activé et strict, un nombre d'extensions réduites, suhosin activé et configuré très strictement. Sur la prod on peut alors lâcher du lest pour assurer une bonne fluidité et éviter des plantages imprévus.

• toute évolution doit être évaluée en terme de ressources.

L'impact d'ajout d'extensions ou d'augmentation des limites doit être soigneusement évalué. Ainsi que par exemple le moteur de stockage des sessions, la collecte de statistiques… La encore une évaluation sérieuse nécessite qu'il y ait des données dans la base.

• Les réglages du serveur web doivent correspondre au cas général et pas au cas particuliers.

Les scripts gourmands (type génération de rapports, export, reindexation …) doivent être isolés et exécutés dans un contexte privé séparé du site public. L'upload de gros fichiers doit être effectué par parties afin de s'adapter au contexte global … Le cas typique est l'augmentation du timeout d'apache (essentiel pour résister aux dos type slow lorris) simplement parce qu'un script d'export de base de données qui pourrait très bien s'éxécuter en cron ou sur une autre instance apache met 3 heures à retourner des données

• Les ressources externes doivent être gérée correctement.

Lorsqu'on fait appel à un web service, à une url externe, il faut s'assurer du comportement du script en cas indisponibilité de la ressource. Il faut écrire un vrai client, gérant les timeout, le cache, et les facilités prévues par le protocole (if-modified-since par exemple en http). Les simples fopen("http:// … sont à bannir.

Côté client il n'est pas toujours évident qu'aller chercher jquery chez google soit beaucoup plus efficace que de l'héberger sois même. Cela doit être encore un fois évalué.

3) Conclusion

Vu ainsi ce type de conseils peuvent sembler démesurés pour une petite agence sortant du site à 500 euros. Pourtant il s'agit d'une simple habitude de travail. De nombreux outils existent pour lancer des tests, remplir les bases et finalement lorsque l'habitude est prise c'est plus un gain de temps qu'autre chose.

Voilà c'était mes trois conseils à deux cents pour un web rapide. Ils n'ont rien d'incompatible avec ceux de google. Je pense juste qu'ils sont un préalable nécessaire. Comme il est dit dans l'article, mod_pagespeed est juste un moyen d'éviter de modifier immédiatement ses sites. Je n'ai pas de chiffres exacts mais j'imagine que le surcout machine est important, ne serais-ce que parce que le serveur doit avoir une vision globale de ce qu'est la page. Et c'est pour cela que je ne l'aime pas trop. Pour moi, le web rapide et qualitatif trouve son origine dans les consommateurs de caféine et pas dans ceux d'uranium.

Joris

Supporter OS X, ok, mais comment ?

Comme vlc par exemple. Qui est loin me semble-t-il d'être une application marginale sous Mac OS

Ce journal semble ignoré que Qt un thème permettant d'avoir un look a ma GTK

Mais également que QT est multiplateforme. Firefox n'aurait-il pas supporté Mac OS X beaucoup plus vite s'il avait utilisé QT ?

Ça serait intéressant que tu donnes des détails là

Je peux te donner quelques exemples.

• kern.maxusers limité à 384, soit la même valeur sur un Core2 avec 2GO de ram que sur un 32 coeurs avec 64GO.
• kern.ipc.shm_use_phys est désactivé par défaut
• kern.ipc.maxpipekva ou encore vfs.maxbufspace sont souvent juste alors qu'il y a de la mémoire dispo.
  
• tout ce qui est semaphores et mémoire partagée est extrêmement limité par défaut (voir postgres ou mod_fcgid par exemple).

Ce que je voulais dire avec cette remarque c'est qu'a mon avis, il est tout à fait possible à FreeBSD de tenir le haut du pavé sur ce type de benchs. Mais que cela demande un gros travail de tuning.

.

Est-ce que c'est juste que Linux a été optimisé, ou non, le noyau de Scientific Linux est patché ?

Scientific Linux est un clone de rhel ( ~ Centos). Le noyau est donc celui de red-hat. Le test basé sur pg_bench à pour but d'évaluer les performances au niveau SMP. Grosso-modo on fait monter le nombre de process et on regarde comment ça réagi. C'est un cas bien particulier notamment parce que les clients sont sur la même machine que les serveurs.

En fait il apparaît que trois points sont essentiels :

• l'ordonnancement
• la gestion des sockets (l'effondrement de NetBSD vient probablement de là).
• la gestion de la mémoire partagée

Il s'est avéré que sur ce test Linux et OpenSolaris ont toujours été en tête. Mon hypothèse est que ces noyaux, de part leur utilisation industrielle dans un contexte massivement multiprocesseur sont largement plus optimisés pour ce contexte que les noyaux BSD. Je pense également que FreeBSD souffre beaucoup d'un certain conservatisme dans ses réglages par défaut.

En fait ce qui est important ici, je crois, ce n'est pas que Linux soit meilleur ce qui semble normal vu l’ampleur comparée des projets mais que DragonFlyBSD avec ces 12 bonhommes arrive à réaliser.

Le rapport gain/taille des diff est énorme !

Je rajouterai qu'on sent une évolution psychologique de taille. Considérer l'amd64 comme une vrai architecture et plus comme un x86 amélioré.

Le rapport gain/taille des diff est énorme !

Ceci dit l'ensemble de l'infra pour utiliser les processus légers et les verrous à grain fins et les io non bloquantes est déjà en place. Le gros du travail à finalement été de trouver ce qui coinçait. De plus il ne faut pas oublier le commit sur la topologie des CPU qui fait environ 1300 lignes.

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff_plain/f77c018a1c4b5e9271cf5fcf3912c2ccbea9c0e1

Pour ceux que ça intéresse, le bench complet est là :
http://lists.dragonflybsd.org/pipermail/users/2012-October/017536.html