We have a lot of clients going live at the moment. This is with new databases, new clouds, new hardware, new tools releases. Everyone gets a little nervous before the go-live, and I think rightfully so. The projects are getting leaner and therefore the load testing needs to get leaner to match.
I'm going to cover off, what I think is the leanest and meanest JDE specific load testing that can be done:
- interactive historical comparison
- batch historical comparison
- synthetic load test
Interactive historical allows you to compare the page load times in your current production environment and compare those with your new environment. You know that we use ERP Insights to provide us with the baseline and also the results from all of the activity that has been done as part of the UAT / testing.
Generally I look at information like the above, put that into excel and compare the load times over the environments. Very quickly you'll see if you have problem applications, but also tell you overall how things are going. This information is constantly updated, so you can react quickly after a go-live.
Data like page load time, server response time and page download time are all critical in forming a complete picture of exactly where the performance challenges might be. You can see from above that all of these are measured - which can include location of browser!
I'd look at the top 20 applications that are slower and see if there are some themes.
Batch historical comparison
fusion5 have spent a lot of time writing detailed statistical analysis tools over the WSJ tables. We have an agent that sits on premise and uploads your WSJ history to the cloud. With this information, we can provide immediate feedback on batch performance too. Once again, for the purposes of an upgrade - we tend to compare the average performance of all batch jobs in production against the new environments. Ensure that you have run all of the jobs in the scheduler (or have an active scheduler) so that you get a quick view of average runtime of important jobs.
I like to look at those that are slower and faster, to ensure that the testing is solid (top 20 of each).
Very quickly you can see if yours jobs are selecting the correct data, running enough times and also how long they run on average.
Synthetic load test
This is really important to ensure that all of your configuration files, database connections, load balancers etc are configured correctly for production. It's important to look at your historical usage to know what load testing you should actually run.
Simple synthetic load testing will tell you any thresholds that you've not done correctly. users per JVM and JDBj connections are a classic problem area!
Getting some speedy results from the above [and successful testing] will make you feel pretty confident walking into your next go live.
Summary
An engagement like this takes less than 1 week and can provide you with some really good insights into how JDE is performing and give you confidence going into your new environment. you should get a solid baseline for JDE performance which you can continue to measure against moving forward.
No comments:
Post a Comment