[rescue] spam WPOISON
Curtis H. Wilbar Jr.
rescue at hawkmountain.net
Mon Sep 8 15:17:08 CDT 2003
>From: Dave McGuire
>On Monday, September 8, 2003, at 03:45 PM, Curtis H. Wilbar Jr. wrote:
>> For this application I wouldn't even consider C.
Because I wouldn't want the constant overhead of forking processes
and launching binaries over and over and over....
>> Perl is growing up for this app. This is a web based app. If
>> you run modPerl, then your perl will be resident and the cgi will
>> not need to launch another process/etc.
> It'd still be much slower than C. Perl's performance problems aren't
>all due to interpreter startup overhead. And the last time I ran a
>server-resident Perl interpreter, it had to be restarted every few
>weeks due to memory leaks and memory fragmentation. My servers stay up
>for months (if not years) at a time, so I find this unacceptable.
Sure.. it might be faster than C from a pure execution standpoint... but
we're not just talking about pure code execution efficiency...
I've never run a server resident Perl interpreter... so I can not comment
on how good/bad/stable/unstable they are... I can only comment from a
My server stay up and running for months too if not years... and my
believe is unless I'm changing hardware, a box should never need to be
rebooted, a process restarted, etc.... now of course sometimes we don't
have ideal conditions, but I like everything to stick to that ideal as
best as possible.
>> PHP is also a good choice for this application.... even JSP would
>> probably be good.
> I'd agree with PHP (though it's still nowhere near as fast as C) but
>I think JSP would be overkill.
PHP would be my key choice. JSP probably would be overkill and I don't
know enough about it to really compare.
>> While C is fast... each link the bot hits is going to cause the
>> web browser to launch the application for each link traversed... since
>> the design is links to self along with garbage addresse to pollute
>> their lists, a language that is resident with your web server is best
>> (IMHO of course).
> I agree with this point, though if written in C, the fork()/exec()
>overhead for such a small program won't be all that bad.
It probably wouldn't be... but it would be nice to avoid the overhead
anyway. And given the small size of this application a resident language
such as Perl via modPerl, or PHP via the PHP/Zend engine would not
be inefficient enough as to merit an advantage with going with an external
program and all that is necessary to start/run/support that (fork, exec,
brk, memory management, process table entry management by the OS, etc)
if you have an internal language/interpreter available through the
interface application (web server).
> An even better way would be to write it in C as an Apache module.
>Anybody here ever program against the Apache module API?
That probably would be better (from a pure speed/efficienty aspect). I'd
still choose PHP... easy to use, easy to update, no worries (from the
PHP code that I'd write) if Apache changes interface methodologies, etc.
Hawk Mountain Networks
My e-mail is protected against viruses and spam by MailGuardian
Top notch protection at unbelievable prices
More information about the rescue