Jonathon Weiss wrote: > 1) multiple client connections come in and are passed from Apache to > SKS (possibly while SKS is working on a previous query). > > 2) SKS works on the first query and returns the answer > > 3) for some reason the owner of the second query has disappeared (I > assume this is because the client gives up, and maybe hist reload or > something, and Apache notices that the client is gone and drops all > connection state) > > 4) SKS waits 'wserver_timeout' (default 60) seconds, and gives up and > goes on to the next connection. > > 5) The next client gave up during the timeout, and the problem expands > out of control. […] > This all leaves me with several questions: > > 1) Does anyone see any flaws in my analysis? or work-around?
There is something strange happening in items 3 or 4. If Apache somehow « drops all connection state » it should close its connection to SKS, no? And SKS should then instantly see the closed connection instead of timing out. > 3) Any suggestions on what to do if/when wserver_timeout=1 becomes > insufficient? In addition to what Phil Pennock suggested you might want to try with very large ProxyIOBufferSize (http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyiobuffersize) and maybe also ProxyReceiveBufferSize (http://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html#proxyreceivebuffersize). I read that this last one may require OS dependent tweekings. > 4) Any chance of detecting this sort of problem in sksd and skipping > the timeout altogether? If it is what you describe in 3 & 4 it would be worthwhile to investigate why SKS does not immediatly see that the connection was closed. -- Kim Minh. _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel