Bruno Michel a écrit 3285 commentaires

Par contre, si la doc de ton outil est vraiement petite et tiens dans un README, tu devrais peut-être te tourner vers une interface Web à un DCVS qui présenterai le tout de façon ergonomique (genre Github ou Gitorious) …

Dans le cas de github, tu peux même générer une page web assez jolie à partir du README. Cf https://github.com/blog/1081-instantly-beautiful-project-pages

Si le slow-start est significatif. Dans certains cas, spdy est plus lent que HTTP malgré les tas d'autres optimisations apportées à cause de ça. Mais je te rassure, d'autres personnes travaillent aussi sur ce problème.

Un lien sur le sujet : http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=11&ved=0CHIQFjAAOAo&url=http%3A%2F%2Fordinarysky.cn%2Fwp-content%2Fuploads%2F2011%2F04%2FAn_Argument_For_Changing_TCP_Slow_Start.pdf&ei=lVilT4uSNseZ0QX0hsDrAw&usg=AFQjCNGuI5ppVEySFJBS3E5uSQZbd4uEQQ

Dans tes formules, la vitesse, c'est un débit ou une latence ?

Pour les navigateurs web, l'important est la latence, afin de pouvoir afficher le plus vite possible la page. Si tu veux des formules simplifiées, ça donnerait quelque chose comme :

Avec une connexion, la première seconde, tu vas télécharger un 1/4 des données (slow start), puis la deuxième seconde, tu vas télécharger les 3/4 restants (passage de slow start à full speed). Il faut donc 2 secondes en tout.

Avec 4 connexions, chaque connexion va télécharger un 1/4 des données en 1 seconde (slow start). Mais comme ces 4 téléchargements se font en parallèle, au bout d'une seconde, c'est fini. Ça a donc été deux fois plus rapide.

Je t'invite à lire http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/ pour mieux comprendre le TCP slow start.

Forcément, si tu attends d'avoir fini la première requête pour lancer la deuxième, ça va aller moins vite. Les navigateurs font ça en parallèle, hein !

La résolution DNS est loin d'être négligeable quand on parle du temps de chargement d'une page. C'est d'ailleurs pour ça que des outils comme Firebug donnent cette information mais pas l'ARP vers la passerelle ;-)

Une seule connexion TCP est plus rapide que plusieurs connexions TCP

Non, ce n'est pas toujours pas le cas. Par exemple, pour charger une page de LinuxFr.org, ça va bien plus vite en ouvrant 6 connexions qu'une seule à cause du TCP slow start. Même en activant le pipelining, ça reste plus rapide avec plusieurs connexions (même si la différence sera probablement moins marquée).

Pour le problème 3), ça ne concerne pas que les équipements intermédiaires. Les serveurs (hosts) sont aussi impactés. C'est relativement coûteux en ressources de maintenir des connexions keep-alive et c'est souvent un des premiers paramètres pour optimiser un serveur web pour qu'il soit capable d'encaisser de plus fortes charges.

Pour 1), quel est l'intérêt de HTTP/1.1 si c'est pour ouvrir autant de connexions ? On se retrouve à peu de chose près dans la situation de HTTP/1.0. D'un coté, on se plaint que les délais de connexion sont grands et de l'autre, on s'arrange pour créer un maximum de connexions en //. C'est un peu contradictoire, non ?

Les navigateurs ont bien d'autres problèmes à traiter que juste les délais de connexion. L'un de ces problèmes est le TCP slow start. Une connexion TCP ne permet pas d'utiliser tout de suite beaucoup de bande passante, il faut attendre qu'elle "chauffe". Les navigateurs font donc appel à plusieurs connexions en parallèle pour pouvoir télécharger plus vite les différentes ressources d'une page web et donc l'afficher plus vite.

Pour le 2), cela me semble plus un problème de gestion d'architecture qu'un problème de pile TCP/IP. Le problème est la dispersion des ressources. Une page déterminée devrait être chargée au maximum via la même IP.

Si tu te places du coté client, tout pouvoir charger depuis une même adresse IP serait effectivement idéal. Mais il faut également voir l'autre coté. Quand on se place du coté serveur, il y a pas mal de bonnes (ou mauvaises) raisons de vouloir faire autrement. par exemple, on veut souvent pouvoir servir le HTML généré dynamiquement depuis nos serveurs, mais laisser des CDN s'occuper des images, css et js pour des raisons économiques.

2) Le slow start s'amplifie avec plusieurs connexions. Le slow-start est fait pour chacune des connexions en lieu et place d'une seule

Certes, mais si tu veux transférer quelques centaines de ko (une page web avec quelques images, css et js typiquement), tu iras quand même bien plus vite avec plusieurs connexions qu'avec une seule. C'est pour ça que les navigateurs font plusieurs connexions en parallèle : pour récupérer plus vite les ressources.

3) La connexion reste ouverte car il y a du trafic dessus via le SSE. Le keep-alive n'est nécessaire que quand il n'y en a pas. Il n'y a plusieurs méthodes pour le faire, je n'ai pas regardé la situation précise pour DLFP. EventSource ne défini pas la façon de faire mais juste une API

