GridSAM jobs are executed concurrently. Each job will go through a pipeline of stages (e.g. validation staging in, submission, monitoring, staging out, clean-up). The individual stages are scheduled among a pool of threads managed by the Quartz sub-component.
The main parameter in tuning the GridSAM performance is the number of concurrent stages that can be run at the same time. The default is 50 threads in the pool, although you can modify this value according to the capability of the execution host and the typical usage of the GridSAM server.
In the jobmanager.xml, a contribution to gridsam.SchedulerConfig can be added to override the org.quartz.threadPool.threadCount property used by Quartz.
<?xml version="1.0" encoding="UTF-8"?>
<module ...>
<.../>
<!-- add this contribution -->
<contribution configuration-id="gridsam.SchedulerConfig">
<!-- a low prefernce value will ensure this contribution will override the other -->
<Properties preference="1">
# number of concurrent thread. Higher the number, higher the concurrency, more context switching in the VM
org.quartz.threadPool.threadCount = 100
# priority of the threads in the pool. Higher the number, the more time would be spent by those threads, however
# might slow down other essential threads.
org.quartz.threadPool.threadPriority = 7
</Properties>
</contribution>
<.../>
</module>To ease the load on the GridSAM host, the database can be distributed on a separate host dedicated for database access. This is preferrably a host with fast disk access and network latency between the GridSAM host and the database host is small. Please consult the Persistence and Recovery section on how this can be done.