Loading ...
Sorry, an error occurred while loading the content.

Re: high throughput perl server

Expand Messages
  • David Nicol
    ... 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
    Message 1 of 8 , May 31 3:26 PM
    • 0 Attachment
      On 5/26/05, Perrin Harkins <perrin@...> 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.
    • Joel
      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
      Message 2 of 8 , Jun 1, 2005
      • 0 Attachment
        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 <perrin@...> 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.
      • Erik Aronesty
        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
        Message 3 of 8 , Jun 15, 2005
        • 0 Attachment
          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 <perrin@...> 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.
          >
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.