Hello,
Comme NZKoz nous le disait en décembre, il réactive The Rails Way
début 2009.
http://www.therailsway.com/2009/1/2/the_rails_way-awaken
\o/
(à suivre)
– Jean-François.
Hello,
Comme NZKoz nous le disait en décembre, il réactive The Rails Way
début 2009.
http://www.therailsway.com/2009/1/2/the_rails_way-awaken
\o/
(à suivre)
– Jean-François.
2009/1/2 ma poire :
Comme NZKoz nous le disait en décembre, il réactive The Rails Way
début 2009.http://www.therailsway.com/2009/1/2/the_rails_way-awaken
\o/
(à suivre)
yep !
séance de rattrapage pour ceux qui n’étaient pas à Paris on
Rails ou RailsConf Europe :
http://www.therailsway.com/2009/1/6/requests-per-second
– Jean-François.
s�ance de rattrapage pour ceux qui n’�taient pas � Paris on
Rails ou RailsConf Europe :http://www.therailsway.com/2009/1/6/requests-per-second
– Jean-Fran�ois.
Il faut raisonner avec des pourcents d’augmentation et non pas avec des
valeurs absolues comme il le fait. D’ailleurs son 5% d’1ms est
totalement absurde.
Dans son exemple, le patch B permet d’obtenir 33% de performances en
plus (ok le patch A en donne 250%), donc loin d’être négligeable. Et
passer de Apache à Nginx permet de gagner 50% de performances en plus,
sachant que pour chaque page visitée, il y aura 20-30 requêtes (à la
mise en cache près) pour charger les différents éléments, donc 6000req/s
c’est pas si grand que ça, après tout dépend de la fréquentation.
C’est plutôt l’optimisation inutile qu’il faut éviter, donc ne pas
chercher à optimiser une appli tant que son temps de réponse reste en
dessous d’un certains seuil.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs