On Jan 29, 2008 10:02 AM, John Joseph B.
[email protected] wrote:
This is an interesting discussion. The conclusions are a bit confusing
to me. John-- you say that your sites get a few thousand hits a day.
With only one mongrel, can’t the system only serve one request at a
time? It seems like, independent of system performance, just the fact
that the requests have to be done sequentially would have a big hit on
the performance on the site.
Is this not the case, that with one mongrel, only one request can be
served at a time?
It’s not quite as cut and dried an issue as that because while there
are a variety of threaded, nonthreaded, and event based combinations
among different frameworks and app container choices, Ruby 1.8’s
threading is via green threads anyway
However, for sake of argument, let’s just say that the answer is
“yes”. Only one request can be served at a time.
It becomes a question of how long it takes for an application to serve
a request. And for, I think, the vast majority of the typical
business oriented dynamic web site, if properly built, the answer
should be “not long at all.”
My absolute slowest sites, on my slowest server, still have a capacity
of 6-10 requests/second, and I wouldn’t tolerate that performance if I
were building those sites today instead of 5 years ago.
6 requests per second means that if it is pushed to it’s limit for
even one hour, it has served more than 21000 requests in that hour.
Even if it were a lethargically slow 1 request/second, that’s a
capacity of 3600 requests in an hour, and that capacity easily meets
the needs of the common business site.
The fastest sites on this same slowest server that are 100%
dynamically rendered, and which perform database transactions with
every request can turn about 130 r/s, peak. This is a several year
old 32 bit Athlon based Linux box proxying through Apache.
And just to prove a point, here are a couple timings from a couple
different sites on one of my faster servers, which is a newer 3.0 Ghz
Xeon based Linux box proxying through Swiftiply:
First, a “normal” business site, with all content and navigation
dynamically rendered (it is managed by a CMS and stored in a database
table):
Requests per second: 436.87 [#/sec] (mean)
Second, a “fast” site. All of the requests are still dynamic template
renderings, but it has been tuned to be fast:
Requests per second: 1167.21 [#/sec] (mean)
Even if one’s app is so slow that it can only render a handful of
pages per second, there is still a vast, expansive forest of sites and
apps where that performance, on a single process, is more than
adequate for even the heaviest traffic that the site will get. That
performance will still serve thousands to tens of thousands of people
per day.
Kirk H.
