On Tue, Dec 4, 2012 at 5:21 PM, Gustaf Neumann 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 o
On Mon, Dec 3, 2012 at 10:38 AM, Gustaf Neumann 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 fixed in the nss
On Thu, Nov 29, 2012 at 6:51 PM, Gustaf Neumann 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. The delivery o
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
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 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 think the thing
On Wed, Nov 28, 2012 at 10:38 AM, Gustaf Neumann 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
> queued.
>
>
Am 05.12.12 00:41, schrieb Stephen Deasey:
> On Wed, Nov 28, 2012 at 10:38 AM, Gustaf Neumann 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 maxth
