Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Statistics on

Thanks Simone (and sorry for the crappy subject, premature mail sending ;-) ).

Seems like it is #1807 I'm interested in,  description is a bit short in that discussion however but assume I would need to hook into

  • requestBeforeDispatch
  • requestAfterDispatch

and do my calculations to get some max, average, etc timings on the dispatching. Looking forward to a release were I can experiment with this.

Just out of curiosity, would the selector thread timings be possible to get in versions <= v9.3.x?

Regards
/Johan

On 2017-09-25 16:16, Simone Bordet wrote:

Hi,

On Mon, Sep 25, 2017 at 1:53 PM, Johan Piculell <johan@xxxxxxxxxxx> wrote:
Hi.
I played around a little with the StatisticsHandler and was hoping to get
some stats on requests waiting for a thread to process, i.e. how long time
the selector threads have to wait for an idle thread for processing.
Jetty, as of 9.4.x, does not have "dedicated" selector threads.
A thread does the NIO selection, Jetty dispatches another thread to
continue with NIO selection, then most of the time the original thread
just continues with socket read, HTTP parsing and eventually invoking
the application.

Therefore "how long a selector thread has to wait for an idle thread
to process the NIO event" is not applicable to current Jetty because
it's the same thread.

It seems to me like it is not possible to pull these stats, so two
questions; 1) am I missing something and/or have there been any plans to
introduce such statistics?
See https://github.com/eclipse/jetty.project/issues/1807.

You have to detail _exactly_ what is it that you are interested in.
If it's the time it takes for a request to be dispatched to an
application, then #1807 will give you that answer.
If you're interested in how long does it take for a generic job to be
executed by a thread, then that's entirely another measure that is not
covered by #1807, but is easily covered by an instrumented thread pool
(and its queue).



Back to the top