Optimizing Iguana Performance

Getting the best performance out of Iguana is not rocket science, the tuning techniques follow similar principles used for databases etc. The good news is that a standard Iguana installation on standard equipment is already very fast (see Iguana is fast below). However as the number of channels you are running and the amount of messages that you are processing grows you will eventually need to address performance issues.

There are many performance related articles in the documentation (try searching for “performance”). This page gives an overview of performance topics, with links to more in-depth articles.

For more help please contact support at support@interfaceware.com.

Iguana is fast [top]

Iguana has the reputation of being the healthcare industry’s fastest integration engine. There are three main reasons for this: Iguana is developed in C++ for efficiency, it uses the Lua which the fastest scripting language available, and it has its own high-performance queuing/logging system.

Logs [top]

Iguana’s proprietary logging system is designed for high performance and fault tolerance. To get the best out of it there are few simple rules: Put the logs on the fastest disk available, for the highest performance use a dedicated disk for the logs, keep the log size relatively small, perform log backups and purges at the quietest time of day, also disabling synchronous disk writes will increase performance (but with increased risk of losing data).

Note: What are synchronous disk writes? This simply means that Iguana will write each log entry to disk immediately. If you disable synchronous disk writes the operating system caches disk writes, which means that if the machine crashes then data may be lost.

Getting the best of both worlds with synchronous disk writes. Some high end disk systems actually cache disk writes in RAM for speed, and then write them to disk later. To get around the possibility of losing data the RAM is battery backed and will be written to disk as part of the disk boot sequence after an outage.

Web Services [top]

We have found that the biggest overhead associated with web services is opening and closing connections, the solution is to always use persistent connections.This requires that the server at the other end at the other end also allows persistent connections. Using persistent connections will approximately double the message throughput.

What can I do if the server at the other end does not allow persistent connections? The solution is to send messages in batches, see Getting high message throughput with REST. Batching messages can be several times faster than persistent connections (with single messages). However you have the additional complexity of the batching/unbatching process.

Sizing/Tuning an Iguana Server [top]

No two Iguana installations are exactly alike, so to get the best performance so you will need to do some measurements. The trick is to estimate message volumes and measure things like disk, cpu and network usage with simulated loads. With large Iguana systems you can then start dividing channels up between server instances (about 50 channels per instance is a good rule of thumb). Too many open sockets can cause performance issues, tweaking the “Connection timeout” setting in the LLP Listener component can be used to control this.

Tuning the code/application [top]

Because all interfaces are different there are no cut and dried tuning solutions. Basically you need to identify the bottlenecks, then figure out how to make them go faster.

Here are a few helpful tuning techniques. Use the os.clock() function to identify the slowest part(s) of the code, if you need more information you can use a profiler like “pepperfish”. Use pipelining (or batching) if you have high message throughput, this can dramatically speed up writing to databases (by reducing disk writes and network overhead), and it is also useful for web services (as it reduces connection overheads). If you are writing output to disk files be sure to archive old output files (either delete or move older files), to reduce operating system overheads. There are many other tuning possibilities, we are always here to help.

Please feel free to contact support at support@interfaceware.com if you need further help with tuning your interfaces.

Editor performance tips [top]

Sometimes code can run slowly in the script editor, which makes for a frustrating development process. Here are some tips to speed it up! Identifying a slow section of code: Use the os.clock() function to see how long a piece of code takes to run. Use iguana.isTest() and iguana.setTimeout() to speed up code execution: Use iguana.isTest() to run a faster “test” version of the code (say processing 10 messages in a batch instead of 10,000), use iguana.setTimeout() to set a shorter execution timeout than the five minute default (perhaps 15 seconds),  so when you write an infinite loop you don’t need to wait so long. Pipeline your components and use sample data: For example if your channel takes three seconds to load data from a web service, you simply load and queue the data in From HTTPS component, then process the the data in the Filter (or To Translator) component using sample data to eliminate the three second delay.