On Thu, Nov 29, 2012 at 6:51 PM, Gustaf Neumann <neum...@wu.ac.at> wrote: > > It turned out > that the large queueing time came from requests from taipeh, which contained > several 404 errors. The size of the 404 request is 727 bytes, and therefore > under the writersize, which was configured as 1000. The delivery of an error > message takes to this site more than a second. Funny enough, the delivery of > the error message blocked the connection thread longer than the delivery of > the image when it is above the writersize. > > I will reduce the writersize further, but still a slow delivery can even > slow down the delivery of the headers, which happens still in the connection > thread.
This shouldn't be the case for strings, or data sent from the fast path cache, such as a small file (a custom 404), as eventually those should work their way down to Ns_ConnWriteData which will construct the headers if not already sent and pass them, along with the data payload to writev(2). Linux should coalesce the buffers and send in a single packet, if small enough. I wonder if this is some kind of weird nsssl interaction. (For things like sendfile without ssl we could use TCP_CORK to coalesce the headers with the body) ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
