Tag Archives: performance

Tips

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.

Jobs

Murex performance – is the system slow?

5 Comments

Murex performance: Is my system slow or is it just me? When you present the system to new users, it is a question you often hear.

There are many answers which can come up:
– Yes
– No
– Maybe
– Server is a little small
Etc…

But the only good answer is: “It’s all relative!”.  Indeed, what do you call slow or fast mostly depends on the user.
For instance, if opening a trade ticket takes 3s, is that slow? is that fast? Agreed, if it takes 2 minutes, it is slow!

So the problem with performance is that there is a big amount of subjectivity. But I don’t want to pretend or even try to do psychology and check what the human mind considers slow or fast. On the contrary, I’d like to take precise examples of what users frequently report:

– Actual session start. Since the new GUI, login, password, group are almost instant, but the actual session start when you enter a menu usually feels slow
– Opening details: bonds, trades, counterparts, etc…
– The feeling that the system is sometimes a bit sticky, where actions take 1s or so when you expect them to be instant
– Simulation loading
– Accounting generation
– Saving trades

There are, in my opinion, 2 types of Murex performance issues: the user experience type and the structural ones. One could argue that they’re both the same but let me explain:

The UX ones are the ones which 1s or 2, for which timing is hard or imprecise. In the list above, I’m referring to opening details, stickyness. This is usually this type of performance which is ignored as 1s to open a trade or .1s does not seem like a big change to the user. But what the user does not always understand is that when you press space bar to open a deal, lots and lots of things are happening in Murex: the trade number is sent from the client to the application server. And then the application server is sending DB requests to get all information. It is not one single request, we’re closer to hundreds than few ones: get trade header, get trade body, get contract details, get additional flows, check access rights. If we assume that the communication between the DB and the application is 3ms, 100 requests bring that to .3s, add the CPU time (to decide if the trade is part of a package, requires to open other tables), add actual request time from the DB and then sending all the information back to the client. And here you go 1s, 2s are very easily reached.

So the User Experience performance issues are also structural and there’s not much to do in terms of code optimization. (well, at least not in my non PAC-brain).

The actual structural ones, the ones you expect to be slow are basically like the above compounded many times, factored with extra calculation for risk. The good thing is that when you get to that level, you can usually find optimizations on the DB side when not on the code side to improve speed and loading/processing more information at once. Usually when you can contact support for Murex performance, people expect to help on this kind of issues.

So back to our original question: is the system slow? It is indeed relative. There are implementation of Murex where the system is lightning fast. But everything has been optimized with that objective. To get your ping times from 1ms to .1ms is no small feat, to have a large DB and very fast requests require massive and optimized DB power, etc… So it can be done and has been done, but people tend to be cost sensitive, so doubling (well, I suspect far more than doubling) your hardware/maintenance budget so that a trade does open in .1s instead of 1s does not really make sense.

And Murex also works hard in terms of improving the user experience where they can: Livebook is a great example. Livebook means that data is churned all day long by processes so that when you enter Livebook in place of simulation, you don’t wait 5-10 minutes but some seconds to have the information; screenset is another great example, defining screensets lets you have all the sessions you need opened in one go rather than starting them one by one.

To conclude, Murex performance is addressed where Murex can do something or think of something innovative. But there are some limits due to hardware that are next to impossible to improve from a Murex point of view. So Is the system slow? No, Murex worked and is working hard on it but in the end, it all depends on your implementation and how fast you want (can afford) it to be.