On Tue, Dec 4, 2012 at 5:21 PM, Gustaf Neumann neum...@wu.ac.at 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
On Mon, Dec 3, 2012 at 10:38 AM, Gustaf Neumann neum...@wu.ac.at wrote:
All changes are on bitbucket (nsssl and naviserver-connthreadqueue).
I found this nifty site the other day:
https://www.ssllabs.com/ssltest/analyze.html?d=next-scripting.org
It's highlighting a few things that need
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.
Am 04.12.12 20:25, schrieb Stephen Deasey:
I found this nifty site the other day:
https://www.ssllabs.com/ssltest/analyze.html?d=next-scripting.org
It's highlighting a few things that need fixed in the nsssl module,
including a couple of security bugs. Looks like relatively little code
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
On Tue, Dec 4, 2012 at 10:55 PM, Gustaf Neumann neum...@wu.ac.at wrote:
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.
Well, I
On Wed, Nov 28, 2012 at 10:38 AM, Gustaf Neumann neum...@wu.ac.at wrote:
It is interesting to see, that with always 5 connections threads running and
using jemalloc, we see a rss consumption only slightly larger than with
plain tcl and zippy malloc having maxthreads == 2, having less requests
Am 05.12.12 00:41, schrieb Stephen Deasey:
On Wed, Nov 28, 2012 at 10:38 AM, Gustaf Neumann neum...@wu.ac.at wrote:
It is interesting to see, that with always 5 connections threads running and
using jemalloc, we see a rss consumption only slightly larger than with
plain tcl and zippy malloc
