nGrinder is a application for running test scripts written in jython(python running on JVM) across a number of machines. It's internal engine is based on Grinder. nGrinder wraps Grinder's console and agent with a controller and agent, respectively, and extends several features to enable multiple concurrent tests.
nGrinder consists of two major components.
- Provides web interface for performance testing.
- Coordinates test processes.
- Collates and displays test statistics.
- Let user create and modify script .
- Runs processes and threads that put loads on target machines when running in agent mode.
- Monitors target system performance (e.g.: CPU/memory) when running in monitor mode
When agents are started, they attempt to connect to a controller. They then are attached in AgentControllerServer component. AgentControllerServer(Which is like an agent pool) manages the current agent pool. Whenever a user starts a performance test, a new console that coordinates agents is created, and the required number of agents is handed over from AgentControllerServer. The console (named SingleConsole to differentiate it from Console in Grinder) sends the test script and test resources to multiple assigned agents and starts to control the test flow until the test is over. After the test is finished, the used agents are returned to AgentControllerServer to be used in the other tests later. SingleConsole is returned to ConsoleManager as well.
The biggest difference between nGrinder and Grinder is that nGrinder keeps multiple console instances and agents in the controller. Each console is independent from the others, and all can run concurrently. Many agents can be attached in advance, and can be assigned whenever they are requested. Unlike grinder, nGrinder is developed to maximize utilization for agents machines.
Well-known load test tools such as "Performance Center" have a test reservation feature to guarantee agent availability when a user starts a test. But the reservation approach causes an agent utilization problem. We observed that people tend to reserve agents as a precaution even while they are actually not testing. In our experience, the average agent CPU utilization is less than 10% as a result.
For this reason, instead of reservation, nGrinder enables multiple test and dynamic agent allocation so that agents are dynamically assigned to tests only when a real test is performed. This makes nGrinder a unique solution among all competitors. With a relatively small number of agents, multiple users can run multiple tests concurrently. The number of possible concurrent tests depends on the number of free agents.