apache à une latence plus importante que nginx ou lighttpd
perceptible par un httperf, pas par un humain
Firefox me donne des temps de reponse tres differents sur une machine
evidemment située sur un reseau local. Donc perceptible par un humain.
Merge tes js et tes css,compresse les avant gzip,
réduit le nombre d’image et fait du css sprite,
configure tes entêtes expires et fait en sorte que les etags soient
les mêmes sur toutes la machines du clusteur,
utilise des cdn et des dns rapides,
utilise du cache static et fait du reverse proxy,
niveau appli fait du fragment caching
Là tes utilisateurs verront la différence. Mais c’est surement pas la
réactivité de nginx/versus apache qui est un facteur de qualité sur la
vitesse perçue. Faut arrêter de délirer.
Rails 2.3.x a actuellement une performance linérairement décroissante
suivant la taille du html rendu, ce qui veut dire qu’une page html de
500K est 2 fois plus lente qu’une page de 250k simplement à cause de
sa taille parce que la bufferisation effectuée via rack était débile
(en gros on met dans le socket tous les @body.each_line!!!). Et j’ai
vu personne hurler au loup bien que ca touche tous les types
d’hébergements (ca a quand même été corrigé en douce dans edge). Tout
ca pour dire qu’il y a d’énorme facteur de progression mais qu’ils ne
sont plus dans le choix de tel serveur Vs tel autre. Mais vraiment pas
du tout.
Je crois qu’on ne pourra pas tomber d’accord et comme le disais
quelqu’un : la difference nous permet de trouver la bonne solution ou
au moins une solution qui nous convient/plait.
Le fragment caching c’est quand même une plaie douleureuse à maintenir
même si le gain est loin d’être négligeable. Personnellement j’ai
abandonné sauf sur les zones vraiment très simple à sweeper.
perso c’est clé intelligente + time based expiry, jamais de sweeper
Intéressant, tu aurais des numéros de commit à indiquer?
Response#each
Juste:
@body.each_line(&callback)
callback.call(@body)
Gain de performance sur une page html/xml de 250k *2 sur une page de
500k *4, plutôt que de faire une IO basé sur une taille mémoire fixe
actuellement rack/rails place sur le socket tous les \n, ce qui est
très loin d’être optimal en ruby
qui font la million de hit par jour, du multithread, de l’em, je
n’arrive pas à voir l’intéret par rapport à un mod_rack si ce n’est
la
fingerprint. Y a un grand secret que j’ignore ?
Ca permet en priorité de ne pas être dépendant d’Apache.
