On 06.12.12 13:13, Stephen Deasey wrote:
> I guess it depends on how the website is deployed: in a more modern
> set-up CSS is often compiled from SASS or LESS; javascript needs to be
> minified and combined, possibly compiled using Google's optmising
> compiler, maybe from coffee script; images ar
On Tue, Dec 4, 2012 at 10:55 PM, Gustaf Neumann wrote:
> 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 g
On Tue, Dec 4, 2012 at 10:24 PM, Gustaf Neumann wrote:
>
> Today, i was hunting another problem in connection with nsssl, which
> turns out to be a weakness of our interfaces. The source for the problem
> is that the buffer management of OpenSSL is not aligned with the buffer
> management in navis
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
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.
>
>
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
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
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
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
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 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
Am 29.11.12 19:51, schrieb Gustaf Neumann:
> However, i am still in the process to clean up and address
> some strange interactions (e.g. for nsssl some socket
> closing interactions between driver and connection threads
> seems to complex to me), so i am still for a while busy with that
The prob
Am 29.11.12 20:24, schrieb Jeff Rogers:
>
> Hi Gustaf,
>
> One quick idea on the writer thread is to, regardless of size always
> make one write attempt in the conn thread, and if less than the
> complete buffer was written, then pass the remainder off to the writer
> thread. This would get the
This is good engineering work. I rise my hat to that.
Congrats,
Maurizio
From: Gustaf Neumann [mailto:neum...@wu.ac.at]
Sent: 29 November 2012 19:51
To: naviserver-devel@lists.sourceforge.net
Subject: Re: [naviserver-devel] naviserver with connection thread queue
Dear all,
one more
Gustaf Neumann wrote:
> Funny enough, the delivery of the error message blocked the connection
> thread longer than the delivery of the image when it is above the
> writersize.
>
> I will reduce the writersize further, but still a slow delivery can even
> slow down the delivery of the headers, whic
Dear all,
one more update. Here is now the data of a full day with the
Async-Writer thread. The avg queueing time dropped from 0,0547 to
0,0009, the standard deviation from 0,7481 to 0,0211. This is a
noticable improvement.
accept queue run total
avg 0, 0,0009 0,1304
Dear all,
here is a short update of the findings and changes since last week.
One can now activate for nslog "logpartialtimes", which adds an entry to
the access log containing the partial request times (accept time,
queuing time, and run time). The sample site runs now with minthreads ==
5,
Dear all,
The idea of controlling the number of running threads via queuing
latency is interesting, but i have to look into the details before i
can comment on this.
before one can consider controlling the number of running threads via
queuing latency, one has to improve the awareness in NaviS
On 18.11.12 20:34, Stephen Deasey wrote:
On Sun, Nov 18, 2012 at 1:22 PM, Gustaf Neumann wrote:
Here are some actual figures with a comparable number of requests:
with minthreads==maxthreads==2
requests 10182 queued 2695 connthreads 11 cpu 00:05:27 rss 415
below are the previous values, c
On Sun, Nov 18, 2012 at 1:22 PM, Gustaf Neumann wrote:
> On 14.11.12 09:51, Gustaf Neumann wrote:
>
> On 13.11.12 15:02, Stephen Deasey wrote:
>
> On Tue, Nov 13, 2012 at 11:18 AM, Gustaf Neumann wrote:
>
> minthreads = 2
>
> creating threads, when idle == 0
> 10468 requests, connthreads 267
On 14.11.12 09:51, Gustaf Neumann wrote:
On 13.11.12 15:02, Stephen Deasey wrote:
On Tue, Nov 13, 2012 at 11:18 AM, Gustaf Neumann wrote:
minthreads = 2
creating threads, when idle == 0
10468 requests, connthreads 267
total cputime 00:10:32
creating threads, when queue >= 5
re
On 13.11.12 15:02, Stephen Deasey wrote:
> On Tue, Nov 13, 2012 at 11:18 AM, Gustaf Neumann wrote:
>> minthreads = 2
>>
>> creating threads, when idle == 0
>> 10468 requests, connthreads 267
>> total cputime 00:10:32
>>
>> creating threads, when queue >= 5
>> requests 10104 connthreads
On Tue, Nov 13, 2012 at 11:18 AM, Gustaf Neumann wrote:
>
> minthreads = 2
>
> creating threads, when idle == 0
>10468 requests, connthreads 267
>total cputime 00:10:32
>
> creating threads, when queue >= 5
>requests 10104 connthreads 27
>total cputime 00:06:14
What if you set min
Dear all,
again some update:
The mechanism sketched below works now as well in the regression test.
There is now a backchannel in place that lets conn threads notify the
driver to check the liveliness of the server. This backchannel makes as
well the timeout based liveliness checking obsolete
Some update: after some more testing with the new code, i still think,
the version is promising, but needs a few tweaks. I have started to
address the thread creation.
To sum up the thread creation behavior/configuration of naviserver-tip:
- minthreads (try to keep at least minthreads thread
Dear all,
There is now a version on bitbucket, which works quite nice
and stable, as far i can tell. I have split up the rather
coarse lock of all pools and introduced finer locks for
waiting queue (wqueue) and thread queue (tqueue) per pool.
The changes lead to significant finer lock granula
26 matches
Mail list logo
