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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
