On Tue, Dec 4, 2012 at 10:24 PM, Gustaf Neumann neum...@wu.ac.at 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
On Tue, Dec 4, 2012 at 10:55 PM, Gustaf Neumann neum...@wu.ac.at 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
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 are
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
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 problem
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 best
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
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, which
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
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
On 18.11.12 20:34, Stephen Deasey wrote:
On Sun, Nov 18, 2012 at 1:22 PM, Gustaf Neumann neum...@wu.ac.at 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
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 neum...@wu.ac.at wrote:
minthreads = 2
creating threads, when idle == 0
10468 requests, connthreads 267
total cputime 00:10:32
creating threads, when
On Sun, Nov 18, 2012 at 1:22 PM, Gustaf Neumann neum...@wu.ac.at 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 neum...@wu.ac.at wrote:
minthreads = 2
creating threads, when idle == 0
10468
On 13.11.12 15:02, Stephen Deasey wrote:
On Tue, Nov 13, 2012 at 11:18 AM, Gustaf Neumann neum...@wu.ac.at 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
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
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
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
25 matches
Mail list logo
