Performance, point of failures

Today’s post is really about performance and more importantly how to ensure that you do not reach a point where your Murex implementation fails. I’m going to mostly focus on Application server, so you don’t need to read it all if you’re not interested!

You can have multiple cause for a slower (or badly) Murex installation. I will share my experience and hopefully you’ll know what to look for.

CPU

CPU is usually the one that will give you less problems especially if you followed Murex recommendations. You might run into CPU related problems if you multiply environments running on the same machine and running heavy CPU bound jobs: reports, simulations for instance. But in production, the only times I’ve seen performance degradation due to CPU were due to aging hardware and an increased bank activity.

Memory

Memory on Unix is quite cheap and it is rare to run out of it. The problem is that as soon as Unix/Linux/DOS (I’m kidding for the last one) runs out of memory, it starts swapping (using hard disk space to temporary storing memory content). It slows down quite a fair bit the processes. But Murex processes do not consume much memory server wise, so except if you start spamming lots and lots of processes with heavy memory usage (large viewers, simulations), again another area that should be fine.

Disk space

This one is most often the culprit. Services starting to fail, not starting, etc… Very likely the server has run out of disk space. It could be log files being too detailed, database traces turned on for all sessions causing a large amount of files to be generated. Core files if not sent to another segment also will cause massive disk usage.

It is very easy to correct and your system admin will monitor usually that one closely. But I don’t know how many times we ran out of disk space due to log files/traces taking too much space.

Network

Normally this one is not so much an issue in terms of hardware. Just accept that if you’re far from the server, your ping time will increase leading to a not so smooth experience especially in screens such as Mxmlexchange.

But firewalls between clients and servers (or in between servers) can lead to slowness, issues which unfortunately are not so easy to track. Had a fair share of these issues and I start to get a nervous reaction whenever someone mentions firewall around each server!

 

Alright, I hope this post would have help some of you. In a general manner, performance issues are rare especially when you keep the 4 points above in checks.