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

[Gustaf N. <ne...@wu...>]

Am 04.12.12 20:06, schrieb Stephen Deasey:
> - we should actually ship some code which searches for *.gz versions 
> of static files
this would mean to keep a .gz version and a non-.gz version in the file 
system for the cases, where gzip is not an accepted encoding. Not sure, 
i would like to manage these files and to keep it in sync.... the 
fast-path cache could keep gzipped copies, invalidation is already there.
>
>     * 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.
this path is ok. when neither mmap or cache is set, fastpath can call 
ReturnOpenFd, and ReturnOpen send the data blindly to the writer if 
configured, which does not handle ranges. This needs some refactoring.
>
>     * 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.

i am not complaining, just trying to understand the historical layers. 
Without the call-graph the current code is hard to follow.

> 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.
The code in naviserver-connthreadqueue handles already read-aheads with 
SSL. i have removed there these hacks already; i think, these were in 
part responsible for the sometimes erratic response times with SSL.

-gustaf neuamnn