hehe.. 'my application is really slow, but thats because the application
is optimized towards high usability' ; )
On Jun 21, 2004, at 1:00 Uhr, Aredridel wrote:
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.
its not really a issue with rails..
its a issue with the performance ruby reads and compiles files..
see my email before about how i tested it. there i only required to
files. no rails stuff going on..
On Jun 21, 2004, at 1:58 Uhr, gabriele renzi wrote:
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?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..
Andreas Schwarz wrote:
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.
my experience with php seems to confirm this. php compilation is so fast that it's okay to use PHP CGI for medium traffic and simple to medium application complexity.
*but*, if your application needs to compile 1000+ lines of php code on every request (e.g. you include/require several libraries, like PEAR modules), the overhead does start to show itself (0.5-1 seconds or more of delay).
php cgi apps seems faster since most libraries are written in C, while Perl's (and Ruby's) are written in pure Perl/Ruby code so they need to compile many lines of code per request. but this situation is changing everyday that PEAR is more and more used everyday...
--
dave
Just that they do so does not mean that shared mod_ruby hosting is now
working. in a shared hosting environment.
They simply leave there customers alone with the problems, only to add
a new item on there marketing feature list.
On 21 Jun 2004 05:08:14 -0700, patrick@hexane.org (Patrick May) wrote:
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.
patrick@hexane.org (Patrick May) writes:
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
How about using a host that does "virtual (private|dedicated)"
hosting via User Mode Linux or Virtuozzo?
I started up a $20 a month account recently with http://jvds.com .
For that, I have root on a "virtual" UML machine, so I was able to
install mod_ruby with no problems, since there is no one else sharing
my install with me. For that matter, I could just as well run webrick
or webrick-using software like Instiki. I could even run webrick on
port 80 if I wanted to.
I mention it because I looked at that kattare.com site, and it seems
to me that a UML setup is a much better deal. At kattare, the $20 a
month package includes 500MB disk space and 2Gigs/month
bandwidth. That jvds.com place I mentioned gives you 3 gigs disk
space and 20Gigs/month for that same price, *plus* you can install
and run whatever you want. You can even choose from among 7 or 8
different linux distros, or FreeBSD if you'd like.
Now, I know that it is very often the case that "you get what you pay
for" in web hosting, but this jvds.com place has nothing but good buzz
at http://webhostingtalk.com , from what I saw. Further, there are
several other places that offer a similar (or even slightly better)
deal for the same price, with that same "virtual root" setup. Among
them are http://www.linode.com (very nice-looking control panel that
lets you wipe and change your distro among other things),
http://www.rimuhosting.com , and http://www.powervps.com . Again, all
have good reputations on the aforementioned bulletin board and on the
net in general, from what I can tell, and any will let you run mod-ruby
and whatever else you might want. Finally, pretty much all of these
places have a 30-day money back guarantee, and several have no setup
fee.
It's true that you are only guaranteed 64 megs of memory with the $20
package I mentioned, but that's a *guarantee*, and, when the other
"virtual servers" on your physical server aren't using up their
memory, then any swap your machine is using is mapped right into the
machine's physical memory. Likewise, while you are only guaranteed a
small slice of the physical machine's cpus, you get as much as you can
use when other virtual servers aren't working them. I've compiled a
couple pretty big Haskell programs with the notoriously memory- and
cpu-hungry GHC, and both times the compilation flew right along.
Just thought I'd throw another option out there in case anybody was
looking and not aware of this one.
--
Florian Weber wrote:
its not really a issue with rails..
its a issue with the performance ruby reads and compiles files..
see my email before about how i tested it. there i only required to
files. no rails stuff going on..
note: php 4.3.6, ruby 1.8.1, both on Linux
<<<
* 0 line of code:
$ time ruby -v; # 0.023s
$ time php -v; # 0.037s (note: only mysql.so dynamic PHP extension is loaded; but several exts are builtin)
* 1 line of code:
$ echo '<? echo "Hello, world!\n" ?>' | time php -q; # 0.037s
$ time ruby -e'puts "Hello, world!"'; # 0.023s
* +- 1750 lines of PHP code:
$ time php /usr/share/pear/System.php; # 0.058s
$ wc System.php PEAR.php Console/Getopt.php
540 2002 17972 System.php
975 3290 30154 PEAR.php
251 1084 9536 Console/Getopt.php
1766 6376 57662 total
* +- 2600 lines of Ruby code:
$ time ruby cgi.rb; # 0.065s
$ wc cgi.rb English.rb delegate.rb
2318 9250 75713 cgi.rb
155 855 5732 English.rb
139 322 2942 delegate.rb
2612 10427 84387 total
>>>
Conclusion: Not disappointing for Ruby...
The problem is, for simple CGI web app, thousands of Ruby lines typically need to be parsed & compiled, while only several lines are needed for PHP (due to PHP extensions are in the form of compiled machine code).
Hope things will get better with Cardinal or Ruby2... Overhead of scripting languages compilation (esp. Perl & Ruby, since those doesn't fully support precompiled code) almost always force me to make persistent/long-running processes/daemons (which have problems of their own), or go to C (which I can't stand :-).
For example, for an SMTPD I have to ditch qpsmtpd (since the script runs via tcpserver, i.e. needs to be forked on every request) and make my own Perl daemon. The overhead would just really burden my machine.
--
dave
Can you show us your PHP file which you used for measuring?
The libraries you loaded are not pure C extensions! Have a look at the
number of lines:
library | source lines
--------|-------------
yaml | 4158
logger | 728
cgi | 2909
So I guess, compiling ~5000 lines in 0.09 seconds, is not that bad at
all. This gives a rate of 50.000 lines per second.
Now try the same in PHP, and measure again.
Regards,
Michael
On Mon, Jun 21, 2004 at 09:05:33AM +0900, Florian Weber wrote:
On Jun 21, 2004, at 1:58 Uhr, gabriele renzi wrote:
>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?
>>
>
>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..its not really a issue with rails..
its a issue with the performance ruby reads and compiles files..
see my email before about how i tested it. there i only required to
files. no rails stuff going on..
my experience with php seems to confirm this. php compilation is so fast
that it's okay to use PHP CGI for medium traffic and simple to medium
application complexity.
I'd go with this, and the statement that PHPs syntax is 'optimized'
for parsing. Actually it chokes on stuff like $obj->ary[$i]->value;
(alledgedly it's improving in PHP5, like many other things).
*but*, if your application needs to compile 1000+ lines of php code on
every request (e.g. you include/require several libraries, like PEAR
modules), the overhead does start to show itself (0.5-1 seconds or more
of delay).
True again. I often test things on an old 300Mhz box, to slow things
down to a speed where I can actaully gauge the speeds. Larger projects
like phpgroupware get extremely slow, which make you think twice
before throwing them on the big iron.
And don't forget that Ruby can be doing catchup when actually running
the code. I've seen Ruby code that was several factors faster than the
equvalent PHP code, doing a lot of throwing data around.
php cgi apps seems faster since most libraries are written in C, while
Perl's (and Ruby's) are written in pure Perl/Ruby code so they need to
compile many lines of code per request. but this situation is changing
everyday that PEAR is more and more used everyday...
And while we're talking about lines.. I had to fix the code in
SquirrelMail that encodes the headers when there's non-ASCII
characters in it. Thought that it would be easy as I'd done my own in
Ruby for another project and it was just 7 lines of code. Imagine my
surprise when I found out that it was 118 lines of PHP code. About 10
was 'extra' code for stuff related to SquirrelMail.
I couldn't resist, first I tried rewriting the function to exec
Ruby. Slow as hell, but only 19 lines. Then I ported my Ruby function
as well as I could and it ended up at 32 lines. So even if we subtract
the 10 lines, it's still the difference between 7 and 22 lines.
My own conclusion is that, while Ruby might be slow on the uptake
sometimes, it's not because it's inheriently slower.
On Mon, Jun 21, 2004 at 04:09:19PM +0900, David Garamond wrote:
--
Thomas
beast@system-tnt.dk
Just that they do so does not mean that shared mod_ruby hosting is now
working. in a shared hosting environment.They simply leave there customers alone with the problems, only to add
a new item on there marketing feature list.
Well, I haven't fiddle much with mod_ruby. But I have had the opposite impression of their service. Sorry to hear that things didn't go well. My experiences with them have always been positive.
Cheers,
Patrick
I have one of those too 
I use kattare.com because I have been satisfied with their overall service, I like many of their member's tools. And I use a virtual server for things that are more esoteric that I want to manage myself. For example, www.narf-lib.org runs at kattare, and svn.narf-lib.org runs at on a virtual server at johncompanies.
I haven't had the time to get mod_ruby together. I need to ensure narf plays well with it (as well as with fast cgi, and webrick)
Cheers,
Patrick
On Monday, June 21, 2004, at 11:33 PM, Jim Marshall wrote:
How about using a host that does "virtual (private|dedicated)"
hosting via User Mode Linux or Virtuozzo?
Thomas Fini Hansen wrote:
And while we're talking about lines.. I had to fix the code in
SquirrelMail that encodes the headers when there's non-ASCII
characters in it. Thought that it would be easy as I'd done my own in
Ruby for another project and it was just 7 lines of code. Imagine my
surprise when I found out that it was 118 lines of PHP code. About 10
was 'extra' code for stuff related to SquirrelMail.I couldn't resist, first I tried rewriting the function to exec
Ruby. Slow as hell, but only 19 lines. Then I ported my Ruby function
as well as I could and it ended up at 32 lines. So even if we subtract
the 10 lines, it's still the difference between 7 and 22 lines.
I know the feeling Sometimes I curse while coding in PHP. Though it does the job, PHP is really an ugly, half-baked, non-designed language. Even Perl looks beautiful when I'm stuck with PHP. Plus they break things (and change defaults!) between releases. IMO PHP is really an undependable tool for large projects.
--
dave