Ruby VS PHP

[Eric Hodel]

Actually, part of my reason for learning Ruby is because I have a
project coming up that I will be designing, and i'm not sure if PHP
is up to the task. I have been looking at ColdFusion, or more
likely, the J2EE framework.

I prefer the philosophy and community of Ruby, but am still not
sure at which point it is required. When would you say, ok, here
is a job for Ruby?

I like Ruby because I find it easier to maintain than PHP or Perl.

A basic site requiring a MySQL backend for a few queries here and
there is obviously a job for PHP, so at what stage is Ruby required?

I think 43 things is the largest RoR site by traffic, and this week
we did 3,109,986 requests, averaging 444284 requests per day.
(Requests through Rails. Hits for the site has been hovering just
under the 2 million mark per day, the remaining 3/4 being images and
so-forth.)

This is with 2 dual-xeon web servers and a dual-xeon DB server. We
have very complex pages, and we're just past half our processor
capacity on the web servers (I think, its hard to judge). The DB
server has lots of room for growth.

To get back to the maintainable part...

We launched the site in 4 months with 5 developers, 4 of them had
zero Ruby experience. About 6 months later we launched a new site.
We're about to start working on a 3rd with an even shorter cycle. We
didn't work on the new site for all of those 6 months, maybe 2 of
them, and we borrowed (and overlayed) much of the code for the new
site from the old.

We didn't plan to extend the original 43 things into 43 places, but
Ruby let it happen without much difficulty.

 

[Jochen Schalanda]

The main PHP problem is just that too many people thought (and even
still think) it scales well with increased application size.

Actually PHP does scale well, see flickr.com as an example. There is a
nice presentation [1] which deals with the architecture of flickr and
the technical problems which occured when they got more popular.


[1]: http://www.niallkennedy.com/blog/archives/2004/10/flickr_architec.html


Best regards,
Jochen

 

[Michael Campbell]

I was chatting with a PHP dev friend tonight, he is a
PHP die hard who thinks it can do anything.

I assume PHP is turing-complete, no? =3D)
--=20
I tend to view "truly flexible" by another term: "Make everything
equally hard". -- DHH

 

[Ara.T.Howard]

I assume PHP is turing-complete, no? =)

if it never frees memory that seems a bit like reading a finite length tape
doesn't it? so maybe no. ;-)

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================

 

[Matthew Berg]

if it never frees memory that seems a bit like reading a finite length tape
doesn't it? so maybe no. ;-)

According to the PHP manual:

Resource management is a crucial issue, especially in server software.
One of the most valuable resources is memory, and memory management
should be handled with extreme care. Memory management has been
partially abstracted in Zend, and you should stick to this abstraction
for obvious reasons: Due to the abstraction, Zend gets full control
over all memory allocations. Zend is able to determine whether a block
is in use, automatically freeing unused blocks and blocks with lost
references, and thus prevent memory leaks.

 

[Eric Hodel]

Hello Dominik,

DS> That's not true, of course you can build "non-web" apps with
PHP [0] -
DS> starting with simple scripts up to GTK bindings <http://
gtk.php.net/>
DS> you have quite a lot of possibilities.

I think the killer argument against this is that a php script never
frees memory, so it is not useable for many non web applications.

While this may have been true in the past, I don't believe this is
current behavior. Getting FastCGI + PHP working has been discussed
several times on the FastCGI developers mailing list. If PHP never
frees memory, it would be completely unsuitable for use with FastCGI.

 

[Robert Wagner]

I think there's a lot of prejudice in that field. There are people
building high-traffic websites using PHP, and I think it scales at least
as good as "Ruby on Rails" (as you can use the same methods for
distributing your server load). There's also commercial support
available from Zend <http://www.zend.com/>.
=20
And last but not least it's still much easier to find a web hoster who
supports PHP (with database bindings etc.) than to get support for Ruby
or even Rails. The latter is changing, though - but at least here in
Germany there's still a long way to go.
=20

regarding webapps php is still the benchmark. why? change the script,
press reload - see the ...aehm error.. no .. changes.
i don't know why theres so much hassle with mod_ruby or fcgi. sooner
or later you will get problems with "in memory hanging classes" or
something. strange effects with "same-request-different-output". i
think it deals with the aggressive cleanup mod_php is doing between
requests so there are no problems on this side.
dry writing sourcecode for ruby/ ror is much more satisfying than php.
but testing or going productionmode with a ruby webapp - for me (with
php background) is quite hard...
how can providers sell virtual domains with mod_ruby, when you (their
customers) must be able to restart the webserver all the time?

regards,
--robert

 

[Greg Donald]

regarding webapps php is still the benchmark. why? change the script,
press reload - see the ...aehm error.. no .. changes.

I agree. I find dispatch.cgi may be slower but it's way more
predictable than dispatch.fcgi.


--=20
Greg Donald
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/

 

[Eric Hodel]

2005/7/16, Dominik Schl=FCtter <[email protected]>:

regarding webapps php is still the benchmark. why? change the script,
press reload - see the ...aehm error.. no .. changes.
i don't know why theres so much hassle with mod_ruby or fcgi. sooner
or later you will get problems with "in memory hanging classes" or
something. strange effects with "same-request-different-output". i
think it deals with the aggressive cleanup mod_php is doing between
requests so there are no problems on this side.
dry writing sourcecode for ruby/ ror is much more satisfying than php.
but testing or going productionmode with a ruby webapp - for me (with
php background) is quite hard...
how can providers sell virtual domains with mod_ruby, when you (their
customers) must be able to restart the webserver all the time?

