On 5/26/05, Perrin Harkins <[EMAIL PROTECTED]> 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.
