In considering ruby on rails for a commercial project I attempted to conduct a speed comparison with php. I created a postgresql database table with 5 fields and 40 records. I created a rails scaffold around this table. I recreated the list page in php and delibrately made it a little complex by creating and including database management, helper and layout files. I got fastcgi running after some help from the IRC channel. There are 15 processes running the dispatcher in production mode. The processes seem to be working correctly as they jump up top when the benchmark is run. To test I used ApacheBench> ab2 -n 100 -c 10 <URL> I was mainly looking for requests per second. WEBrick server: 3.45 [#/sec] (mean) Apache with fastcgi: 3.82 [#/sec] (mean) Apache with php: 55.36 [#/sec] (mean) Other people reported getting 20 pages/sec for the same test but that was without database content. Is this the level of performance that is expected? Or is my configuration horribly wrong somewhere? Boring details: Server Version: Apache/2.0.53 (Debian GNU/Linux) mod_fastcgi/2.4.2 mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-9 mod_perl/1.999.20 Perl/v5.8.4 ruby 1.8.2 (2005-04-09) [i386-linux] PostgreSQL 7.4.7 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc (GCC) 3.3.5 (Debian 1:3.3.5-5) Rails 0.11.1-2 ~David Tulloh
David Tulloh wrote:> > To test I used ApacheBench> ab2 -n 100 -c 10 <URL> > I was mainly looking for requests per second. > > WEBrick server: 3.45 [#/sec] (mean) > Apache with fastcgi: 3.82 [#/sec] (mean) > Apache with php: 55.36 [#/sec] (mean) > > > Other people reported getting 20 pages/sec for the same test but that > was without database content. Is this the level of performance that > is expected? Or is my configuration horribly wrong somewhere? > > > Boring details: > Server Version: Apache/2.0.53 (Debian GNU/Linux) mod_fastcgi/2.4.2 > mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-9 mod_perl/1.999.20 Perl/v5.8.4 > ruby 1.8.2 (2005-04-09) [i386-linux] > PostgreSQL 7.4.7 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc > (GCC) 3.3.5 (Debian 1:3.3.5-5) > Rails 0.11.1-2Same here. I tested Rails with Lighttpd both on production server (dual AMD) and on my linux box and was unable to score more than 10 reqs/s with pretty simple actions. However Bougyman reported far better results, but I can''t recall his benchmark configuration. I think you can''t compare a MVC framework with a small library written in PHP. It will always give you better results with "clean" PHP because there''s nothing to parse. You could compare Rails with for example PHP Mojavi + Propel which would give you functionality similar to Rails. Also I think with "clean" PHP the more complex your application becomes the slower it gets. Which is not the case with Rails applications. You can always set up a couple of spare servers and balance the load if it gets busy. -- Best Karol Hosiawa
On 4/26/05, David Tulloh <david.tulloh-FCV4sgi5zeUQrrorzV6ljw@public.gmane.org> wrote:> In considering ruby on rails for a commercial project I attempted to > conduct a speed comparison with php. > > I created a postgresql database table with 5 fields and 40 records. > > I created a rails scaffold around this table. > > I recreated the list page in php and delibrately made it a little > complex by creating and including database management, helper and layout > files. > > I got fastcgi running after some help from the IRC channel. There are > 15 processes running the dispatcher in production mode. The processes > seem to be working correctly as they jump up top when the benchmark is run. > > To test I used ApacheBench> ab2 -n 100 -c 10 <URL> > I was mainly looking for requests per second. > > WEBrick server: 3.45 [#/sec] (mean) > Apache with fastcgi: 3.82 [#/sec] (mean) > Apache with php: 55.36 [#/sec] (mean) > > Other people reported getting 20 pages/sec for the same test but that > was without database content. Is this the level of performance that is > expected? Or is my configuration horribly wrong somewhere?Sounds like something''s horribly wrong. Things to check: You have the fcgi gem installed, otherwise it will fall back to the ruby version rather than the fast native version. How many fastcgi processes do you have? Does increasing it help?> Boring details: > Server Version: Apache/2.0.53 (Debian GNU/Linux) mod_fastcgi/2.4.2 > mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-9 mod_perl/1.999.20 Perl/v5.8.4 > ruby 1.8.2 (2005-04-09) [i386-linux] > PostgreSQL 7.4.7 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc > (GCC) 3.3.5 (Debian 1:3.3.5-5) > Rails 0.11.1-2 > > > ~David Tulloh > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
I did some futher investigation and tried lighttp. I tracked the biggest speed loss to the use of views. Using lighttp without any database interactions: Controller based hello world: 71.83 [#/sec] (mean) View file based hello world: 11.29 [#/sec] (mean) Including ActionView::Helpers::TagHelper and ActionView::Helpers::UrlHelper to create a controller based output with a link_to tag: 11.27 [#/sec] (mean) View file with link_to tag: 10.23 [#/sec] (mean) From this I think it''s clear that the ActionView helpers are adding a considerable amount of overhead and slowing down rails far more than an initial impression suggests that they should. ~David David Tulloh wrote:> In considering ruby on rails for a commercial project I attempted to > conduct a speed comparison with php. > > I created a postgresql database table with 5 fields and 40 records. > > I created a rails scaffold around this table. > > I recreated the list page in php and delibrately made it a little > complex by creating and including database management, helper and > layout files. > > I got fastcgi running after some help from the IRC channel. There are > 15 processes running the dispatcher in production mode. The processes > seem to be working correctly as they jump up top when the benchmark is > run. > > To test I used ApacheBench> ab2 -n 100 -c 10 <URL> > I was mainly looking for requests per second. > > WEBrick server: 3.45 [#/sec] (mean) > Apache with fastcgi: 3.82 [#/sec] (mean) > Apache with php: 55.36 [#/sec] (mean) > > > Other people reported getting 20 pages/sec for the same test but that > was without database content. Is this the level of performance that > is expected? Or is my configuration horribly wrong somewhere? > > > Boring details: > Server Version: Apache/2.0.53 (Debian GNU/Linux) mod_fastcgi/2.4.2 > mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-9 mod_perl/1.999.20 Perl/v5.8.4 > ruby 1.8.2 (2005-04-09) [i386-linux] > PostgreSQL 7.4.7 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc > (GCC) 3.3.5 (Debian 1:3.3.5-5) > Rails 0.11.1-2 > > > > ~David Tulloh > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
David Tulloh wrote:> I did some futher investigation and tried lighttp. > I tracked the biggest speed loss to the use of views. > > Using lighttp without any database interactions: > Controller based hello world: 71.83 [#/sec] (mean) > View file based hello world: 11.29 [#/sec] (mean) > Including ActionView::Helpers::TagHelper and > ActionView::Helpers::UrlHelper to create a controller based output with > a link_to tag: 11.27 [#/sec] (mean) > View file with link_to tag: 10.23 [#/sec] (mean) > > From this I think it''s clear that the ActionView helpers are adding a > considerable amount of overhead and slowing down rails far more than an > initial impression suggests that they should.Routing is slow -- both recognizing a route from a URL and generating URLs from a route. In my profiling they are a consistent bottleneck. (''Routing'' is a pared-down pure-Ruby mod_rewrite-alike that can map URLs to controller/action/params and back. It was added to Rails to make pretty URLs more configurable and to divorce us from the mod_rewrite requirement.) We knew this convenience came at a cost. We need a better routing algorithm. For starters, a pre-compilation step could sacrifice some startup time (death to CGI) in favor of quicker route-finding. Performance enhancement is the last major item before 1.0 release. Stefan has done some great detective work in http://dev.rubyonrails.org/ticket/912. Start your profilers; let''s find those hotspots! jeremy
Michael Koziarski wrote:>On 4/26/05, David Tulloh <david.tulloh-FCV4sgi5zeUQrrorzV6ljw@public.gmane.org> wrote: > > >>In considering ruby on rails for a commercial project I attempted to >>conduct a speed comparison with php. >> >>I created a postgresql database table with 5 fields and 40 records. >> >>I created a rails scaffold around this table. >> >>I recreated the list page in php and delibrately made it a little >>complex by creating and including database management, helper and layout >>files. >> >>I got fastcgi running after some help from the IRC channel. There are >>15 processes running the dispatcher in production mode. The processes >>seem to be working correctly as they jump up top when the benchmark is run. >> >>To test I used ApacheBench> ab2 -n 100 -c 10 <URL> >>I was mainly looking for requests per second. >> >>WEBrick server: 3.45 [#/sec] (mean) >>Apache with fastcgi: 3.82 [#/sec] (mean) >>Apache with php: 55.36 [#/sec] (mean) >> >>Other people reported getting 20 pages/sec for the same test but that >>was without database content. Is this the level of performance that is >>expected? Or is my configuration horribly wrong somewhere? >> >> > >Sounds like something''s horribly wrong. > >Things to check: > >You have the fcgi gem installed, otherwise it will fall back to the >ruby version rather than the fast native version. > >How many fastcgi processes do you have? Does increasing it help? > > >I''m using debian package management, libfcgi-ruby1.8 (FastCGI library for Ruby) is installed. I have 15 fastcgi processes, I''m only running 10 apache processes so that should be plenty. Cutting back to two processes actually speeds things up very slightly.>>Boring details: >>Server Version: Apache/2.0.53 (Debian GNU/Linux) mod_fastcgi/2.4.2 >>mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-9 mod_perl/1.999.20 Perl/v5.8.4 >>ruby 1.8.2 (2005-04-09) [i386-linux] >>PostgreSQL 7.4.7 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc >>(GCC) 3.3.5 (Debian 1:3.3.5-5) >>Rails 0.11.1-2 >> >> >>~David Tulloh >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> > > > >
Hi Jeremy, you wrote:>Routing is slow -- both recognizing a route from a URL and generating >URLs from a route. In my profiling they are a consistent bottleneck. > > >I can fully confirm this.>(''Routing'' is a pared-down pure-Ruby mod_rewrite-alike that can map URLs >to controller/action/params and back. It was added to Rails to make >pretty URLs more configurable and to divorce us from the mod_rewrite >requirement.) > > >We knew this convenience came at a cost. We need a better routing >algorithm. For starters, a pre-compilation step could sacrifice some >startup time (death to CGI) in favor of quicker route-finding. >Well, the simplest solution is to make it possible to do routing with mod_rewrite again. mod_rewrite is very powerful, it is fast, I know how to use it and I don''t have the need for doing it in Rails. Can we make it optional for 1.0? That said, I''ve added a simple routing cache yesterday, which solves the problem of fast recognizing nicely, trading memory for speed. Generating urls is still slow, though. But I''m not using link_to and url_for anymore. -- stefan PS: Can you tell me which profiler you''re using?
David Tulloh wrote:> To test I used ApacheBench> ab2 -n 100 -c 10 <URL> > I was mainly looking for requests per second. > > WEBrick server: 3.45 [#/sec] (mean) > Apache with fastcgi: 3.82 [#/sec] (mean) > Apache with php: 55.36 [#/sec] (mean) > > > Other people reported getting 20 pages/sec for the same test but that > was without database content. Is this the level of performance that > is expected? Or is my configuration horribly wrong somewhere? >Your test creates a new session for each request, which is rather expensive. You need to send a _session_id cookie along with the url, like so: $ get -e URL | grep _session_id Set-Cookie: _session_id=f314e412ef66d84d0d6bfc6848931e1a; path=/ or $wget -s -O - URL | grep _session_id Set-Cookie: _session_id=f314e412ef66d84d0d6bfc6848931e1a; path=/ ab -n 100 -c 10 -C ''_session_id=f314e412ef66d84d0d6bfc6848931e1a'' URL This should give a much better result. Can you post the numbers obtained with this setup? With my optimized version of Rails 0.12.1, Suse92 x64, and an Athlon64 3000+, I get a minimum of 110 requests per second. Details attached. -- stefan _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Stefan Kaes wrote:> Hi Jeremy, you wrote: > >> Routing is slow -- both recognizing a route from a URL and generating >> URLs from a route. In my profiling they are a consistent bottleneck. >> > I can fully confirm this. > >> (''Routing'' is a pared-down pure-Ruby mod_rewrite-alike that can map URLs >> to controller/action/params and back. It was added to Rails to make >> pretty URLs more configurable and to divorce us from the mod_rewrite >> requirement.) >> >> We knew this convenience came at a cost. We need a better routing >> algorithm. For starters, a pre-compilation step could sacrifice some >> startup time (death to CGI) in favor of quicker route-finding. >> > Well, the simplest solution is to make it possible to do routing with > mod_rewrite again. mod_rewrite is very powerful, it is fast, I know how > to use it and I don''t have the need for doing it in Rails. Can we make > it optional for 1.0?Agreed; native rewriting is excellent. However, for new applications and new Railers, Routes makes Rails FAR easier to get up and running. It also uses simpler, more concise rewrite rules than any mod_rewrite I''ve seen, and can rewrite the other direction (from a set of params to a URL) also, something no mod_rewrite can do. I think the best of both worlds would be a Routes "compiler" that creates an optimized set Apache or lighttpd rewrite rules for you.> That said, I''ve added a simple routing cache yesterday, which solves the > problem of fast recognizing nicely, trading memory for speed.Excellent! May I try your patch?> Generating > urls is still slow, though. But I''m not using link_to and url_for anymore.This is a route (ha ha) I''ve considered. Not dumping url_for, but overriding it to case out common params and return a URL immediately, deferring to Routes'' url_for if no immediate match is found. Compiling an optimized url_for method would be a perfect counterpart to a mod_rewrite rule compiler!> PS: Can you tell me which profiler you''re using?I''m using Shugo Maeda''s ruby-prof extension with an around_filter to profile each request and append the results to the response body. It''s not useful for fine-grained analysis since the profiler doesn''t keep a call tree, but it is fast, cross-platform way to uncover hotspots. Here''s the request profiler: http://dev.rubyonrails.com/file/tools/conductor/lib/request_profiler.rb Drop it in your lib/ directory and enable it in ApplicationController: require_dependency ''request_profiler'' class ApplicationController < ActionController::Base profile_requests end And here''s a patch for ./script/console --profile and ./script/profiler: http://dev.rubyonrails.com/ticket/1154 These are command-line scripts useful for ferreting out a bottleneck you''ve identified with the request profiler. They support both the stdlib profiler (slow, based on trace func) and the fast ruby-prof extension. Unfortunately, I don''t have a Windows machine to try http://www.softwareverify.com/rubyPerformanceValidator What is your experience with this tool? Best, jeremy
Jeremy Kemper wrote:>Agreed; native rewriting is excellent. > >However, for new applications and new Railers, Routes makes Rails FAR >easier to get up and running. It also uses simpler, more concise >rewrite rules than any mod_rewrite I''ve seen, and can rewrite the other >direction (from a set of params to a URL) also, something no mod_rewrite >can do. > >Yes, the backwards rewriting is neat, but also very expensive. And I don''t really need it. So having Rails routing as an option is what I want. It should not be too hard to do. It all really depends on the scope of your app. If you have a high traffic site, you will want to squeeze out the last bit of performance you can get. Same if your hardware is not top notch. Or if you share your machine with others.>I think the best of both worlds would be a Routes "compiler" that >creates an optimized set Apache or lighttpd rewrite rules for you. > > >This is a nice idea. But maybe the effort needed to implement this could be better spent on implementing other functionality. If you don''t have a high traffic site, Rails routing is good enough. If you do, then you should be able to write the native rules. And there are some things that are not easily done with rails routing (or I don''t know how to). E.g., in my set of rewrite rules I switch protocol from http to https and vice versa, depending on controller and action. I can''t see how to do it without native rules, unless you want to clutter your controller code with redirects. And that would be far less efficient.>>That said, I''ve added a simple routing cache yesterday, which solves the >>problem of fast recognizing nicely, trading memory for speed. >> >> > >Excellent! May I try your patch? > >Of course you can. File attached. I will also update my jumbo patch at http://dev.rubyonrails.org/ticket/912 in a while with more stuff and descriptions.>Unfortunately, I don''t have a Windows machine to try > http://www.softwareverify.com/rubyPerformanceValidator >What is your experience with this tool? > >My experience is very good. I''m beta testing it and a large part of my performance patches have been based on observations made with the tool. And these guys are really helpful with fast response time for both bugs and enhancements. Regards, Stefan _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails