Various Topics on Ruby

.... ..in..

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

> > however im still wondering why my heavy php app, where
> > cl***es are not cached, no accelerator is used, etc is even a bit
> > faster than a super simple ruby example where cl***es 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.

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

..dre.. ..hwa..

Kirk Haines wrote:
> On Mon, 21 Jun 2004 06:03:15 +0900, Andreas Schwarz wrote
>
>> > however im still wondering why my heavy php app, where
>> > cl***es are not cached, no accelerator is used, etc is even a bit
>> > faster than a super simple ruby example where cl***es 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
"cl***es 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.

.... ..in..

> I don't think he was talking about parsing speed there; he wrote that
> "cl***es 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

..th.. ..ho..

Hello Kirk,


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

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

KH> Thanks,

KH> Kirk Haines




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

.... ..bil..

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,
>
>
> KH> Guh, you're right. To many parsing systems in my head. LOL.
> Thanks. I
> KH> think that I was thinking of Clearsilver.
>
> Did you try Clearsilver ?
> If yes, can you recommend it ?
>
> KH> Thanks,
>
> KH> Kirk Haines
>
>
>
>
> --
> Best regards, emailto: scholz at
> scriptolutions dot com
> Lothar Scholz http://www.ruby-ide.com
> CTO Scriptolutions Ruby, PHP, Python IDE 's
>
>
>