On 11 avr, 21:17, Fernando Perez <[email protected]> wrote: > > niveau appli fait du fragment caching > > 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 > > Sinon en astuce sympa, il faut tenter de réécrire ses views afin de > basculer en page caching, ça impose quelques concessions niveau design. > C'est facile à maintenir (en tout cas plus que le fragment) et là le > gain est gigantesque. Sur la homepage ou les pages diggables, c'est un > must-have.> > > 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). > > Intéressant, tu aurais des numéros de commit à indiquer? http://github.com/rails/rails/commit/91d274059536f09dffd87141e570c3eab9ebd9b4 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 --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] -~----------~----~----~----~------~----~------~--~---
