Re: high throughput perl server

[prev] [thread] [next] [Date index for 2005/06/01]

Hi folks,

Maybe I'm just a complete newbie to this or I completely do not
understand what we're talking about here... :)=20

=2E..but we've written a home-grown ad server that runs on
Apache2/mod_perl2/PgSQL that serves up 40 or more ads per second
(sustained) where each ad served includes 5-6 hits to the database. Some
of this performance may have to do with the fact that the webserver and
database server are separate boxes which balances load and memory usage.

And we're not really doing anything special. Right now, it's implemented
as a simple registry script which means we're not even using a custom
PerlResponseHandler inside our httpd.conf.

So I can call the script as mod_cgi or as mod_perl or even on the command
line for debugging. Am I doing something wrong? :)

--Joel

>On 5/26/05, Perrin Harkins <perrin@xxxx.xxx> wrote:
>> On Thu, 2005-05-26 at 14:53 -0400, Erik Aronesty wrote:
>> > ppcgid kicks it's butt in that arena.
>>=20
>> > My business partner and I decided on two tactics: he started
>> > building a patch to thttpd to run perl scripts natively as opposed
>> > to exec'ing, and I built a pure perl web server.  I finished first,
>> > so we're using that for now.  But I think that a perl patch to
>> > thttpd (including preloading support) is what we'll be using in the
>> > long run... it's the right way to go.
>
>Me too -- mine is on CPAN as HTTP::Server::Singlethreaded, and apps
>written against it that have to do DBI calls to serve each page are
>responsive enough to deliver multiple pages per second.  I am curious
>to see which will be the choke point as more throughput is needed: the
>MySQL server or the Singlethreaded.  If it turns out that there are
>delays due to ST waiting for DBI results, ST can be made to fork after
>binding the listening ports, but DBI connections must be done after the
>forking, as I understand it, at this time.  Currently my ST
>installation is handling my load perfectly well as a single thread.
>
>I haven't looked at ppcgid yet, I might lift some code out of it for ST
>if it is licensed in a way conducive to that.