Je dis juste que la connexion reste ouverte pour un visiteur de la tribune car il a toujours une reponse HTTP qui n'a pas fini d'arriver et que cela n'a rien à voir avec le keep-alive.

4) Cela dépend, vous avez fait ce choix mais ce n'est pas le défaut.

La valeur par défaut d'Apache est de 15s, ce qui est toujours bien en-dessous des 115s du firefox. Je maintiens que dans la vraie vie, c'est le serveur et non pas le navigateur qui ferme les connexions keep-alive.

Note aussi que ton exemple avec time ne mesure pas du tout le keep-alive, mais le client_header_tiemout dans la terminologie nginx.

5) Attention, il ne faut pas confondre domaines différents et IP différentes. Les connections TCP sont ouvertes vers une IP et il peut y avoir plusieurs domaine par IP (virtualhost). Lors d'un get en HTTP/1.1, c'est « GET /index.html\n\rHost: moncomaine.com » donc ce n'est pas parce que tu as plusieurs domaines que tu ne peux pas ré-utiliser.

Sauf que dans la vraie vie, que le nouveau nom de domaine soit sur la même IP ou pas, le navigateur va quand même ouvrir une nouvelle connexion TCP au serveur.

Oui, autant pour moi. Je voulais surtout dire qu'avant de pouvoir ouvrir sa connexion vers le serveur web, il faut attendre d'avoir résolu son adresse IP. Mais tu as raison, ça ne compte pas dans les connexions TCP.

Je ne connais plus les chiffres exacts, mais il me semble qu'un site web inclut en moyenne des ressources provenant de 7 ou 8 domaines différents.

Raté, c'est en fait 12 ou 13 domaines d'après http://httparchive.org/trends.php

Ouch, c'est moche de mettre autant de termes techniques sans comprendre mieux que ça comment ça marche derrière. Voici quelques unes de tes erreurs :

• Tu omets les connexions TCP utilisées pour la résolution DNS dans tes calculs.

• Les navigateurs web sont loin d'ouvrir une seule connexion TCP quand ils se connectent à un serveur web. En pratique, ils ouvrent généralement jusqu'à 6 connexions HTTP en parallèle pour télécharger plus vite les ressources (à cause du TCP slow start).

• Si tu as une connexion ouverte quasiment en permanence sur le serveur LinuxFr.org quand tu es sur la tribune, ça n'est absolument pas à cause du keep-alive. C'est juste que l'on utilise du EventSource dont le principe même est de garder la connexion ouverte.

• Le timeout d'une connexion HTTP en keep-alive ne vient pas du navigateur mais du serveur dans la vraie vie. Par exemple, sur LinuxFr.org, c'est configuré à 5 secondes (oui, on est loin des 115s de firefox).

• LinuxFr.org n'est pas forcément représentatif du web. Je ne connais plus les chiffres exacts, mais il me semble qu'un site web inclut en moyenne des ressources provenant de 7 ou 8 domaines différents. Pour chacun d'eux, le navigateur devra faire une résolution DNS, puis ouvrir une ou plusieurs connexions HTTP. Au final, ça fait un paquet de connexions TCP ouvertes à chaque page web visitée.

Les points faibles de la solution me paraissent évidents : ça a un fort impact sur les performances et ça pose des problèmes de sécurité. Je cite la page web de mpm-itk :

Since mpm-itk has to be able to setuid(), it runs as root (although restricted with POSIX capabilities where possible) until the request is parsed and the vhost determined. This means that any security hole before the request is parsed will be a root security hole. (The most likely place is probably in mod_ssl.) This is not going to change in the near future, as the most likely alternative solution (socket passing and its variants) is very hard to get to work properly in a number of common use cases, like SSL.

Par contre, je suis curieux de savoir pourquoi quelqu'un voudrait cette solution. Quels seraient les points forts de faire ça plutôt que de lancer une instance de nginx/apache par utilisateur, plus un reverse-proxy devant ?

Il me semble que c'était le comportement sur l'ancienne version du site.

Pas tout à fait, on avait deux versions des flux sur deux URL différentes : l'une avec des liens en HTTP et l'autre avec des liens en HTTPS. Nous n'avons pas conservé la version avec les liens en HTTPS car nous considérons que c'est une mauvaise solution.

En effet, seuls les liens principaux étaient en HTTPS, pas les liens à l'intérieur des contenus. Nous recommandons plutôt de se connecter en HTTPS sur le site (le cookie de connexion sera uniquement envoyé en HTTPS, et nous faisons automatiquement la redirection HTTP -> HTTPS) ou, pour aller plus loin, d'installer l'extension HTTPS Everywhere.

L'URL est envoyée en clair, mais pas le cookie (il est en HTTPS-only).

Pourtant vous constatez bien aussi le soucis non?

Bah, justement, non.

Serait-il possible d’enlever ce header ?

Oui, c'est fait.

