Rubys web performance

ruby-talk
1

hi!

i have to admit that im kinda disappointed by ruby because of its
poor web performance i've experienced so far.

i have a fairly complex application written in php. it does all kinds
of complex stuff, front controller, complex template system, interceptors,
etc. even without any kind of acceleration which does any kind of caching
for files, classes, etc, the app takes never longer than 0.2 seconds per
request.

when i have a simple app in rails now, which basically only takes about 100 rows
from one tables, puts it in objects and displays those in the view, the request
takes 0.2 seconds with mod_ruby (all classes cached!) and with cgi
0.7 seconds.

on both systems (php and ruby) i measured without the invocation overhead.
on the start of the script i set a variable to the current time and and the end
i displayed the difference of the current time to the variable.

so basically the overhead created by cgi having to start a new ruby interpreter
each time is ignored.

i know that rails is not really optimized for performance yet, especially since
its not even released. however it feels like 0.55 seconds out of the 0.7 are
spend with the compilation of the ruby classes, before i even execute any..

any ideas why? thanks a lot for feedback!

ciao!
florian

2

Hello Florian,

hi!

i have to admit that im kinda disappointed by ruby because of its
poor web performance i've experienced so far.

i have a fairly complex application written in php. it does all kinds
of complex stuff, front controller, complex template system,
interceptors,
etc. even without any kind of acceleration which does any kind of
caching
for files, classes, etc, the app takes never longer than 0.2 seconds per
request.

when i have a simple app in rails now, which basically only takes about
100 rows
from one tables, puts it in objects and displays those in the view, the
request
takes 0.2 seconds with mod_ruby (all classes cached!) and with cgi
0.7 seconds.

on both systems (php and ruby) i measured without the invocation
overhead.
on the start of the script i set a variable to the current time and and
the end
i displayed the difference of the current time to the variable.

so basically the overhead created by cgi having to start a new ruby
interpreter
each time is ignored.

i know that rails is not really optimized for performance yet,
especially since
its not even released. however it feels like 0.55 seconds out of the
0.7 are
spend with the compilation of the ruby classes, before i even execute
any..

I don't know rails but if you work with a non cgi architecture, like
FCGI, webrick, mod_ruby. Write an init page that requires all files
(not just the toplevel ones) that will be loaded.

I don't know if it is possible to change the GC behaviour because GC's
are done much to often in a normal environment, so if this has an
significant percentage, change the settings in "gc.c" and recompile
ruby.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

3

just one thing: How did youm measured time?
IIRC you should be using Process.times.utime but actually don't
remember why :confused:

···

il Mon, 21 Jun 2004 01:50:01 +0900, Florian Weber <csshsh@structbench.com> ha scritto::

4

I don't know rails but if you work with a non cgi architecture, like
FCGI, webrick, mod_ruby. Write an init page that requires all files
(not just the toplevel ones) that will be loaded.

that means that mod_ruby and fcgi actually dont cache all the
loaded classes? i thought exactly thats what it does. when i profile
my ruby test, the execution via mod_ruby takes just about as
long as the execution under cgi minus the time it takes to load
the classes.

so here it seems like really all the classes are cached..

however im still wondering why my heavy php app, where
classes are not cached, no accelerator is used, etc is even a bit
faster than a super simple ruby example where classes are cached..

5

Florian Weber wrote:

I don't know rails but if you work with a non cgi architecture, like
FCGI, webrick, mod_ruby. Write an init page that requires all files
(not just the toplevel ones) that will be loaded.

that means that mod_ruby and fcgi actually dont cache all the
loaded classes? i thought exactly thats what it does.

You are right.

however im still wondering why my heavy php app, where
classes are not cached, no accelerator is used, etc is even a bit
faster than a super simple ruby example where classes are cached..

I don't know rails, but all the ruby web frameworks I looked at were
extremely memory and CPU intensive. If you use the relational DB like it
is supposed to, without a generic OO mapping layer, and a simple
templating system like Kwartz, you will see that performance is similar
to PHP.

6

I don't know rails, but all the ruby web frameworks I looked at were
extremely memory and CPU intensive. If you use the relational DB like it
is supposed to, without a generic OO mapping layer, and a simple
templating system like Kwartz, you will see that performance is similar
to PHP.

well, even when i dont do any orm or database stuff at all its fairly
slow. in general it feels like the compilation of the classes and modules
is the bottleneck..

7

The disadvantage to running something as a CGI is that there is a parsing
step every time, and a lot of the Ruby libraries are written in Ruby, not C,
so that is a lot of Ruby lines to parse.

The advantage to something like Kwartz is that it is written in C, so it
fundamentally pretty fast.

However, if you run some framework that gives you persistence of code, you
eliminate the code parsing step, and even with heavy apps that are doing a
lot of database interaction and producing a lot of HTML, performance can be
pretty good under Ruby.

