Dear David,
i would not recommend to use the accept times are a measure of
performance, since it measures the time between the accept of an
incoming connection until the time, when the request is added to the
queue, since for one "accept", there might be multiple requests added to
the queue (on HTTP persistent connections).
It is true, that this time contains for drivers with read-ahead
configured (standard case) the time for receiving the request from the
client. But note, that this time depends on the connection quality of
the client. A client on a remote location connected via smart phone will
lead to much worse values than a user on the local network. Increasing
the bandwidth to your Internet provider might not change this picture.
But note, that this high latency does not hit the server, since reading
is performed with async i/o. Similarly, largish post requests will
result in larger accept times.
The interpretation of the accepttime is not easy, and depends also on
the overall system architecture, e.g. whether or not NaviServer is
running behind a proxy server. See below for two different systems: the
first chart show the year statistics from a system running without a
reverse proxy in front of it, the second chart is from a system is
running behind nginx. The first system show high accept times (average
1.1 seconds), the second one shows low accept times (average 200 micro
seconds). For the first system, one sees rather growing accept times (on
the logarithmic scale), which says probably, that the number of clients
with persistent connections is growing. On the second system, one can
see a change in the accept time around mid January from typically below
100 microseconds (10^-4s) to the current value. Interestingly, at that
time, we fixed the spectre/meltdown vulnerabilities, and the kernel
latencies increased.
So, in short for some use cases, the accept-timings might be useful, but
typically, these values can't be changed by faster soft- or hardware. We
exclude the accept times often in our performance analysis.
If you are interested in the real user experience, i would recommend a
measurement tool like boomerang [1,2]. One lesson to learn from that is
that only a relatively small fraction of the perceived performance is
due direct server performance (in the example of openacs.org, total
server runtime is 36ms, while the performance is around 2 secs; you can
get from boomerang as well the "request time", which is the time after
the TCP connect has finished until the request is received at the server)
all the best
-g
[1] https://openacs.org/forums/message-view?message_id=5387444
[2] https://github.com/openacs/boomerang
yearly graph
On 3/5/18 5:31 PM, David Osborne wrote:
Hi,
One of our installations is appearing to randomly experience long
accept times.
While all other requests are flowing nicely, suddenly one request will
have an accept time of between 2-20 seconds (as measured in the access
log with logpartialtimes).
Our understanding is that this is the time it takes for the driver to
receive the entire request from the client, and long accept times can
be due to clients connecting with very low bandwidths.
However, we're not really seeing any correlation between slow times
and any particular clients or request type. Plus there doesn't seem to
be any correlation to CPU/network/disk load.
I was wondering if there are other factors apart from bandwidth we
should be looking at which could be affecting accept times?
Regards,
--
David
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
