From: Gustaf N. <ne...@wu...> - 2012-12-04 17:21:32
|
Am 29.11.12 19:51, schrieb Gustaf Neumann: > 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. Most likely, i won't address this now. however, i > will check the effects of fastpath cache, which was deactivated so far... It turned out that the interactions between the various delivery methods of naviserver are more differentiated than i expected. As one can see from the graphics below, the content returning infrastructure of naviserver depends is very differentiated. Look below at the call graph. * The boxed nodes are the tcl commands, the pink nodes denote handling by the writer thread. * Of course, the ns_writer command can be used on the application layer and tries always delivery via the writer thread. * The implicit calls (e.g. ns_returnfile) go through FastReturn(), which calls Ns_ConnReturnOpenFd() only, when neither caching or mmap are activated. As soon one of these are activated, ns_return etc. will never use the writer thread. * All of the error messages or redirects use the path via Ns_ConnWriteChars. * Only content sent via Ns_ConnWriteVChars has the chance to get compressed. * Similarly, range requests are not handled when the data is not sent ReturnOpen to the writer Queue. * The nodes with the gray background are marked as deprecated * The nodes with the grey font are not called at all * The nodes with the blue font are in the driver, and not further analyzed. To make it short: * caching and mmap deactivate the implicit delivery via the writer * the non-200 return messages are always delivered via the connection thread; reducing the writersize does not make any difference. * there is quite some potential to simplify / orthogonalize the servers infrastructure. * improving this structure has nothing to do with naviserver-connthreadqueue, and should happen at some time in the main tip. -gustaf neumann |