Andrew Pace wrote: However, this seems like > more of a hassle to update if the design requirements change. >
Look at it this way: Suppose you have the "next big thing" and everyone is flocking to your site to see and read about it. Do you want your response cycle dependent on a hunk of code checking whether thumbnails of a set of product images exist for every request that hits a URL (especially when your intent is to have those thumbnails available for serving)? For 10 users? For 10,000 users? For X users? Or do you want your application to generate those thumbnails once, when the images are uploaded? Don't defer work that must be done, that's not simplicity. Get it out of the way as soon as possible. Anecdote: At work a year or so ago, I was asked to improve performance for a web process. In a nutshell, I a) stopped 'dynamically retrieving' certain data (that wasn't truly dynamic) and formatting the results for the web on the fly, but formatted and stored it at schedule creation. In one test case, we went from 7000 queries to under 300, and the response time went from 28 seconds to 3. Main lesson: make the real work happen outside your request-response cycle -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
