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 queue >= 5
requests 10104 connthreads 27
total cputime 00:06:14
What if you set minthreads == maxthreads?
The number of thread create operations will go further down.
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, competed by the number of
queuing operations and the rss size in MV
with minthreads=2, create when queue >= 2
requests 10104 queued 1584 connthreads 27 cpu 00:06:14
rss 466
as anticipated, thread creations and cpu consumption went
down, but the number of queued requests (requests that could
not be executed immediately) increased significantly.
Maybe the most significant benefit of a low maxthreads value
is the reduced memory consumption. On this machine we are
using plain Tcl with its "zippy malloc", which does not
release memory (once allocated to its pool) back to the OS.
So, the measured memsize depends on the max number of
threads with tcl interps, especially with large blueprints
(as in the case of OpenACS). This situation can be improved
with e.g. jemalloc (what we are using in production, which
requires a modified tcl), but after about 2 or 3 days
running a server the rss sizes are very similar (most likely
due to fragmentation).
-gustaf neumann
When running already at minthreads, the connection thread
timeout is ignored (otherwise there would be a high number
of thread create operations just after the timeout expires
to ensure minthreads running connection threads). With
connsperthread == 1000, there will be about 10 thread create
operations for 10000 requests (not counting the 2 initial
create operation during startup for minthreads == 2). So,
the cpu consumption will be lower, but the server would not
scale, when the requests frequency would require more
connection threads. Furthermore, there will be most likely
more requests put into the queue instead of being served
immediately.
When we assume, that with minthreads == maxthreads == 2
there won't be more than say 20 requests queued, a similar
effect could be achieved by allowing additional thread
creations for more than 20 requests in the queue. Or even
more conservative, allowing thread creations only when the
request queue is completely full (setting the low water mark
to 100%) would as well be better than minthreads ==
maxthreads, since the server will at least start to create
additional threads in this rather hopeless situation, where
with minthreads == maxthreads, it won't.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
