You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Erik Aronesty <er...@q32.com> on 2005/05/26 04:16:51 UTC
high throughput perl server
In order to deal with apache's problems handling a high load, I wrote
a trivial pure perl server with few features.
http://www.documentroot.com/code/ppcgid
Since it's nonforking, it's not appropriate if your web pages block on
IO, or if some of them are much slower than others, etc.
But it's blazingly fast for certain kinds of applications.
I based on the IO::Select "multiplexing" code from O'reilly. It's
hastily written and probably buggy, and doesn't support HTTP features
like keepalive
which could speed it up, and there's probably a zillion things in it
that
can be sped up.
But it's way faster than apache/mod_perl.
- Erik
Re: high throughput perl server
Posted by Joel <pe...@joelrichard.com>.
Hi folks,
Maybe I'm just a complete newbie to this or I completely do not
understand what we're talking about here... :)
...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 <pe...@elem.com> wrote:
>> On Thu, 2005-05-26 at 14:53 -0400, Erik Aronesty wrote:
>> > ppcgid kicks it's butt in that arena.
>>
>> > 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.
Re: high throughput perl server
Posted by Erik Aronesty <er...@q32.com>.
Your server blocks on reads/accepts.
It should never do a blocking read or a blocking write. It must always
check for readability/writability beforehand, and if a partial write has
occurred, defer the processing until the socket is ready.
We really ought to look at the source/guts of ppcgid and merge them.
David Nicol wrote:
>On 5/26/05, Perrin Harkins <pe...@elem.com> wrote:
>
>
>>On Thu, 2005-05-26 at 14:53 -0400, Erik Aronesty wrote:
>>
>>
>>>ppcgid kicks it's butt in that arena.
>>>
>>>
>>>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.
>
>
>
Re: high throughput perl server
Posted by David Nicol <da...@gmail.com>.
On 5/26/05, Perrin Harkins <pe...@elem.com> wrote:
> On Thu, 2005-05-26 at 14:53 -0400, Erik Aronesty wrote:
> > ppcgid kicks it's butt in that arena.
>
> > 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.
Re: high throughput perl server
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2005-05-26 at 14:53 -0400, Erik Aronesty wrote:
> If all you're doing is serving static pages, you're probably not hanging
> out on the modperl list.
>
> That being said, thttpd rocks, but it's cgi speed is awfully slow.
> ppcgid kicks it's butt in that arena.
Multiplexing while running arbitrary perl code that does DBI fetches and
other blocking tasks is not very easy. That's why most people who need
more speed for static files use some kind of proxy setup (perlbal and
tux do this) to send the dynamic stuff to mod_perl or just put the
static files (i.e. images mostly) on a separate subdomain handled by the
multiplexing server.
> 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.
I think you'd be better off using a well-tested and supported tool like
mod_perl for the dynamic stuff than trying to replicate it in another
server, but I admit to being biased.
- Perrin
Re: high throughput perl server
Posted by Erik Aronesty <er...@q32.com>.
> theshz wrote:
> Have you looked at POE? http://poe.perl.org/
POE is VERY cool!. Thanks for the link. It's the same event-driven
model that I needed. It was hard for me to read or understand. I'll
probabyl keep using my little ppcgid server until I find a need for a
serious framework like POE. I'd bet there's a bit more overhead in POE
than I wanted for a lightweight highspeed perl web app. But that's just
guessing based on a one hour review of the docs/examples.
> Perrin Harkins wrote:
> When all you're doing is serving static files, I read about POE. It's
a beautiful thing -uses the same event-driven model as ppcgid and
If all you're doing is serving static pages, you're probably not hanging
out on the modperl list.
That being said, thttpd rocks, but it's cgi speed is awfully slow.
ppcgid kicks it's butt in that arena.
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.
- Erik
Perrin Harkins wrote:
>When all you're doing is serving static files, most people run out of
>bandwidth long before they hit any limitation of apache. If you really are
>running into limits on your static files, you would be better off using one
>of these:
>Tux, http://www.redhat.com/docs/manuals/tux/
>thttpd, http://www.acme.com/software/thttpd/
>Perlbal, http://www.danga.com/perlbal/
>
>All are open source and free.
>
>- Perrin
>
>On Thursday 26 May 2005 2:43 am, theshz wrote:
>
>
>>Have you looked at POE? http://poe.perl.org/
>>
>>Z.
>>
>>----- Original Message -----
>>From: "Erik Aronesty" <er...@q32.com>
>>To: <mo...@perl.apache.org>
>>Sent: Wednesday, May 25, 2005 7:16 PM
>>Subject: high throughput perl server
>>
>>
>>
>>>In order to deal with apache's problems handling a high load, I wrote
>>>a trivial pure perl server with few features.
>>>
>>> http://www.documentroot.com/code/ppcgid
>>>
>>>Since it's nonforking, it's not appropriate if your web pages block on
>>>IO, or if some of them are much slower than others, etc.
>>>
>>>But it's blazingly fast for certain kinds of applications.
>>>
>>>I based on the IO::Select "multiplexing" code from O'reilly. It's
>>>hastily written and probably buggy, and doesn't support HTTP features
>>>like keepalive
>>>which could speed it up, and there's probably a zillion things in it
>>>that
>>>can be sped up.
>>>
>>>But it's way faster than apache/mod_perl.
>>>
>>>- Erik
>>>
>>>
>
>
>
Re: high throughput perl server
Posted by Perrin Harkins <pe...@elem.com>.
When all you're doing is serving static files, most people run out of
bandwidth long before they hit any limitation of apache. If you really are
running into limits on your static files, you would be better off using one
of these:
Tux, http://www.redhat.com/docs/manuals/tux/
thttpd, http://www.acme.com/software/thttpd/
Perlbal, http://www.danga.com/perlbal/
All are open source and free.
- Perrin
On Thursday 26 May 2005 2:43 am, theshz wrote:
> Have you looked at POE? http://poe.perl.org/
>
> Z.
>
> ----- Original Message -----
> From: "Erik Aronesty" <er...@q32.com>
> To: <mo...@perl.apache.org>
> Sent: Wednesday, May 25, 2005 7:16 PM
> Subject: high throughput perl server
>
> > In order to deal with apache's problems handling a high load, I wrote
> > a trivial pure perl server with few features.
> >
> > http://www.documentroot.com/code/ppcgid
> >
> > Since it's nonforking, it's not appropriate if your web pages block on
> > IO, or if some of them are much slower than others, etc.
> >
> > But it's blazingly fast for certain kinds of applications.
> >
> > I based on the IO::Select "multiplexing" code from O'reilly. It's
> > hastily written and probably buggy, and doesn't support HTTP features
> > like keepalive
> > which could speed it up, and there's probably a zillion things in it
> > that
> > can be sped up.
> >
> > But it's way faster than apache/mod_perl.
> >
> > - Erik
Re: high throughput perl server
Posted by theshz <th...@gmail.com>.
Have you looked at POE? http://poe.perl.org/
Z.
----- Original Message -----
From: "Erik Aronesty" <er...@q32.com>
To: <mo...@perl.apache.org>
Sent: Wednesday, May 25, 2005 7:16 PM
Subject: high throughput perl server
> In order to deal with apache's problems handling a high load, I wrote
> a trivial pure perl server with few features.
>
> http://www.documentroot.com/code/ppcgid
>
> Since it's nonforking, it's not appropriate if your web pages block on
> IO, or if some of them are much slower than others, etc.
>
> But it's blazingly fast for certain kinds of applications.
>
> I based on the IO::Select "multiplexing" code from O'reilly. It's
> hastily written and probably buggy, and doesn't support HTTP features
> like keepalive
> which could speed it up, and there's probably a zillion things in it
> that
> can be sped up.
>
> But it's way faster than apache/mod_perl.
>
> - Erik
>
>