Monday, 6 July 2020

Quantification of performance gains in JDE

I'm assisting a client move to a new database platform at the moment, and we are trying to work out if this has been a successful move or not.  Success has many measures, but performance is a critical measure.

If you are not going to spend 30K on performance testing (let's be honest, this is what it is going to cost), then how are you going to determine whether you have improved your user experience?

We were lucky enough to have ERPinsights installed in non production before this project kicked off, so we had about 40 days of performance history to compare against.  This means that we had 40 days history of EVERY batch job, and every page load.  Using this data with some intuitive reporting (cue me) and we are able to give the client some very string indications whether things have improved or not.

Interactive

 The move actually occurred on the 18th of June.  Can you see we definitely had some issues.  The server response time when from around .7 of a second (which is slow BTW) to over 2 seconds.  This is how long it was taking for the server to start to respond to the user request.  This does not include the download time or the page render time.  In my experience, this is a key indicator to server problems.

The team did some scrambling and found a pretty neat setting for VMWare and the implementation of this on the 22nd seemed to have done the trick.  The client is now getting better performance in non production than they ever were - 27% improvement based on all of the history and 11% on the previous best period.

These figures were based on over 223,000 page loads and the cumulative experience of 335 users.

Batch

The table below allows us to compare before the change to after the change, we can see rows processed and average runtime.  You'll see that the triangle (delta) in the final column is the change in average runtime between the periods specified.  Green arrow is good and red arrow is bad.  We can see from below that on average we are looking much better.


We can see any trending graphically too, looking at runtime, rows, number times run or waittime

385 jobs have been run in non-production environments in the last 9 days that were run also in the 9 days before that.  Of those jobs, 270 ran quicker in the last 9 days.  

Don't forget your package build

The full build is a good litmus test.  If you are moving database or platform, compare your full build times.  They should be around 2 hours.  Remember though, this is not an interactive performance benchmark, just a good thing to compare high traffic and database intensive activities in JDE.

 

No comments:

Extending JDE to generative AI