The engine database configuration can have a significant impact on engine performance as welll as the overall performace of ALBPM Enterprise.
Each process execution engine must perform database transactions to persist data when a PBL method is executed or when an instance proceeds to the next activity. Data persistence is necessary to ensure the state of a process instance can be recovered after engine failure.
In addition to vendor-specific database performance tuning, the following sections provide general guidelines on tuning the engine database.
The Maximum Pool Size parameter allows you to ensure the correct number of database connections are available. The Maximum Pool Size paramater specifies the maximum number of connections that the server can allocate to perform transactions against the server’s database. If for some reason the engine database needs more connections it will be able to increase the connection pool up to the number indicated in this field.
If more connections are needed, the requests are queued until the first transaction finishes, the connection is freed for another transaction in the queue to start. This parameter should reflect the number of concurrent interactive users. This is the determining factor. Make sure the database has that many client connections configured to be consumed by FuegoBPM. This is a combined value from the interactives thread + automatic execution threads that can be concurrently active. Do not define a huge value (i.e.: 400) for this parameter since this will create also contingency in the RDBMS used by the FuegoBPM Server.
It is preferable to wait for a connection to be released after a transaction is finished than generate a big concurrency of transaction in the target RDBMS. There must be a balance between how soon the transactions can be finished without generating a bottleneck and contingency in the database. This will also depend on the hardware where your RDBMS is deployed and the dimensioning of the RDBMS used by the FuegoBPM Server. Make sure that the database is configured so that there are enough sessions to handle the number of maximum connections that the engine database may use.
Make sure you have enough sessions. Check Oracles SESSIONS parameter. For no contingency, you should have a session for each Server connection that the FuegoBPM; Server may use for a transaction.
Make sure there are enough processes on the Oracle side. Check Oracles PROCESSES parameters. This parameter depends also on the values assigned to SESSIONS and TRANSACTIONS. For no contingency, you should have a process for each FuegoBPM Server FuegoBPM Web Console 150 connection that can be executing a transaction at the same time.
Make sure the Oracle memory is properly configured for the number of concurrent transactions to be executed by a FuegoBPM Server. The dimensioning of the memory in Oracle is related to the conguration of the SGA.FuegoBPM only uses from the SGA the following sections: BUFFER CACHE, LARGE POOL, SHARED POOL