On Wed, Oct 21, 2009 at 1:36 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Wed, Oct 21, 2009 at 10:27:23AM -0700, David Birdsong wrote: >> On Wed, Oct 21, 2009 at 4:31 AM, John Lauro <john.la...@covenanteyes.com> >> wrote: >> > You could bump your range up. It might help if you have a high connection >> > rate and not just a high number of connections. >> > >> i dont have a high connection rate. my connection over localhost is >> just intended to mimic user behavior. i >> >> it boils down to is it the os, or lighttpd or both? >> >> can a backed up listen queue delay a tcp handshake? my guess would be >> that the OS would start sending RST's when a server isn't clearing out >> it's listen queue. > > when a backlog is full, the system simply drops the SYNs, that's what > allows the client to try again. There are still applications around > which do listen(fd, 5) because that was an example in many school > manuals. That limits the backlog to 5 entries ... > > Also, check your somaxconn sysctl. It's also a limit on the SYN > backlog size, and that one is generally set to 128 by default. > You need to restart the application bound to the listening port > when you change somaxconn or tcp_max_syn_backlog for them to take > effect. > > Hoping this helps, > Willy
All of this helped. Thanks list. I upped a few of these parameters resulting in a fast handshake but slow request-serve time in lighttpd. This helped to narrow it down to lighttpd and not the OS and then further narrowed it down to a module that we had written poorly that was devastating to lighttpd performance in general -been running it for probably a few years now, it predates me. It's basically a module that reads in a file of rejected and white listed referrer domains and rejects or white lists every single request. Poorly written to be sure, but this sounds like something I'd like to do higher up the proxy chain anyway. ...sound like a job for my new hammer that hammers all nails - haproxy. > > >
