On 03/12/2024 03:37, Owner wrote:
Hey Mark,
Thank you for the input. I believe that such a feature will be extremely
helpful as well, on top of the queue time.
1. I was thinking - if we want to accurately capture the time taken by the
Poller (only the poller, which excludes the time taken after accepting
connections.) in reading data, processing it and throwing it into the task
queue, would the timer begin when the the first read event for that socket
wrapper takes place, in the selector? Since that would be the first
instance that the poller actually starts processing that request.
It varies. For new connections timing should start as soon as the
connection is accepted. For kept-alive connections it would need to be
the first byte received.
- On this note, do you know if there's any way we can differentiate
requests at this stage, and "tag" them before they are inserted into the
task queue? We will require this tag to accurately measure the time the
request is first processed by the Poller, till it's inserted into the queue.
Tricky. The socket doesn't generally have visibility of what is
happening at the protocol level.
- Would capturing the time taken by the Poller only be sufficient as well?
Since an end-to-end metric might be better, it might be ideal to start
timing from the time the Acceptor accepts the connection. Since there is no
way to track that, I'm guessing the first bytes being written into the
socket buffer, and the poller thread first processing the socket buffer to
read from it might be sufficient?
I don't see why timing can't start on accept.
2. For the queue time code I mentioned above, do you foresee any
performance issues / implementation gaps?
The challenge will be getting the right information available in the
right place. Performance is always going to be a concern since this code
will execute on every request.
I haven't spend any time looking at possible implementations.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org