Hi Alan,
Alan Williamson wrote:
> Following on from that thread, can we get a handle on how busy things
> are at the moment? What are the differences between these calls?
>
> st.getCurrentConnectionNumber()
> st.getCurrentThreadCountStats()
> st.getCountThreadsStats()
Yes, mainly, just do:
SelectorThread.enableMonitoring(). An example is here:
https://grizzly.dev.java.net/nonav/xref-test/com/sun/grizzly/http/SelectorThreadStats.html
Then you can get a lot of statistics by calling like the number of
current opened connections, the number of keep-alive connection, etc.
The objects to looks at are:
// Return information on current connections:
getKeepAliveStats();
// About current Thread state
getCountThreadsStats();
getCurrentThreadCountStats()
// About request/responses (like how many 200/500 etc.)
getGlobalRequestProcessor().getCount200() // How many sucessfull request
getGlobalRequestProcessor().getProcessingTime()
The documentation is so nice here I have to look myself at the code :-(
Some links that can helps:
[Request]
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/RequestInfo.html
[Threads/Pipeline]
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/PipelineStatistic.html
[Keep-Alive]
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/KeepAliveStats.html
[Aggregation]
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/RequestGroupInfo.html
Take a look :-)
A+
-- jeanfrancois
>
>
> Alan Williamson wrote:
>> thanks for that clarification Jeanfrancois, as it turns out, that
>> explanation fits with the fact that lighttpd (our frontend load
>> balancer) had run out of socket handles and was doing a lot of back
>> queuing and flooding our backends with connections.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>