Basic WebSphere Liberty Profile Tuning

I was in need of going beyond out of the box tuning for the WebSphere Liberty Profile recently.  I was working with a system that was front ending services hosted in Liberty.  We wanted to make sure that Liberty wasn't the bottleneck in the overall system.  Turns out that the tuning proved that Liberty wasn't an issue even with the out of the box tuning.  However, since the tuning isn't yet documented, I wanted to put out what I learned.  There will be more tuning information coming in a refresh to the InfoCenter, so I'll update this post with that link when that formal documentation exists. [EDIT]The infocenter now has tuning information - see this topic[/EDIT].  Here is what I tuned:

JVM Heap Sizing:

I won't advise you on heap size tuning as there is a wealth of information on JVM tuning that basically applies to WAS or Liberty and is mostly affected by your application memory needs. Of course, Liberty requires a lower server cost of memory footprint, but beyond that the tuning is similar. In order to do basic heap tuning, create a file in the same directory as the server called jvm.options with the following contents.

-Xms1024m
-Xmx1024m

Thread Pool Sizing:

Thread pool tuning is always interesting. It's easy to say that you should create roughly the same number of threads or slightly more than the number of server processor threads if the application has no I/O. Unfortunately, no application is void of I/O and therefore needs to wait sometimes. Therefore, you usually want to allocate 4 to 5 times the number of threads than can execute with no I/O. Based on this (assuming a server that has 16 cores), add the following to your server.xml. Of course this totally depends on the I/O your application does. I suggest tuning this to a lower value and do a performance run. If you can't saturate the application, tune it higher and repeat. If you set this value over the optimal value, it won't hurt you tremendously, but you will be more efficient if you get closer to the optimal value due to context/thread switching.

<executor name="LargeThreadPool" id="default" coreThreads="40" maxThreads="80" keepAlive="60s" stealPolicy="STRICT" rejectedWorkPolicy="CALLER_RUNS" />

HTTP Keep-Alive Tuning:

As my application was services based, I wanted the clients to be able to send multiple requests using HTTP Keep-Alive to keep latency down. Otherwise, without this tuning, the connection would close and I'd have to endure HTTP/TCP setup/teardown cost on every request which can be slow and burn up ephemeral ports on a load client. If you want to set the keep alives to be controlled by the client and more infinite from the server side, set the following option in server.xml (make sure this is under a httpEndpoint stanza):

<httpOptions maxKeepAliveRequests="-1" />

Monitoring:

I was pinged by an IBM'er trying to monitor the performance of Liberty. There is a good overview of the monitor feature you can add to a server to allow JMX based monitoring in the infocenter.

Updated 2012-08-09 - Added monitoring section.