At a glance
- Client: a large American company whose core business is IT management tools, offering numerous solutions including monitoring systems
- The product being demonstrated: monitoring systems that track server storage volumes, disk usage and capacity metrics, follow key resources and forecast when capacity will run out
- The task: the client needed a test infrastructure that would fully and tangibly show what the monitoring systems can do - a product whose value only becomes visible when something is actually under strain
- The rig: a platform on several servers with different hardware and software configurations, running the testing system the client chose, with monitoring agents installed on every server
- The load: generated with Apache JMeter and increased until server resource usage and system response time grew critically
- The turn: at peak load, cloud servers were introduced - after which average response time decreased, on camera
- Deliverable: video, screenshots and descriptions showing the monitoring system's behaviour at different levels of demand on the test system - material the client will use in its advertising
The demo problem for a monitoring product
A monitoring system is difficult to sell in a slide. It watches storage volumes, disk usage and capacity metrics, tracks key resources and forecasts when they will run out - all of which is valuable and none of which is visible when the servers being watched are idle. A screenshot of a healthy dashboard proves nothing; the product's whole argument is what it tells you as conditions deteriorate.
So the client's requirement was not really "test our monitoring system". It was: build us a situation in which the product has something to say, and capture it. To do that the client needed a test infrastructure realistic enough that the graphs mean something, and controllable enough that the interesting moments happen on demand and can be recorded. That is what they came to PFLB for.
What was built
The team proposed a rig with 5 deliberate properties:
Average CPU load before extra capacity was added: 97%, into the red band.
Memory used before extra capacity was added: 76%.
Average CPU load after cloud servers joined the pool: 49% - a little over half of what it was.
Memory used after cloud servers joined the pool: 76%, unchanged - the constraint was CPU, not memory.
- Several servers with different hardware and software configurations, so the demo shows monitoring across a heterogeneous estate rather than a uniform one.
- The testing system chosen by the client running on the servers, with monitoring agents installed - the agent on each server is what hands out the data, and the demo covers servers with different operating systems.
- Load generated with Apache JMeter, so the demand on the system is deliberate and repeatable rather than incidental.
- A switch to a cloud server under peak load conditions, giving the demonstration a second act: not just "here is the problem" but "here is the response".
- Video recording of the monitoring system's performance and its reaction to load changes, because the reaction over time is the part that a static screenshot cannot carry.
During the project the servers were monitored while load was placed on the testing system. When a critical growth in server resource load and in system response time was recorded, cloud servers were introduced - and average response time decreased. That sequence, captured live, is the demonstration.
Results
- The client received video, screenshots and descriptions that tangibly demonstrate the monitoring system's capabilities under different levels of demand on the test system.
- The material shows monitoring across servers with different operating systems and configurations, via agents installed on each.
- It captures a full arc: resource load and response time growing critically, cloud capacity being added, and average response time coming back down.
- The customer will use these reports for advertising - the engagement's output is marketing evidence, not a test report.
Honest note on the numbers
This engagement is documented qualitatively. The published source records the rig, the method and the sequence of events, but no response times, resource thresholds, server counts or user volumes are stated - so none appear above. Where a case can be read for figures, we quote them; here there are none to quote, and inventing plausible ones would be worse than the gap.
Questions this engagement answers
How do you demonstrate a monitoring product convincingly?
By creating the conditions it exists for. Idle infrastructure makes monitoring look redundant, so the demo has to include real load, a real degradation, and a real intervention - here, JMeter driving the test system until resources spiked, then cloud servers being added.
Why generate load with a load testing tool for a marketing demo?
Because the demand has to be controllable and repeatable. Apache JMeter lets the interesting moment be scheduled, re-run and filmed, instead of waiting for production to misbehave.
Why several servers with different configurations?
Because a monitoring product's claim is coverage. A demo on one uniform server proves it can read one server; a demo across mixed hardware, mixed software and mixed operating systems, each with its own agent, proves the thing customers are actually buying.
What does a demo project like this hand over?
Not a verdict on the software, but assets: recorded video, screenshots and written descriptions tied to specific load conditions - reusable in the client's own marketing.
Need to show your product working, not just describe it?
Building the conditions under which software proves itself is the same discipline as load testing it - a rig that reflects real configurations, a load that can be dialled to the exact moment you want on camera, and monitoring that is watching when it happens.
