Thank you very much for that info Gustaf.
We'll have a look at whether we can adapt the ideas in boomerang to our
environment.
Yes we suspected the Accept timings might be outwith the control of the
server.
Am I right in thinking that Runtimes (if not using writer threads) are also
affected by network conditions since they include the time taken to deliver
content back to the client?
Thanks again,
--
David
On 5 March 2018 at 20:25, Gustaf Neumann <neum...@wu.ac.at> wrote:
> 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
>
>
> [image: yearly graph]
>
>
>
------------------------------------------------------------------------------
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
