Some good points in the link - but I'm thinking it still doesn't address the large fundamental increase in response time when having to go through rails for the authentication etc. In both cases in the comparison for example there was no expires time populated.
I'm thinking maybe what i need to address is whether it's normal that adding some extra code paths and a few database calls (authlogic and paperclip lookup) should be taking this extra 300-400ms or so, or whether there is something wrong here? Perhaps I'll need to under the paperclip and authlogic code so I put some logging code in to measure the times? On Dec 16, 7:29 pm, Arun Srini <[email protected]> wrote: > http://www.engineyard.com/blog/2009/your-pages-will-load-faster-with-... > > On Dec 16, 2:19 pm, greghauptmann <[email protected]> wrote: > > > > > thanks - so I do want to have the images etc authenticated as well by > > the way, so this is why I haven't got them under public either... > > > so the two test scenarios are based on doing a "save as" from a > > website, and then: > > (a) saving the web content directly under /public - which runs fast > > (b) having the content in a protected area, and then having rails > > serve it up via a controller - again that does (a) authentication via > > authlogic and then (b) serves via paperclip which stores files on > > disk, however there is a look to the database to find out where the > > file is > > > I'm not sure how to attach the images here, however the results > > basically show that on average, picking some of the images/css etc > > that the browser fetches: > > * a ~10kb javascript file: 10ms => 497ms > > * a 1kb image: 5ms => 29ms > > . > > . > > This is measured from a browser running on the same server as the ./ > > script/server -e production, mongrel server... > > > On Dec 16, 5:18 pm, Andrew Pace <[email protected]> wrote: > > > > I believe that paperclip actually stores a copy of the images in the > > > public directory by default. Once the html is rendered to the browser > > > the image requests should not go through the rails stack. > > > > Let us know what firebug says. Browser load times are dependent on > > > many factors, and often the rails stack is not the slowest piece of > > > the pie. Once you prove there is some evidence that rails is > > > significantly slowing you down, then it would be worth trying to > > > optimize it. But minimizing javascript, css, and images often has a > > > more profound effect on browser load times. Then caching pages, > > > actions, etc helps immensely too. > > > > Let us know the firebug or safari browser load time for each part of > > > the http requests. > > > > Andrew -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
