Socket management

Iguana works within a single process so if you have it configured so that the number of open sockets gets too large then you can run into problems. Firstly it can slow overall performance since the networking code in Iguana is having to multiplex between all these open socket connections. But what can really kill you is when you exceed the allowed limit of sockets for the process. This is defined by the operating system.

Some of the symptoms you may see are error messages with the words FD_SETSIZE=2048 reached.

There is some simple tuning that you can do which will make things work smoothly in this area. Take a look at the way you have your LLP listeners components are configured. The default for socket connections in the LLP Listener in Iguana 5.6.6 and earlier versions is to never timeout sockets – see the Connection timeout setting:

Now if you Connection Timeout to:

Then Iguana will close connections automatically that haven’t been active for 10 minutes. This stops badly behaved counterparties from having too many open socket connections into your Iguana instance. In Iguana 5.6.7 onwards we actually select this timeout behavior as the default.

Another area where sockets can give you grief is for HTTP(S) sockets.  HTTP supports persistent connections from counterparties which can result in sockets being used up they do not close these connections. To counteract this if you have a lot of HTTP(S) activity we recommend that you use at least Iguana 5.6.3 – in fact if you are using Iguana HTTPS you should definitely be on Iguana 5.6.5 or above because of the Heartbleed issue with OpenSSL – any customer using HTTPS should be ready to upgrade to patch releases because there are likely to be ongoing patches required for new versions of OpenSSL.

In Iguana 5.6.3 and above there is an environmental variable called IGUANA_WEB_SOCKET_IDLE_TIMEOUT_SECONDS which has a default value of 120 seconds.  You can set this variable as low as 1 second which might be needed if you have a very busy transactional environment.

That still may not be enough if you have crazy volumes of transactions.  Let’s say for instance you had 300,000 HTTPS transactions going through one Iguana instance. At this point it’s pushing the limit of what a single process can manage in terms of open sockets and so on.  So a technique that can used here is to divide into smaller silos by doing something like:

1. Leverage the libraries that come with the Channel Manager to take the same production channel and deploy it across multiple server instances.
2. Push the inbound traffic through a high speed web proxy like nginx and round robin the traffic against that Iguana cluster.

This is good design to scale out a very high volume installation with a lot of HTTPS transactions.