Wednesday, July 25, 2018

Tuning WFA 4.2

My collegue José is working on one of the largest WFA installs I know of and he told me this after migrating from 4.0 to 4.2 :

After a migration from WFA 4.0 to a different server on WFA 4.2 we started to see slowness up to the point where the application was unusable.

The execution log was taking minutes to populate, and when it was populating for one user, the rest could do nothing, get timeout errors and messages about "server busy".

We saw that every time someone hit on the execution logs, the database was bringing the table to memory, and seems that happened every time, causing 140MB/s throughput and around 10k iops

Another observation was that the services were using ways less memory, even if we went from a 8GB system to a 16GB system.

After some troubleshooting, did the following:

Browse in "regedit" to 
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\NA_WFA_SRV\Parameters\Java

And change the “option” key with new values for XMS and XMX to :

Change the option in "my.ini":
Innodb_buffer_pool_size = 8M
Innodb_buffer_pool_size = 8192M

Restarted the services, and now seems like it keeps the tables in cache. 
The application is fast again and no more IO to disk.


I would recommend (if WFA becomes a big part of your automation) to give 4 cores and 16GB of ram.


Regarding WFA's limits.  It's know that perl scripts are way faster than PowerShell, remember that PowerShell has signed code that might check Revocation Lists (see previous posts on CRL).
The WFA planning phase is a single thread (to handle reservations properly), but once planned, it can run 100 workflows simultaneously (depending on the resources ofcourse).  The rest gets just queued.

No comments :

Post a Comment