User Guide

JMX monitoring

By default rubris registers a number of MBeans with the default JMX server. It does not create its own MBean Server nor does rubris control the security for the JMX endpoint. This should be secured as per normal practice for the JVM.

The MBeans cover statistics for the HTTP polling, Websocket timings, connected clients, internal timing behaviours, rpc statistics and subscription details.

HTTP Stats

The Http MBean exposes:

  0-10:9
  1050-1060:1
  2010-2020:1
  3030-3040:1
  ...

As shown above we can see that the histogram has large deviations well above the expected 10ms range. This is due to the fact that the long polling nature of the http request is held on the server (for up to a maximum of 10s). Therefore we would not expect any timings to be above this value.

This histogram is present for other timings in the same format.

WS Stats

The WS MBeans expose

EngineIO Stats

The EngineIO stats are differentiated again by HTTP and WS processing.

The core proxy handler enables the maxDriftTime to be set/cleared.

The HTTP MBean exports

The WS MBean is a duplicate of the HTTP details but for data that passes along the WS pathway rather than the HTTP path.

Socket Acceptor

The acceptor MBean exports a histogram in 1ms segments detailing the time it takes to accept the TCP socket connections. This time is for a batch of socket which may be 1 or more.

Client data

The Client namespace MBeans provide 2 functions:

Server

The server MBean enables the viewing of the Config that the server was initialised with.

Module

The module namespace MBeans detail information regarding the internals of the server’s operation. As described in the config docs <../configuration/index.html#module> each module has its own threads that deal with processing incoming sockets, notifying and processing outbound events etc. the general behaviour of each one of these loops is in essence similar to a game loop where on each pass it processes all the pending channels, or incoming reads that have notified to have something to do.

The timings in the MBean are the beginning to end of that loop. So for example the GenericNotifier MBean (which is responsible for all the outbound writes) will show something like:

0-1: 3094
1-2:136
2-3:1
...

the above histogram shows us that the vast majority of these cycles took 1ms. The timings will vary according to how much work is involved in each loop. so processing 1000 sockets will show significantly longer times as the time is for each poll cycle for all the sockets combined. In saying that timings should be generally low and above 1 second is an indication that something is amiss.

Similarly, the reader MBean shows the time from the first socket to be read, the inbound path processing of the sockets and ends after the final socket read in that notification set has completed and the data processed. Again this makes the timing dependent upon the numbers of events.

These numbers are generally useful to identify issues in a coarse way, e.g when the calling read thread is being blocked or is is performing work directly in the application’s code when instead the inbound messages should be handed off immediately for asynchronous processing.

Also shown in these MBeans are:

The blocked write numbers should normally be 0 or low. A higher number indicates issues such as oversized outbound buffers (compared to the OS TCP write buffer), slow clients or large messages (e.g you will get a number of blocked writes when trying to push a 1Mb message into a 256k buffer)

Channel Details

The remaining MBeans cover the individual channels. 1 for each RPC channel and 1 for each subscription Channel.

The RPC MBeans show: * A histogram of the RPC timings (the amount of time for message handoff form the initial read) * inbound and outbound byte count

The Subscription MBean varies slightly on whether it is private or shared