I let tests do the driving. I don't like the whole switch, reload, =20
wait, verify, tweak, repeat cycle, it doesn't give rapid feedback.

Tests are much more pleasant to work with. They give rapid feedback =20
and allow you to make sure you don't break stuff that used to work =20
(provided your coverage is good enough).

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

 

[Lothar Scholz]

Hello Robert,

RW> how can providers sell virtual domains with mod_ruby, when you (their
RW> customers) must be able to restart the webserver all the time?

They expect that you never to development on the webserver (and they
did not configure it very well). It's still impossible to use mod_ruby
in a shared simple apache environment, but with FCGI you should never
need to restart apache.

If we want a mod_php like environment someone has to patch the ruby
interpreter so that multiple instances can be run by multiple
independent threads without any conflicts. Something that is very hard to do.

 

[Kirk Haines]

Hello Robert,

RW> how can providers sell virtual domains with mod_ruby, when you (their
RW> customers) must be able to restart the webserver all the time?

They expect that you never to development on the webserver (and they
did not configure it very well). It's still impossible to use mod_ruby
in a shared simple apache environment, but with FCGI you should never
need to restart apache.

There is a simple workaround.

Everyone gets their own Apache server running on a specific port. There is
then a server running on port 80 that proxies requests to the private
servers.

So they can do anything that they want in their own environment.

Once upon a time I ran a corporate development network like this. Each
developer had his own sandbox, but it was all on a shared server and the
server on port 80 proxied everything. Worked great.


Kirk Haines

 

[Robert Oliver]

------=_Part_1322_12156107.1121721452486
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
=20
There is a simple workaround.
=20
Everyone gets their own Apache server running on a specific port. There i= s
then a server running on port 80 that proxies requests to the private
servers.
=20
So they can do anything that they want in their own environment.
=20
Once upon a time I ran a corporate development network like this. Each
developer had his own sandbox, but it was all on a shared server and the
server on port 80 proxied everything. Worked great.
=20
=20
Kirk Haines
=20
=20

Kirk,

This is a great idea. It seems you'd have a headache on the front end with=
=20
the Apache proxy server, but some careful management of that might prove=20
helpful.

My company provides mod_ruby and mod_fastcgi, but we do recommend people=20
develop on their machines, or with fcgi off. Turning fcgi off in Rails v13+=
=20
isn't so bad, as they've really speed up the core.

We're working a script to kill off processes that are in their name, but it=
s=20
not yet done, because even though you can say "Don't develop on this=20
machine, or don't have fcgi on if you do so", people still will from time t=
o=20
time

--=20
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.
http://www.ocssolutions.com/
Ruby / Ruby on Rails Discussion at http://www.rubyforums.com/

------=_Part_1322_12156107.1121721452486--

 

[Kirk Haines]

This is a great idea. It seems you'd have a headache on the front end with
the Apache proxy server, but some careful management of that might prove
helpful.

I say a lot of bad things about Apache2, but the proxy support is very easy to
use. Especially in a corporate environment where employees aren't turning
over rapidly, it's no problem. It's just like name based virtual hosting,
but all of the requests for the virtual host are then just proxied out to the
developer's server.

It's not a management headache at all.

The biggest management headache actually comes from developers who know just
enough to really mess up their development server's configuration, but not
enough to fix it, in my experience. Fortunately, most people deemed
employable are capable of learning, so this is a problem that can mostly be
educated away.


Kirk Haines

 

[Robert Oliver]

------=_Part_1382_31182482.1121722842962
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
=20
It's not a management headache at all.
=20
The biggest management headache actually comes from developers who know= =20
just
enough to really mess up their development server's configuration, but no= t
enough to fix it, in my experience. Fortunately, most people deemed
employable are capable of learning, so this is a problem that can mostly= =20
be
educated away.
=20
=20
Kirk Haines
=20
=20

As you said though, in the corporate environment, you can lay down more=20
ground rules and hopefully prevent some mess that could ensue with virtual=
=20
hosting in this manner

However, either way, keeping regular, frequent backups of all the=20
apache2.conf's seems to be in order I could see someone turning into a=
=20
full time Apache administrator, solving a ton of little config issues.

--=20
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.
http://www.ocssolutions.com/
Ruby / Ruby on Rails Discussion at http://www.rubyforums.com/

------=_Part_1382_31182482.1121722842962--

 

[Ezra Zygmuntowicz]

As you said though, in the corporate environment, you can lay down
more
ground rules and hopefully prevent some mess that could ensue with
virtual
hosting in this manner

However, either way, keeping regular, frequent backups of all the
apache2.conf's seems to be in order I could see someone turning
into a
full time Apache administrator, solving a ton of little config issues.

--
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.
http://www.ocssolutions.com/
Ruby / Ruby on Rails Discussion at http://www.rubyforums.com/

I run something similar except the apache up front proxies to
lighttpd instances for each app or developer. Much less overhead than
running many apaches ;-)
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
(e-mail address removed)

 

[Robert Wagner]

If we want a mod_php like environment someone has to patch the ruby
interpreter so that multiple instances can be run by multiple
independent threads without any conflicts. Something that is very hard to= do.
=20

that would be very cool. kinda=20
--enable-stupid-webapp=20
configure option. i'd love it.

-robert