Process and Thread

nGrinder uses processes and threads to simulate the number of vuser. For example, if you set up a test like following. Only one agent will be activated and 1 process will be invoked then this process will include 2 running threads. Eventually, at the same time, 2 running thread in the total test lifecyle will exist. What if you increase agent to 2, it will have 4 vusers in total.

If you put the virtual user count in Vuser per agent field,  then nGrinder will calculate the appropriate processes and threads count. For example if you put 100 in the field, it will turn to 99. It’s because 3 processes and 33 threads will be used. You can configure process-thread count calculation logic by configuring process_and_thread_policy.js. 

Processes more than 20 easily cause thrashing problem by HDD swapping in the agent side if your agent has less than 4GB memory. nGrinder agent run on JVM. It needs enough heap memory. If there are many number of processes, they would exceed the agent machine’s physical memory size. Please set it less than 20. If you increase the thread number more than 50, it might causes problem either. The threads belong to one process share the same heap. It’s obvious to see the OOM error if a lot of threads occupies the process memory.

You have to set process and thread count with care. If you have no idea on this, Just let the nGrinder calculate automatically.

NEWS!! we have some experiment how many vusers a agent can handle. 1000 vusers can be supported by a single 4GB memory equipped agent if each test doesn't use much memories. If you like to extend the vuser max value and try some experiment, please configure agent.max.vuser in system.conf.