Tuning eiPlatform Memory and CPU Usage
The default eiPlatform configuration is designed to work well in most typical installations. However, this default configuration may not be optimal when processing large documents or a large number of small documents.
The following list contains configuration changes that can be made to maximize performance and throughput.
Most of the listeners operate via polling, where at a set interval they will attempt to retrieve messages from whatever they are listening too. Polling cycle intervals should be set based on two things: how frequently you expect to have new messages to process, and how much of a strain processing each message will place on the system.
Many (although not all) of the listeners have a maximum Transactions setting. This is effectively a message limit, it ensures that in a given polling cycle only that many messages will be picked up and sent into the system via transactions, regardless of how many messages are actually available to process. This is another great way to control how much of a strain you place on the system in any given Route.
While processing a transaction, the message data is stored in an internal cache. These caches come in several types based on your needs, and can be configured in the eipServer.conf via the “com.pilotfish.eip.transact.defaultCache” property. Here is a quick summary again of the available types:
- memory – This is an in-memory cache that is always initialized at 1 MB and expands to larger sizes as-needed. It’s better if you’re primarily dealing with a few larger files rather than many smaller ones.
- segment – This is another in-memory cache, but it is initialized at a much, much tinier size and expands to larger sizes as-needed. It’s better if you’re primarily dealing with lots of smaller files, rather than a few large ones.
- file – This is a file-based cache. The data is not stored in-memory, but in a temporary file, for the duration of the transaction. While performance is obviously reduced due to the need for I/O, it trades the memory burden from being on the RAM to being on the disk.
Thread Pool Settings
All transactions going through the eiPlatform are passed between thread pools, which are configured in the eipServer.conf (or on a per-route basis if necessary).
Optimize Thread Pool Settings
Making the above change will help regardless, but you may want to continue to fine tune those settings. The basic rule is that the more threads that are available, the more messages that can be processed concurrently. However, if you have too many threads, because each thread gobbles up its own little piece of memory, you’ll end up with the same problem in a different way. So finding the sweet spot is key.
Increase eiPlatform Max Memory
In the eiPlatform Service.vmoptions file, the max memory setting defaults to 1 GB. This means that the eiPlatform will not use more than 1 GB of RAM regardless of how much RAM is available on the server.
You can modify the –Xmx property you’ll find in there to a larger amount of megabytes, let’s say 4 GB for now, but it can be whatever you want it to be. To do 4 GB, it would look like –Xmx4096m.