Re: [naviserver-devel] naviserver with connection thread queue

[Stephen D. <sd...@gm...>]

On Tue, Dec 4, 2012 at 5:21 PM, Gustaf Neumann <ne...@wu...> wrote:

>
> * Only content sent via Ns_ConnWriteVChars has the chance to get
> compressed.
>

ie. dynamic content with a text/* mime-type. The idea here was you don't
want to try and compress gifs an so on, and static content could be
pre-compressed on disk - at runtime simple look for a *.gz version of the
content.

This could be cleaned up a bit by:

- having an extendable white-list of mime-types which should be compressed:
text/*, application/javascript, application/xml etc.

- we should actually ship some code which searches for *.gz versions of
static files



> * Similarly, range requests are not handled when the data is not sent
> ReturnOpen to the writer Queue.
>

The diagram shows Ns_ConnReturnData also calls ReturnRange, and hence the
other leg of fastpath and all the main data sending routines should handle
range requests.



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


The writer thread was one of the last bits of code to land before things
quietened down, and a lot of the stuff that got talked about didn't get
implemented. One thing that was mentioned was having a call-back interface
where you submit a function to the writer thread and it runs it. This would
allow other kinds of requests to be served async.

One of the things we've been talking about with the connthread work is
simplification. The current code, with it's workarounds for stalls and
managing thread counts is very complicated. If it were simplified and
genericised it could also be used for background writer threads, and SSL
read-ahead threads (as in aolserver > 4.5). So, that's another +1 for
keeping the conn threads simple.