On 16 Oct 2007, at 13:45, Zed A. Shaw wrote: > No, as usual performance panic has set in and you're not looking at > the problem in the best way to solve it.
Sorry Zed, I have a great deal of respect for your work and your opinions on development. But you seem to have a blind spot here and I just don't understand why. This has nothing to do with optimisation. It has nothing to do with performance. It's got everything to do with resilience and reliability. Clearly what you say about waiting for remote services is true. Doing so is a Bad Thing and an application shouldn't do it. But you're missing the point. Your philosophy guarantees that your applications performance will be held hostage by the worst performing action within it. What if I screw up and accidentally roll out "bad" action. Should this mean that *every aspect* of my app now behaves terribly? Following your logic, it does. The whole point of a load balancer is that it should enable things to behave sensibly even if one of my backend servers is screwed up. But a mismatch between the expectations encoded within mod_proxy_balancer and Mongrel running Ruby on Rails means that this isn't the case. Similarly, if I write a quick and dirty reporting action which runs an SQL query which takes 10 seconds to complete, should that screw up my entire application? It seems unreasonable to me that I have to optimise an action like this (why should I care if a reporting action which is only used once a day takes 10 seconds to complete?). I *do* care if every time I run it, though, I cause all the 0.1 second actions to queue up behind it. -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: https://www.linkedin.com/in/paulbutcher MSN: [EMAIL PROTECTED] AIM: paulrabutcher Skype: paulrabutcher _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
