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 ===