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? Thanks -- View this message in context: http://www.nabble.com/Is-This-a-Performance-Concern--tf1870138.html#a5111275 Sent from the RubyOnRails Users forum at Nabble.com.
On 6/29/06, s.ross <cwdinfo@gmail.com> wrote:> A page that actually hits the database: > Completed in 0.07666 (13 reqs/sec) | Rendering: 0.04842 (63%) | DB: 0.00934I 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 :: -Curtis
On Jun 29, 2006, at 3:25 PM, Curtis wrote:> On 6/29/06, s.ross <cwdinfo@gmail.com> wrote: >> 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 :: > > > -Curtis > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsThose 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. -Ezra
> 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 1) enabling caching can dramatically improve performance 2) 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 regards A.Senthil Nayagam http://senthilnayagam.com -- Posted via http://www.ruby-forum.com/.
> > Completed in 0.07666 (13 reqs/sec) | Rendering: 0.04842 (63%) | DB: > > 0.00934 > > (12%) | 200 OK [http://localhost/faq]> 1) enabling caching can dramatically improve performance > 2) 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..
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. -- View this message in context: http://www.nabble.com/Is-This-a-Performance-Concern--tf1870138.html#a5113992 Sent from the RubyOnRails Users forum at Nabble.com.
Steve Ross wrote:> 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 regards A.Senthil Nayagam http://senthilnayagam.com -- Posted via http://www.ruby-forum.com/.
Ezra Zygmuntowicz wrote:> > 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.Absolutely true. Couldn''t have stated that better :-) -- Rails performance tuning: http://railsexpress.de/blog Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml
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 On 7/14/06 4:31 AM, "Stefan Kaes" <skaes@gmx.net> wrote:> Ezra Zygmuntowicz wrote: >> > >> > 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. > > Absolutely true. > > Couldn''t have stated that better :-) >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060714/8e6612da/attachment.html