Murex performance – is the system slow?

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

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.

5 thoughts on “Murex performance – is the system slow?”

  1. Sorry for the delay in posting that one, guys. Had quite busy days and when I was facing the keyboard, my eyes were shutting down!

  2. Could you please lay down the probability and possibility and previously experienced performance issues in Murex applications and how were they resolved.


    1. Hi Jay,

      That’s actually a very broad question and I would say that most of the time, once a problem has been found and solved, it does not reappear again. As I’ve put it previously, you have performance and performance. Performance from a subjective point of view is actually very hard to address as it is a pure gut feeling and I would say that with a client/server architecture, you always have that lag time between the time you click and something happens.
      The good thing about that subjective performance, it is usually not critical.

      The actual performance: we’re a volume business and need to be able to book 5,000 trades per hour (or whatever frequency). This is hard facts and Murex has been tailored to be able to adapt and deliver on such timings. Obviously hardware is essential as if you want to compute full risk exposure on a highly complex portfolio, you obviously will need more CPU/GPU power to able to churn through the calculations. As part of every Murex project there are usually clear requirements set: EOD need to be completed by 1 am, this report should be live and full recalc should take < 10s, 5 minutes, etc... And Murex will size the hardware based on requirements and database content. Also some modules or specific hardware might be required: Livebook for example for instant on simulation (live reports) regardless the size of the simulation, GPU grid for highly complex exotics, etc... If you do have some performance issues: either something was set/configured incorrectly, there is a bug (and it will be fixed) or the hardware is under-powered. I would say that if the requirements were clear from the start, Murex will test and ensure that the solution passes the said requirements before going live. If something changes in Production (e.g. new payoff hard to price), and you are then faced with an issue endangering the said timings, then Murex will help work through them. If the issue is about a slow deal for EOD reval, you will probably have to simplify it for a while or exclude it from EOD. If the issue is about trades being processed too slowly (back to your example of 5,000 trades per hour), Murex will look into it within hours and come back with a solution (I doubt it would happen out of the blue but still, the turnaround would be very fast) I hope that answers your questions!

  3. Is there a possibility to create a new UDF in Murex and not Do ADM , is there a work aroud for ADM to be done ?

    1. No, it’s not possible. As soon as you create the UDF, sessions will expect to find the field in the DB, so you will get error messages.
      But the ADM you run is the one from the CONFIG menu, it takes just seconds to run. And it is usually a good idea to do UDF creation outside main working hours to avoid any error for people (or processes) running sessions.

Comments are closed.