This chapter contains some tricks you may use to optimize the performance of your LIXA installation.
On the LIXA state server side, there are basically 3 elements you can tune in your installation: state file disk assignment, number of server threads, min and max elapsed synchronization time.
As explained in the section called “Configuring the server” every manager inside the LIXA state server uses a specific path for its status files. If you specified path associated to independent disks, you should obtain the best I/O performance for the LIXA state server.
Following the “just work” concept the default
configuration specifies a path like
/opt/lixa/var/...
but you should change it if your system had indipendent disks.
The LIXA state server is a multi-threaded process with one network listener and many “managers”; every manager runs in a dedicated thread. Choosing the optimal number of threads is not an easy task: following the “just work” concept the default configuration specifies 3 threads, but your own installation could necessitate a quite different value for optimal performances (in the following paragraphs you could pick-up some information).
Starting with version 0.7.2 you can configure two parameters:
min_elapsed_sync_time and
max_elapsed_sync_time.
In the previous versions these parameters was implicitly set to 0.
Setting them to “0” will dramatically reduce the probability a synchronization operation can be shared by two or more client sessions (LIXA transaction managers). Setting them to a value greater than zero will increase the likelihood a synchronization operation batches a lot of requests.
The higher the value of these parameters, the higher the chance you will have to perform manual recovery in the case of a server crash (manual recovery is explained in the section called “Manual (cold) recovery”).
Do not use too high values: you will increase the likelihood of a long and tiring manual recovery phase after a server crash without extra performance benefits.