In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Ask Bjoern Hansen) wrote:
> and his perl code and knowledge about modperl is not uh, the best
> we've seen around here either. =)
*chuckle* I posted *my* code to perl.dbi.users in case any of you are
interested in seeing it and could make any constructive suggestions. I'd
be very interested in some feedback from you more experienced ladies and
gents.
but basically what it comes down to is, this is the mentality we're up
against when it comes to php vs perl: (excerpted from the siteadmins's
last e-mail to me)
If mod_perl really is the *utter complete DOG* that he says it is, how
could so many sites use it?
on 10/25/2001 06:13, Jason Nugent at [EMAIL PROTECTED] wrote:
> On Thu, 25 Oct 2001 at 4:55am, FuzzBuster used Jedi Powers and said
>
>> on 10/24/2001 19:28, Jason Nugent at [EMAIL PROTECTED] wrote:
>>
>>> Any Apache:: module requires mod_perl installed. As was mentioned,
>>> doing so would grossly inflate the size of the httpd binary as it
>>> is, increasing the amount of ram needed by each httpd process,
>>> regardless of whether or not that process was involved in running a
>>> mod_perl script.
>>
>> Notwithstanding the fact that we're talking about a shared memory
>> process where each child uses only a fraction of the main httpd
>> process? Oh, did you think I wasn't aware of what we're talking
>> about?
>
> That fraction is about a third of what httpd would normally use.
> You're still talking about a hundred megs of memory when there are
> 120 httpd processes running at any one given point in time.
> Considering each process eats up about 6 megs of memory, and shares
> about a third to one half of that. (thats binary plus application
> together). The current stripped Apache binary is a little over two
> megs. Adding mod perl would increase to about four.
>
>
>> How many concurrent httpd processes are you permitting for the
>> server currently? Do you even have an upper limit set to, if not
>> prevent paging, at least to prevent thrashing? (one would assume so,
>> but still I must ask)
>
> You can't run Apache without having an upper limit. The current
> upper limit on BU is 150. I run busier sites than BU with lesser
> servers that have MaxClients of a thousand or more, without problems.
> The fault does not lie with Apache here.
>
>> ...and one wherein the DBI, CGI, and other modules necessary are
>> ALSO all in shared memory space and do not need to be recompiled,
>> reloaded, and re-started for each individual connection?
>
> CGI is done through a completely external process, spawned in it's
> own shell by apache. There is no shared memory for external perl
> processes.
>
>> isn't that the way you have PHP set up now? so that it doesn't have
>> to re-load itself every time its called? so that it's optimized to
>> shit and gone ? so that it takes advantage of shared memory for each
>> child process?
>
> Exactly. thus, the -entire- point about why PHP kicks the shit out of
> Perl. PHP behaves this way. Perl, on the other hand, does not. You
PHP behaves this way ONLY because he's compiled it into apache, but he
won't admit that this is THE ONLY reason it has any advantage over
external perl processes.
> are also missing one key "feature" regarding mod_perl. Perl scripts
> do not terminate after they finish. They remain in memory, compiled
> as a subroutine inside of the Apache:: registry. While this would
> normally be a respectible concept, it forces you to restart Apache
> -every time- you make a change to a CGI script. Change a variable
> name? Restart apache. Add a line of code? Restart apache. No thank
> you.
O_o this is true? Restart the whole damned Apache, cuz I changed ONE
variable in a .cgi ?
>> It hurts when I laugh this hard.
>>
>> You give your peasants the tools they need to go out and cull the
>> fields each day, and you send slippered servants out to feed them
>> while in the fields and to take their place while they rest.
>>
>> you make MY peasants BUILD their own tools EACH and every day, and
>> take them away again when they finish, and force them to take the
>> time to rebuild their tools _every single day_, before you even LET
>> them go out to cull the fields, and then go and claim that we have a
>> level playing field when you show me how many more bushels your
>> peasants bring back ?
>
> Why dont you just quit it with the dumbass analogies? You're making
> my king piss himself from laughing at you. History has been about
> making the playing field un-level anyway. That's how you make
> progress.
>
>> Show me benchmarks when you DON'T have PHP compiled into Apache
>>
>> (forcing php to restart and rebuild its tools for each process like
>> you're making my CGI script do),
>
> As was mentioned in many email thus far, PHP -does- reload the script
> and parse/interprete/compile it -each- time it is accessed. The only
> diffence is that the interpreter itself is inside of the httpd
> binary. That is, of course, the entire point of a server side
> embedded scripting language.
>
> Fuzz, if BU was just using Perl, and we were running UBB instead of
> Vbulletin, and none of the other hosted sites used PHP either, then
> sure. Why the hell not install mod_perl. But, you are in the
> minority here. Going from Perl to PHP is not difficult. As Pete
> mentioned, you can use this opportunity to grow as both a developer
> and an individual. I've done Perl for a long time. Many years ago, I
> was like you. I didn't want to use anything other than Perl. Now,
> I'm glad someone did the same thing to me.
This, ladies and gents, is what we're up against as Perl proponents. If
we're lacking in comparison with PHP _truely_ then I don't know what I
can do other than bite the bullet and give up developing in Perl for
this site, which would suck considering how easy it is for me to create
the HTML-elements using CGI's function oriented interface, and which
also has the added benefit of generating automatic closures for all the
html elements used. i.e. p("text"); generates <p>text</p> properly
--
Scott R. Godin | e-mail : [EMAIL PROTECTED]
Laughing Dragon Services | web : http://www.webdragon.net/
