I’m running on a brand new MacBook Pro with a relatively clean working
set.
using Mongrel in production mode on port 3000. The home page does not
hit
the database and I’m getting:
Processing HomeController#index (for 127.0.0.1 at 2006-06-29 14:59:02)
[GET]
Session ID: e11f7df52bffff304ca7c88e672ef71a
Parameters: {“action”=>“index”, “controller”=>“home”}
Rendering within layouts/application
Rendering home/index
Completed in 0.01957 (51 reqs/sec) | Rendering: 0.00228 (11%) | DB:
0.00000
(0%) | 200 OK [http://localhost/]
A slightly more complicated page with a sqlite in-memory db:
Processing QuickQuoteController#index (for 127.0.0.1 at 2006-06-29
14:59:05)
[GET]
Session ID: e11f7df52bffff304ca7c88e672ef71a
Parameters: {“action”=>“index”, “controller”=>“quick_quote”}
Rendering within layouts/application
Rendering quick_quote/index
Completed in 0.05039 (19 reqs/sec) | Rendering: 0.03294 (65%) | DB:
0.00000
(0%) | 200 OK [http://localhost/quick_quote]
A page that actually hits the database:
Processing FaqController#index (for 127.0.0.1 at 2006-06-29 14:59:17)
[GET]
Session ID: e11f7df52bffff304ca7c88e672ef71a
Parameters: {“action”=>“index”, “controller”=>“faq”}
Rendering layoutfalseactionlist within layouts/application
Rendering faq/list
Completed in 0.07666 (13 reqs/sec) | Rendering: 0.04842 (63%) | DB:
0.00934
(12%) | 200 OK [http://localhost/faq]
This is a single instance of Mongrel, so of course a cluster would
improve
things, but is this kind of performance expected or does it seem a bit
pokey?
A page that actually hits the database:
Completed in 0.07666 (13 reqs/sec) | Rendering: 0.04842 (63%) | DB: 0.00934
I wouldn’t exactly say that 13 hits per second is pokey… I don’t
have a MacBook Pro (though I’d love one)…but try it on a few
different platforms and see. My guess is that it will speed up on a
production server. :: shrug ::
Those stats in the log are approximate at best and totally wrong on
many occasions. You should test with httperf or at least ab to get a
realistic req/sec reading.
Completed in 0.07666 (13 reqs/sec) | Rendering: 0.04842 (63%) | DB:
0.00934
(12%) | 200 OK [http://localhost/faq]
hope you are aware of how rails loads, on most platform/runners first
hit will be slower as it has a lot of overhead.
other pointers
enabling caching can dramatically improve performance
DB optimisation is always possible(indexing, optimizing queries,
eager loading in case of joins)
for upto 100,000 hits per day, your existing rails app will run smooth,
without too much load or delay
dont waste your development time in pre-optimisation now, there are
other scalability techniques which you would have to learn to suit your
specific application.
so please dont worry now, get your app completed and launched. you will
always get time post launch to refactor and optimse the above mentioned.
my site runs comfortably on a shared server(yes shared server, no VPS,
no dedicated server or clustered load balanced server) without any
optimisations
Thanks for the pointer to httperf, ezra. I’m showing much more
interesting
data. This site is in a late stage of development, so I think it’s the
right
time to be thinking about caching and moving things into load-time code.
I’m running a single Mongrel for dev, but the results shown by httperf
are
reassuring. I got a little scared watching one of my PHP sites under
Apache
2 kick out pages like lightning and then see somewhat slower performance
of
my keen new Rails app.
It should scale up fine on lighty with a few fcgi’s or a Mongrel
cluster.
Completed in 0.07666 (13 reqs/sec) | Rendering: 0.04842 (63%) | DB:
0.00934
(12%) | 200 OK [http://localhost/faq]
enabling caching can dramatically improve performance
DB optimisation is always possible(indexing, optimizing queries,
eager loading in case of joins)
i was going to add a #3, but its actualy a good thing that Mac OS is so
slow. you should have about 3 or 4 people test it at once while its
still on OSX, since it will be harder to find the optimizable areas by
‘feel’ if youre testing as a single user on an AMD X2 running 64bit
linux…
youll get a big speed boost especially for >2 concurrent users once you
put it on a deployment kernel (eg linux or freebsd) with a much lower
IPC/syscall/multithread/process overhead, and if santa is nice, another
boost in the form of a fast Ruby VM maybe on Christmas 2007. so dont
worry about the stats in the dev log, unless its causing you other
problems besides worry itself…
Those stats in the log are approximate at best and totally wrong on
many occasions. You should test with httperf or at least ab to get a
realistic req/sec reading.
I got a little scared watching one of my PHP sites under
Apache
2 kick out pages like lightning and then see somewhat slower performance
of
my keen new Rails app.
Hi Steve,
I have seen PHP crawling for some medium-large applications using large
frameworks like, Prado with propel, Yellowduck, until you do content
caching and enable some optimiser like zend optimiser or some
webserver/php based caching mechanism.
It took me around 5 years to do big things on PHP, templating, caching,
deplyments,scalability issues, etc, but on day 4 on rails I was learning
to implement all those on rails.
I know I have still a long way to go, but rails is re-assuring, stress
free productivity
Both seem to inject their own set of inaccuracies. I can¹t speak the the
Rails log estimates, but httperf has to take into account network
traffic
and common usage scenarios (i.e., how many connection, etc.).
What settings are you using for httperf to get a useful number and are
you
using req/sec as the ³gold standard² of performance?
Thx
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
