mod_perl_vs_fastcgi_and_mysql_trashing

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: Re: [Slashcode] PHPSlash vs Slash..
From: "Dave Aiello" <dave_aiello@ctdata.com>
Date: Mon, 28 Feb 2000 21:23:28 GMT


Commenting on remarks from Chris Nandor and James Turinsky:

> >
> >Well, exactly *what* kind of machines are you using?  SMP PIII's?
> >Overclocked Athlons?  You got 512MB RAM in those suckers?
> 
> One is a PowerPC G3/292 MHz with 160MB.  Another is PIII/450 with 128MB, I
> think, and the other is like a PIII/550 with about 512MB RAM.  I also had
> it on a PPro/200 with, I think, less than 100MB.  That one was fine, but
> only handled really small loads.
> 

I do not have a serious Linux server in my arsenal yet.  Everything I have at 
my disposal at the moment is Solaris or NT.  So, the environments I am familiar 
with are not mySQL and Apache/mod_perl.  However, I have ported Slash 0.3, so I 
am familiar enough with the code and its operation to make some comments on 
this discussion.

Although Apache / mod_perl is a highly scalable environment, it is not nearly 
as tunable as FastCGI or Velocigen.  By tunable, I mean (at the simplest level) 
that we can say how many processes we want to dedicate to specific tasks and 
know that these wishes will be honored by all tiers of the application.

This is the result of Apache's tendency to create as many processes as it needs 
to serve the current demand.  In a hobbyist environment, this is potentially 
deadly because of limited hardware budgets and the potential impact of the 
Slashdot effect.  In the corporate environment (behind firewalls), this is 
often unacceptable because boxes are often not dedicated to a single task.

> 
> >I'll buy it on the grounds that mod_perl tends to suck a lot of RAM and on
> >older machines (say a P-200 no MMX with the maximum 128MB EDO DRAM) you can
> >start running outta RAM and into swap with good amounts of traffic.
> 
> Yeah, that is the main thing.  You need RAM.  If you have lotsa RAM, you
> are fine.  If you don't ... well, get more.  :)
> 

Another thing that would help performance a lot would be using a database that 
had an enterprise-level feature set.  For instance, the tendency of mySQL to 
lock entire tables has resulted in user table information, which used to be 
housed in one table in 0.3, being split into 5 separate tables in 0.9.  If you 
were running a database that supports row level locking, this could easily go 
back to one table and would improve performance measurably, in some cases.

However, this is the tip of the iceberg in terms of database optimization that 
could be available with a bigger RDBMS.

> 
> >Also PHP can be made --with-mysql which I believe ties in MySQL bits and
> >pieces, as compared to calling other bits of Perl to talk to MySQL.  PHP
> >effectively becomes a MySQL client inside of Apache or something.
> 
> I don't know how that would speed anything up; mod_perl only needs to load
> in the shared libraries for DBD::mysql and DBI once for each process, and
> then it speeds right along.  PHP might load into the process faster than
> Perl, but I don't know if that is too relevant, when each process is
> handling a couple of hundred requests anyway, and for each one that code is
> already loaded in.
> 

I have no idea about how Perl compares to PHP in terms of apparent performance 
in data retrieval operations from the user perspective at the Web application 
level.  I would suggest that it is much harder to measure this objectively than 
people think.



A comment about the recent posting from Patrick where he said, "The idea here 
is to make what we have better, not re-write it from ground up, or get 
distracted about various 'maybe if's'.  It's written in mod-perl, and that's 
what we're going to stick with.":

You need to be careful that you do not choke off debate on this issue.  If you 
have a robust OpenSource project, there is no reason why Slash implementations 
cannot be done using other gateway interfaces.  For instance, a FastCGI 
implementation would still probably have 80 percent of the code in common with 
a mod_perl implementation, if not more.  If this improves performance 
substantially in certain environments, it's a better alternative than losing 
people from the developer group because they defect to totally different 
programming environments and reinvent the wheel.

The same holds true for database diversity.  mySQL has served Slash and 
Slashdot well up to now, but not everyone can nor will use mySQL, no matter how 
much its performance improves in the future.  Who knows?  Slashdot may find it 
cheaper to one day run on Sybase, Oracle, or Informix, if it continues to grow 
exponentially.

You may not feel it is possible for you to support much diversity in these 
respects, but if the Slashcode project takes off, you won't have to do as much 
as you think.  The contributors will take on some, if not most, of the burden.

Dave Aiello

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu