George Schlossnagle wrote: > > On Friday, April 4, 2003, at 01:56 PM, Scott R. Godin wrote: >> The question I have is with the current Apache (2.x) > > First off, Apache 2.x is highly beta software. Almost no-one is > running it in production. The questionable thread-safety of many third > party libraries makes anything but the pre-fork MPM largely unusable > for most people (php and perl).
Right. The place that I mention below was using 1.3.x .. Whether or not Apache 2.x is still not widely regarded as stable, this does not invalidate the question. >> and mod_perl (1.27?) >> involved, when a perl program is incorporated into the httpd process in >> this manner, how much more *memory* overhead does each httpd process >> require over related circumstances in php? > > Probably more relevant to that is to look at so-called realistic > performance benchmarks. When the Yahoo! folks were deciding to swicth > from their hown-grown scripting language to something more mainstream, > they did an internal performance bakeoff between a mod_perl solution > and a mod_php solution. Properly tuned they delivered almost identical > performance numbers. Look up Michael Radwin's 'Making The Case for PHP > at Yahoo!' talk from PHPCON 2002 for the details. (It was an > interesting talk no matter outside of this as well. An interesting > take on the differences between language solutions.) performance speed wise and performance in terms of how much extra memory each httpd child requires are different animals. I'll look up the article though. should be interesting reading. >> for example if I use CGI.pm to create a form (using its functional >> interface to produce the actual HTML seen) and also respond to said >> form, how much more RAM will each httpd process require if this is >> run under mod_perl? > > Comparing mod_php to CGI.pm is really apples and oranges. CGI.pm pages > result in a high level of intermingling between Perl code and html > code. The resultant soup looks neither like HTML or Perl. PHP on I don't know how you code personally, or what sort of code you encounter, but when I code CGI.pm applications the processing sections look like perl and the output sections look like html (very much so thanks to CGI.pm's function-oriented interface. This also has the VERY nice side-effect that all the html closures are provided for and wrapped properly... i.e. it's easier to produce well-formed html via this method.) To *me*, the intermingling of html and php looks more like soup. > the other hand is designed for embedding of code fragments within HTML, > producing code that still largely looks like HTML. This allows (but > doesn't force you) to have as much separation of display logic from > application logic as you would like. This isn't PHP FUD, there are > solutions in almost every language that emulate this behavior: > > Perl: Apache::ASP, embperl (both mod_perl) > Python: mod_python, mod_snake, mod_psp > VB: ASP > PHP: PHP > ?: ? true true. > They've chosen this model because for a huge number of people it's the > Right Way (tm) to solve the web problem. > >> >> One argument I've been handed by the php camp is that in a mod_perl >> situation, this will cause apache processes to become much larger, >> thereby taking up more of the precious memory resources. > > In my experience that statement is pretty vacuous. The PHP and > mod_perl footprints both largely depend on the size of the source code > base you are running and the number of extensions/packages you use. > It's hard to get a side-by-side comparison. And why bother. > Performance numbers and code maintainability/extensibility are what > really matter. Also true. Considering an un-mod_perl cgi accessing a database via DBI will run considerably slower than one that is run under mod_perl, and also considerably slower than its php counterpart. This is one of the things I ran into where the people involved outright refused to even consider testing with mod_perl and instead waved specious benchmarks around comparing the perl vs the php in completely unrelated contexts. It was quite frustrating to nice well-formed scripts thrown out because of the lack of support hooks in the httpd process that the 'opposing' scripts were given. >> (consider a large gaming website like planetunreal (which IIRC uses >> .asp), >> or quakeworld, which garner huge volumes of hits on a daily basis) > > I've run PHP on a website doing 130 million page requests/day. I've > also run Apache::ASP on a site doing 10 million hits per day. They > both run fine. Performance wise, the language-intrinsic differences > are small in comparison to user code performance issues (sub optimal > database queries, suboptimal code implementation, poor architectural > choices, etc.). I totally agree with this, which is why the situation was so frustrating. >> This issue needs to be addressed firmly to the php camp, because the >> FUD being spread was enough to cost me one of the most fun hobby >> projects I was involved with, > > Did PHP cheat on your wife and wreck your truck too? Answering FUD > with a plea for how PHP victimized you is highly ironic. If it was Um, what? I don't suppose you'd mind retracting this? > your project, what do you care about the FUD? If it was someone else's > project (or a group project), then presumably the decision to switch > languages was made by someone who had the authority to do so. You > should be upset with them, not with PHP. If you enjoy working on the > project, then fork it and develop in Perl. Perhaps you misunderstood. I'm certainly not blaming PHP, but the people involved with insisting that it be used for everything in this case. No it wasn't my project, no I didn't have any hand in the decision making, nor any hand in making the test comparisons fair in any way, no it's not possible to fork the project although I still have all the perl code I wrote for it, and it was back in 2001 at any rate. This doesn't stop it from bothering me. :) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