David is successfully running Basecamp under Rails, so his performance
benchmarks can't be too bad, and I am running a variety of sites and
applications under Iowa with very reasonable performance. Server hardware
and Ruby version are relevant when talking about speed. On an 800 Mhz PIII
devel box under Linux with Ruby 1.8.1 I range from a high of about .3
seconds/request for a heavy page with about 30k of HTML with data queried
from a database and formatted, cookies checked, and some other data
manipulations down to lows in the thousandths of a second for pages with
less than about 4k of HTML, with some minor dynamic content but no database
queries. Note that these are the times for the Ruby code itself to run and
don't include the overhead for the webserver.

Because of the amount of time that threads spend waiting on other resources,
even with the heavy .3 seconds/request pages, though, I can handle 15-20 of
those per second on this hardware while more typical pages end up
benchmarking around 30-35 per second and the really lightweight ones around
70/second. For comparison, the requests that deliver 30-35/second via FCGI
or mod_ruby, if I instead use CGI, drop to around 6-7/second. These per
second number are all for the complete transaction with the webserver and
the applications, not just the Ruby portion.

These performance numbers, for me, are well within the acceptable range, and
memory usage does not seem to be a problem, either.

Kirk Haines

···

On Mon, 21 Jun 2004 06:03:15 +0900, Andreas Schwarz wrote

> however im still wondering why my heavy php app, where
> classes are not cached, no accelerator is used, etc is even a bit
> faster than a super simple ruby example where classes are cached..

I don't know rails, but all the ruby web frameworks I looked at were
extremely memory and CPU intensive. If you use the relational DB
like it is supposed to, without a generic OO mapping layer, and a simple
templating system like Kwartz, you will see that performance is similar
to PHP.

8

Florian Weber wrote:

in general it feels like the compilation of the classes and modules
is the bottleneck..

Of course, but there is a solution: use fastcgi. Try PHP as CGI, it will
be as slow as a ruby CGI.

9

Kirk Haines wrote:

> however im still wondering why my heavy php app, where
> classes are not cached, no accelerator is used, etc is even a bit
> faster than a super simple ruby example where classes are cached..

I don't know rails, but all the ruby web frameworks I looked at were
extremely memory and CPU intensive. If you use the relational DB
like it is supposed to, without a generic OO mapping layer, and a simple
templating system like Kwartz, you will see that performance is similar
to PHP.

The disadvantage to running something as a CGI is that there is a parsing
step every time, and a lot of the Ruby libraries are written in Ruby, not C,
so that is a lot of Ruby lines to parse.

I don't think he was talking about parsing speed there; he wrote that
"classes are cached".

The advantage to something like Kwartz is that it is written in C, so it
fundamentally pretty fast.

No, it generates Ruby code.

Because of the amount of time that threads spend waiting on other resources,
even with the heavy .3 seconds/request pages, though, I can handle 15-20 of
those per second on this hardware while more typical pages end up
benchmarking around 30-35 per second and the really lightweight ones around
70/second.

Sounds not bad, maybe I should have a look at it.

···

On Mon, 21 Jun 2004 06:03:15 +0900, Andreas Schwarz wrote

10

not really. like i said, i didnt measure the overhead created by the fact
that cgi has to start up a interpreter each time. i just stop from the start
of the script to the end. directly within the script..

i just tried something:

#!/usr/local/bin/ruby

start = Time.now
require 'yaml'
require 'logger'
t = Time.now - start

print "Content-type: text/html\r\n\r\n"
print "%.3f sec.\n" % t.to_f

this alone takes already at least 0.13 seconds (via cgi)

when i run it just via the shell it takes 0.09 seconds, which i think
is already quite a lot... no?

ciao!
florian

···

On Jun 21, 2004, at 0:13 Uhr, Andreas Schwarz wrote:

Florian Weber wrote:

in general it feels like the compilation of the classes and modules
is the bottleneck..

Of course, but there is a solution: use fastcgi. Try PHP as CGI, it will
be as slow as a ruby CGI.

11

I don't think he was talking about parsing speed there; he wrote that
"classes are cached".

Maybe I misunderstood. My impression was that he was talking about the
startup time of a CGI being longer under Ruby than PHP, but that it's a bit
of an apples and oranges comparison since most of the Ruby libs are written
in Ruby and a lot of the PHP libs are .so's written in C.

I was just saying that if one eliminates that from the equation using some
sort of persistence for the Ruby code, then the comparison gets much better.

> The advantage to something like Kwartz is that it is written in C, so it
> fundamentally pretty fast.

No, it generates Ruby code.

Guh, you're right. To many parsing systems in my head. LOL. Thanks. I
think that I was thinking of Clearsilver.

