Two issues:
A) What is actually happening.
B) How it is being measured/reported
A) What happens
In the app server you configure the max number of threads (max threads) typical
32 per host.
The min is 1 (you don't see that). The server starts threads as needed up to
the maximum and allows them to live
For a while even if idle so they can be reused.
These threads are in a thread pool waiting for requests , so the OS sees them
as live threads in a blocked/idle state.
A master thread per app is listening on the socket (also blocked/idle).
A request comes in and the master thread wakes up and dispatches it to the pool.
An available thread reads the request, processes it and puts the socket in the
pool of active connections, then itself back to the pool.
Asyncronously a cleanup task closes sockets that are still open past their
timeout (The request thread doesn't block on this).
A typical one-time request from an HTTP client that isn't using socket pools or
session cookies but does use a authentication that requires a round trip (e.g.
digest),
does 2 requests sequentially.
Say a GET.
GET 1 [ returns with 401 unauthorized ]
? Fill in digest info
GET 2 [ processes data ]
At most the system will simultaneously process the max thread count (say 32).
This is different from the number of open connections or pending connections.
B) How its measured
Depending on how the measurement is done (point snapshot, averaging per sec,
cumulative ...) you will see different metrics.
Depending on the load of the system and other factors it may or may not be 'the
same thread' that handled both requests, the metrics
You don't mention which api or tool your using to measure the thread counts.
Assuming your r xdmp:server-status,
The metrics per host are "threads" (number of threads in the pool currently)
and "max-threads" the maximum allowed in the pool.
Since the threads are kept alive for a while after a request they may increase
to at least the number of simultaneous HTTP requests
Processed in the recent past. That doesn't mean they are all running at
that moment.
If you run requests sequentially very quickly you will likely see 2 threads
because the first request thread has completed
The request but not yet back in serviceable mode before your next request shows
up so a different thread is used.
On average only 1 thread is actually running per simultaneous request but there
is a small window that may start 2nd thread.
After that they both will wait a while for new requests.
You would observe the thread count returning to 1 after while of no activity if
your query is run on a different app server then what your are measuring.
Eg. Run
xdmp:server-status(xdmp:host(),xdmp:server("HealthCheck"))
will show threads=1
but
xdmp:server-status(xdmp:host(),xdmp:server())
will show atleast 2 probably 3.
From: general-boun...@developer.marklogic.com
[mailto:general-boun...@developer.marklogic.com] On Behalf Of
gnanaprakash.bodire...@cognizant.com
Sent: Friday, January 09, 2015 6:17 AM
To: general@developer.marklogic.com
Subject: [MarkLogic Dev General] MarkLogic Concurrent Threads/latency
Hi
I want to understand how threads in app servers work.
I believe for every request with authentication MarkLogic will show 2 threads.
But what I see is when we are doing performance testing, MarkLogic is showing
32 threads are being used per node (we have 3 nodes in a cluster) but active
thread (requests/updates) as 3-4.
What's the difference between Threads and requests/updates. I understand that
requests are GET and updates are updating any content (PUT/POST/internal update
in GET linked code), the main question is why thread count is more than sum of
requests and updates.
If threads are sockets being opened why they are not getting closed even when
the keep alive is just 5 seconds in configuration.
Can someone help me in understanding this and resolving the latency issue I am
facing in my performance testing.
Regards,
Gnanaprakash Bodireddy
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient(s), please reply to the sender and
destroy all copies of the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email,
and/or any action taken in reliance on the contents of this e-mail is strictly
prohibited and may be unlawful. Where permitted by applicable law, this e-mail
and other e-mail communications sent to and from Cognizant e-mail addresses may
be monitored.
_______________________________________________
General mailing list
General@developer.marklogic.com
http://developer.marklogic.com/mailman/listinfo/general
