Load testing JD Edwards–some load testing tips from the field?

I’ve said it before and I’ll say it again, load testing must be one of my favourite and rewarding consulting gigs.  I really like it, probably revealing a little too much about myself here.

I like constantly pursuing bottlenecks and trying to give clients confidence that the changes are going to make a difference and that they are pushing their hardware and software to the limit – getting the best bang for buck.

The age old question is – how hard do you push?

Here are a couple of things that I live by when load testing:

• choose everyday transactions – sales order entry, PO entry, address book find, launch a simple job.  Do not just hit the system with all of the slow and hard transactions, you are not going to test anything
• Do not go to the end of large grids
• know the type of transactions that you are performing, are they logic intensive or are they data intensive and understand their individual timings and more importantly their consistency.
• get your users waiting more than 3 seconds per interaction with the browser, you would be surprised when you see actually how hard your JDE is hit
• Include a mix of batch and interactive
• make sure that you count records before and after so that you know transactions are hitting the database
• make everything repeatable.  Add a PO, approve a PO, print a PO – so you do not run out of data
• dates should be variables
• Don’t start near the end of a month, you’ll have date problems and warning problems before you know it
• Use OATS – it’s great for JDE load testing
• get a specialist (like me) in to do the job.  It’s a tough gig to set this up and run it yourself.

But, back to the question, how many users?

Here are some stats that you may or may not believe.

For a site that has about 400 active JDE users a week approximately.

This is cookie based.

They’ve loaded 1.4 million pages and server over 37000 logins

Wait, that is cool, that means 37 pages per second – wait ERP analytics tells us this!

And we can see that the timeout is probably 30 minutes!

But, we can also tell the peak periods of usage.

A simple custom report can tell me pageviews per minute, at a peak of 117

and pageviews per hour, at a peak of 3405

This is really good data for load testing.

If we looked at this basically we’d want to load test 1394000 million pages and try and divide out a value for # days, 10 hours a day etc etc…

1394000/13x5 (weeks work days)/10 hours per date = 2144 an hour – but the peak is 3405 using data (1.5 times the estimate)

Taking this to another level 2144/60=35 pages a minute, which is more than 3 times less than the peak!

Load testing for this client could take many different forms, but if I’m loading more than 117 pages a minute – then we are net positive.

What am I testing you ask?  21 a second… or 1260 pages a minute!  so I’m actually load testing at 10 times their maximum load for the last 3 months.  I think that I can wind back the testing wait time and sit back and relax!