On Tue, 16 Oct 2007 14:01:16 +0100 Paul Butcher <[EMAIL PROTECTED]> wrote:
> 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. That's because you're reading my recommendation as "performance tuning vs. design to avoid". If you've read any of my work you'll understand I *never* advocate a boolean argument. Those are for computers. In my argument I'm saying that his problem can never be solved because he doesn't have control of the performance at all, and why should the user's HTTP REQUEST be held up for this? You get the distinction? Your HTTP request processing doesn't have to be coupled to your backend request processing. Break them apart and then you can ensure the user gets rapid feedback, you have fewer bottlnecks, you can push the processing out, and you can measure orthogonal pieces rather than one giant messy process. > This has nothing to do with optimisation. It has nothing to do with > performance. It's got everything to do with resilience and reliability. No, resilience and reliability are quantifiable metrics. Mean Time Between Failure to be exact. "Performance" is a subjective thing that's based on human perception. Yes, I know you can go get yourself a little graph of requests per second, but that won't tell you if the users think it is fast. If you can't make the computer fast, trick the people to think it's fast. <snip> > Your philosophy guarantees that your applications performance will be > held hostage by the worst performing action within it. Again, no, I'm not saying don't try to make it fast. What I'm saying is first thing programmers do is they run off with faulty statistics to "tune" their system, completely ignoring the fact that many times a simple redesign (or complex improvement) can just eliminate the problem entirely. See my most recent reply to Brian for many examples. > 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. Well I didn't do a logic proof so you're inventing logic where there is none. My "logic" would be this: The fastest way to do something is to just not do it. Right? That basically gives you an infinite number of requests per second. :-) But ultimately, I've been doing this a long time, and the one thing I've realized is, no matter how fast you make something, there's always a bigger dumbass available to make it slow. Hell man, computers have blasted in capability and speed over the years, and still I have to wait for my damn email to render in the fastest email client I could find. No amount of making things fast will protect you against stupidity. > 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. I'd reword this: "I have SQL queries that take 10 seconds to complete and I'm stuck using Mongrel because nobody else has stepped up to fix the dumbass crap in Ruby's GC, IO, and Threads and even the JRuby guys can't solve their 'mystery' performance problem with Rails..." Option A: "... I'm totally screwed and should toss myself off a building because I keep banging my head on this thing and it doesn't go faster." Option B: "... I'm rich and will just put 1000 mongrels in the mix and solve the problem." Option C: "... I know queueing theory and can work up a queuing model that will help me figure out the minimum number of request processors to handle the queue at a 10 req/sec rate." Option D: "... I can analyze the performance of all my stuff and tune it as fast as possible, then try C and B." Option E: "... Well, let's try some stuff on the front end and see if we can just trick people into thinking how this goes so that there isn't a problem anymore." Any of them will work, but with Rails option E, D, C, and B work best (in that order). Please don't do A, it's not that big a deal. Epliogue (not just for Paul): A lot of people complain that rails should be thread safe. Well, Rails Core folks including DHH also complain that it should be thread safe. Under JRuby you can spin up a ton of real threads with entire Rails apps in each one, but that's suboptimal for memory usage (like Java cares). If all of you think that Rails shouldn't have a giant lock, then I have only one suggestion: Get off your damn ass and make it happen. David just made a big effort to make the process for submitting patches much more open and he's looking for people to solve this problem. I dare say he's admitted he was wrong about the locking issue and is ultra-keen (I won't say desperate) for someone to solve it. Nothing is in your way, and the reward will be the glory of making things fast. Worked for me, and I can say it's totally worth it. As a sweetener, I'll throw this out: I bet you can NOT make Rails threadsafe. The first person or group of people to finally get rid of the thread locking around Rails requests in Mongrel and make Rails performance match that of Merb or Nitro on average will get a real highschool style trophy from me. The trophy will have a bust of a dog on it and will be enscribed: "Official Mongrel Rails Threadify Ninja Destroyer 1st Place: Zed and DHH were wrong!". The runner-up will get the first set of MUDCRAP-CE certificates, and I'll hand them out at the next Rails or Ruby conference in person. Alright, I've ponied up my end of the bargain. Who's going to take me on? -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