Ouais, lighttpd, c'était sympa il y a quelques années, mais ça a pris un méchant coup de vieux ces dernières années. D'ailleurs, la version 1.5 n'est toujours pas là 5 ans après la version pre ?

Cf https://github.com/nono/linuxfr.org/commit/29d34ed3d3b4a972b6ffa3156e50442a59acd82f

Cf https://linuxfr.org/suivi/url-autres-que-http-cliquables

En bidouillant un peu, on peut y arriver pour le premier niveau mais, à ma connaissance, ce n'est pas possible pour ce qui se trouve après le premier séparateur.

This bunch of zeros should be enough to any use troll.

Avant d'être à court de chiffres, on aura un autre problème : la clé primaire a aussi une limite (2^32, si je me souviens bien).

Pas utiliser de séparateur, c'est pour une question de performances ?

Oui, ça permet de récupérer tous les commentaires sur un contenu déjà triés par MySQL (ORDER BY path). Il ne reste plus qu'à utiliser le code cité initialement pour reconstruire l'arbre.

Avec un séparateur, si tu as un commentaire dont le path est 12.99, il arrivera après celui avec 12.100 comme path alors qu'il lui est pourtant antérieur.

Pour enregistrer des arbres dans une base de données, il existe 3 grandes façons de faire.

La première consiste à avoir un champ parent_id sur chaque élément. C'est celle que l'on rencontre le plus souvent et pourtant, c'est probablement celle qui est la moins intéressante et la moins performante.

La seconde technique est celle utilisée par LinuxFr.org. On la retrouve généralement sous le nom de materialized path. Ça consiste à avoir sur chaque enregistrement un champ path avec la liste des identifiants des parents. Par exemple, si le commentaire 12 a pour parent le commentaire 7, et que le commentaire 7 a pour parent le commentaire 3, alors le commentaire 12 aura pour path 3.7.12 (en fait, pour LinuxFr.org, on remplit les ids sur une taille fixe plutôt que d'utiliser un séparateur, donc ce serait plutôt 00000003000000700000012).

Enfin, la troisième manière est ce que l'on appelle les nested sets. Ça consiste à parcourir un arbre et à donner des numéros à chaque élément. On part de la racine et on fait le tour. Quand on passe à gauche, on remplit le champ lft (left est un mot-clé réservé) et quand on repasse à droite, on remplit le champ rgt (right) :

                        (1) Commentaire n°1 (10)
                           /               \
              (2) Commentaire n°3 (7)   (8) Commentaire n°5 (9)
                 /           \
(3) Commentaire n°7 (4)  (5) Commentaire n°9 (6)

ID | lft | rgt |
 1 |   1 |  10 |
 3 |   2 |   7 |
 5 |   8 |   9 |
 7 |   3 |   4 |
 9 |   5 |   6 |

Il devient aussi alors très facile de retrouver tous les commentaires d'un même fil de discussions. Il suffit de prendre tous ceux qui ont un lft plus grand que celui du commentaire parent et un rgt plus petit que celui du commentaire parent.

Moi j'aime bien les méthodes Agile. C'est un nom plus vendeur pour la méthode Rache, ça fait plus sérieux :)

Il arrive aussi que des gens connaissent bien les méthodes agiles et sachent les appliquer pour que ça ne transforme pas en méthode Rache. Chez af83, selon les projets, on utilise des méthodes séquentielles ou des méthodes agiles. Quand on utilise des méthodes agiles, on commence à avoir assez d'expérience pour que ça passe vraiment bien.

Par contre, on va aussi essayer de faire des projets en Lean, en gros de l'Agile poussé à l'extrême. Là, effectivement, je m'attends à ce que les premiers projets, ça se transforme en méthode Rache.

Rémunération à négocier… De combien à combien, si je commence ma négo à 120k€ l'an ça va?

Si tu es une super-star qui les vaut, peut-être, mais je doute fort que ce soit le cas. Plus probablement, ça devrait tourner autour de 45k€. Je ne suis jamais très à l'aise pour donner un chiffre, car 1. ce n'est pas moi qui négocie le salaire après et 2. c'est très variable selon les profils. Par exemple, ça nous ait déjà arrivé de poster une annonce pour un développeur confirmée et, à cette occasion, on a rencontré un développeur débutant dont l'état d'esprit nous plaisait bien ; on lui a fait une offre mais moins importante que celle affichée dans l'annonce (vu qu'il était moins expérimenté) et cette différence l'a rebuté.

Temps de travail ?

35H

Vacances ? RTT ?

Pour les vacances, ce qui est défini par la loi. Pas de RTT.

Télétravail ?

Ça peut se faire. On est assez hésitant pour avoir une personne qui commence par du télétravail. Certains développeurs sont en télétravail mais on préfère que les nouveaux passent au moins un an dans les locaux.

Si, des gens y avaient pensé avant. Par exemple, http://search.creativecommons.org/ existe depuis un certain temps.

Cf https://github.com/nono/linuxfr.org/commit/a997906b317b2ffd6fc3232cce9e0cf6a3c7122c