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.
begin:vcard
fn:Robert Mela
n:Mela;Robert
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users
