Threading

You can configure the number of client threads that Liberator uses to improve its performance. For example, when Liberator needs to handle a high number of user connections, increasing the number of client threads can improve performance. But you should take into account the number of DataSource threads being used, and the number of CPUs on the machine running the Liberator, since you’re likely to get the best performance when there’s a single thread running on each CPU.

Liberator uses threads to process the communication with its DataSource peers. The default setting is for it to use one thread for each peer connection, but you can also configure how Liberator allocates threads to its DataSource peers. For example, you could configure more than one connection to a each DataSource peer, which can improve performance by utilising multiple DataSource threads for each peer.

Alternatively, you can define named DataSource threads and then allocate the same named thread to a set of DataSource peers, so they all share it . This reduces the number of threads used to handle the peer connections. This can be useful if there is one peer handling lots of data, and a number of other peers handling a low volume of data. You can group the low-volume peers onto one thread, allowing the high volume peer to have a dedicated thread.

Once again, you should also take into account the number of client threads, and the number of CPUs and cores, on the machine running the Liberator - just adding more and more threads isn’t guaranteed to improve performance.

See also: