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 <[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. > > >
