[Mongrel] Design flaw? - num_processors, accept/close
rob at robmela.com
Tue Oct 16 21:34:23 EDT 2007
The query should not take 10 seconds. People should not steal. Still,
they do, and I live with the workaround -- locking.
So, while the 10-second query is a problem, and worth solving for its
own sake, the mod_proxy_balancer solution prevents it from causing the
secondary, request queuing problem.
That might eliminate enough crisis meetings that someone actually has
time to fix the underlying problem without working through the week
end. Which in turn lessens the likelyhood of anyone choosing option A.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/f3478dbd/attachment.vcf
More information about the Mongrel-users