Channel already keeps some rudimentary statistics about class loading (classLoadingCount and so on), which can give insight into slow initial builds. But there are many cases where we suspect that a performance or reliability problem is ultimately due to excessive traffic on the channel, yet cannot prove this except via the crude tool of a network traffic analyzer, and have no visibility into which features (plugins) are responsible and whether the traffic is really necessary.
Propose that we add some more statistics (counts, mean, median, standard deviation) maintained per Channel for each of the three types of Request/Response.
- For ProxyInputStream/ProxyOutputStream, record number of pipes opened and closed in each direction, and bytes sent on them. Ideally we would like to get some information about what code opened the stream, though I am not sure how to aggregate this well, since stack traces are too variable.
- For RPCRequest, record the implementation class name of the proxied object, perhaps the method name/signature being called, the number of calls, their duration, the byte size of the request, the byte size of the response.
- For UserRequest, record the implementation class name of the Callable (or delegate of a FileCallableWrapper), number of calls, duration, byte sizes of request and response.
These statistics could be reported in various places:
- Slave system information page.
- support-core bundles. (Of course aggregate data across channels should be recorded, so it is still available after slave disconnections.)
- metrics data.
Originally reported by 
jglick, imported from: Request/response statistics
- assignee: jglick
- status: Resolved
- priority: Major
- component(s): core, remoting
- label(s): diagnostics, performance, remoting
- resolution: Fixed
- resolved: 2018-02-17T09:38:25+00:00
- votes: 2
- watchers: 4
- imported: 2025-11-24
Raw content of original issue
Channel already keeps some rudimentary statistics about class loading (classLoadingCount and so on), which can give insight into slow initial builds. But there are many cases where we suspect that a performance or reliability problem is ultimately due to excessive traffic on the channel, yet cannot prove this except via the crude tool of a network traffic analyzer, and have no visibility into which features (plugins) are responsible and whether the traffic is really necessary.
Propose that we add some more statistics (counts, mean, median, standard deviation) maintained per Channel for each of the three types of Request/Response.
- For ProxyInputStream/ProxyOutputStream, record number of pipes opened and closed in each direction, and bytes sent on them. Ideally we would like to get some information about what code opened the stream, though I am not sure how to aggregate this well, since stack traces are too variable.
- For RPCRequest, record the implementation class name of the proxied object, perhaps the method name/signature being called, the number of calls, their duration, the byte size of the request, the byte size of the response.
- For UserRequest, record the implementation class name of the Callable (or delegate of a FileCallableWrapper), number of calls, duration, byte sizes of request and response.
These statistics could be reported in various places:
- Slave system information page.
- support-core bundles. (Of course aggregate data across channels should be recorded, so it is still available after slave disconnections.)
- metrics data.
Channel already keeps some rudimentary statistics about class loading (classLoadingCount and so on), which can give insight into slow initial builds. But there are many cases where we suspect that a performance or reliability problem is ultimately due to excessive traffic on the channel, yet cannot prove this except via the crude tool of a network traffic analyzer, and have no visibility into which features (plugins) are responsible and whether the traffic is really necessary.
Propose that we add some more statistics (counts, mean, median, standard deviation) maintained per Channel for each of the three types of Request/Response.
These statistics could be reported in various places:
Originally reported by
jglick, imported from: Request/response statistics
Raw content of original issue
These statistics could be reported in various places: