Feature request: burst-mode network requests
Opened this issue · 2 comments
If InTrace is monitoring a remote application, it seems that a separate
network request is made for every trace event. Is that right? -- I haven't
looked closely enough at the code to see. If that is the case, I don't
think that kind of model will scale when medium-to-large amounts of load is applied.
Perhaps we could consider some kind of burst mode where trace events
collect in a queue and are sent to the GUI every X seconds?
CA Introscope, for instance, has a 15 second delay. I'd be happy with 5, but it should be configurable.
We should do some load testing to measure InTrace overhead.
- Deploy Java PetStore application
- Use "http://grinder.sourceforge.net/" to apply some load.
- Measure
- CPU/RAM consumption on PetStore server.
- Get from "The Grinder" Response time and throughput metrics
Compare results from the above test with and without InTrace with instrumentation.
We should have multiple Load tests with InTrace.
- instrumenting 50 classes
- instrumenting 100 classes
- instrumenting 200 classes
- instrumenting 400 classes
InTrace Agent supports two types of connection - Control and Trace. Each client makes a Control connection and can then request to open a Trace connection.
InTrace Agent maintains a single dedicated Trace TCP connection to each InTrace UI which has requested it. Trace events are dispatched locally to a dedicated thread which handles sending trace events down the trace TCP connection.
I just created a pull request to address this issue.
#40
Please close this issue if you apply the code.