Thanks,

Kirk Haines

12

Florian Weber wrote:

Florian Weber wrote:

in general it feels like the compilation of the classes and modules
is the bottleneck..

Of course, but there is a solution: use fastcgi. Try PHP as CGI, it
will
be as slow as a ruby CGI.

not really. like i said, i didnt measure the overhead created by the
fact
that cgi has to start up a interpreter each time. i just stop from the
start
of the script to the end. directly within the script..

i just tried something:

#!/usr/local/bin/ruby

start = Time.now
require 'yaml'
require 'logger'
t = Time.now - start

print "Content-type: text/html\r\n\r\n"
print "%.3f sec.\n" % t.to_f

this alone takes already at least 0.13 seconds (via cgi)

Where's the problem? You have to load the files only once, so it doesn't
matter how long it takes to parse them. CGI is no use for "real"
applications, use fastcgi, webrick or mod_ruby.

···

On Jun 21, 2004, at 0:13 Uhr, Andreas Schwarz wrote:

13

Florian Weber wrote:

i just tried something:

#!/usr/local/bin/ruby

start = Time.now
require 'yaml'
require 'logger'
t = Time.now - start

print "Content-type: text/html\r\n\r\n"
print "%.3f sec.\n" % t.to_f

this alone takes already at least 0.13 seconds (via cgi)

when i run it just via the shell it takes 0.09 seconds, which i think
is already quite a lot... no?

try php cgi with several php extensions pre-loaded in php.ini, it can take up to 0.30-0.40 second on my machine (the overhead is mainly in opening *.so files).

···

--
dave

14

Hello Kirk,

Guh, you're right. To many parsing systems in my head. LOL. Thanks. I
think that I was thinking of Clearsilver.

Did you try Clearsilver ?
If yes, can you recommend it ?

···

Thanks,

Kirk Haines

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

15

Where's the problem? You have to load the files only once, so it doesn't
matter how long it takes to parse them. CGI is no use for "real"
applications, use fastcgi, webrick or mod_ruby.

well, but i think thats exactly the point why ruby is really hard to use
for general web stuff..

there are barely any hosters who support fastcgi, webrick or mod_ruby.
especially since the last one is not usable for shared hosting. so you
have to rely on cgi..

and anyways, why does it take ruby so long to load the files and compile
it when the same would only take a fragment of it with php?

16

I'm using Clearsilver with ruby-fcgi module to implement a commercial web-site. It's very nice template engine indeed. So far I'm very pleasant with the performance.

Cheers,
Kent.

···

On Jun 21, 2004, at 1:35 PM, Lothar Scholz wrote:

Hello Kirk,

> Guh, you're right. To many parsing systems in my head. LOL. Thanks. I
> think that I was thinking of Clearsilver.

Did you try Clearsilver ?
If yes, can you recommend it ?

> Thanks,

> Kirk Haines

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

17

and anyways, why does it take ruby so long to load the files and compile
it when the same would only take a fragment of it with php?

In short, PHP is optimized for ease of computer parsing.

Ruby is optimized for human parsing.

18

Florian Weber wrote:

Where's the problem? You have to load the files only once, so it
doesn't
matter how long it takes to parse them. CGI is no use for "real"
applications, use fastcgi, webrick or mod_ruby.

well, but i think thats exactly the point why ruby is really hard to use
for general web stuff..

there are barely any hosters who support fastcgi, webrick or mod_ruby.
especially since the last one is not usable for shared hosting. so you
have to rely on cgi..

I agree, ruby support on shared servers is poor. This is one of the
reasons why I'm using a virtual server from www.vdserver.de.

and anyways, why does it take ruby so long to load the files and compile
it when the same would only take a fragment of it with php?

Did you really try PHP CGI with source files of comparable size (don't
forget that every file you require could itself require other files)?

I don't know exactly how the parsing mechanism in PHP and Ruby differs,
and I don't know if there is actually a difference in performance; but
I wouldn't be surprised if PHP was faster, because the language is
*much* simpler to parse than Ruby. However, I don't think it's really a
problem.

19

I just thought of this: does rails uses ERB or ERuby ?
The first one is basically a pure ruby version of the latter, maybe if
that is the one used you may seicth to the C one and get some better
performance..

···

il Mon, 21 Jun 2004 07:55:25 +0900, Florian Weber <csshsh@structbench.com> ha scritto::

and anyways, why does it take ruby so long to load the files and compile
it when the same would only take a fragment of it with php?

20

Florian Weber <csshsh@structbench.com> wrote in message news:

there are barely any hosters who support fastcgi, webrick or mod_ruby.
especially since the last one is not usable for shared hosting. so you
have to rely on cgi..

Try Kattare.com, they've told me they do mod_ruby hosting.

Cheers,

Patrick