in reply to More than mod_cgi less than mod_perl.

2. mod_cgi - It has served us for years but it's getting quite old and what most people care for - it's slow.

Well so am I ... but seriously, I think the slow argument is not as valid as it once was. Copy-on-write has made fork on modern *nixes very efficient. So before you start calling mod_cgi slow, take a look at your *own* code and ensure it's not slow.

mod_cgi has a lot going for it *because* it's old - it's well understood, it's universal, it's cleaner, any script/executable can be run under it (I wouldn't be suprised to see java progs under mod_cgi as the JVM start-up times continue to improve).

-derby
  • Comment on Re: More than mod_cgi less than mod_perl.

Replies are listed 'Best First'.
Re^2: More than mod_cgi less than mod_perl.
by techcode (Hermit) on Jun 08, 2005 at 09:34 UTC
    Well actualy I dont think my code is that bad/slow :)

    I'll try to find exact code that recently made problems to one of my "customers". It's some banner rotation script. And he puted ~ 8 banners on the pages (wich means on each page request, you get extra 8 calls of that CGI/Perl script). And his server went down.

    He belives that particular script made problems as once he removed it, server was faster, and didnt went down since. Nothing else was added/removed so ...

    Of course that doesnt mean it's scripts fault for shure, nor that he couldnt have done it some other way that wouldnt call it 8 times per each page.


    So where can I find a way to test the speed of the script? I mean, how many request per second can it process, or something like that? Someone wrote that forking is speeded up these days. So let's test it out. Maybe it's only bad code ...

    PS. The funiest thing about that script, is that it's creator - said he should normaly only place 2 - 3 banners per page :)
[reply]

In Section Seekers of Perl Wisdom