More and more companies have web applications connecting to SAP to pull information and present to users – or the other way around; web applications that update information in SAP.
In fact, more and more companies have more and more web applications, and more and more companies find it difficult to understand, whether they are actually being used and if so, how they are performing.
Checking Web Stats with DevOps for SAP
This is why we added these data to DevOps, because understanding web apps and their usage is very much of interest and importance to the SAP team, since many web programmers have a tendency to call the SAP stack without really thinking about SAP performance implications. To them, SAP is a black box that either provides or consumes data. But imagine you have a mobile app which has reached a maturity that triggers mass rollouts going from a few hundred to several thousand users, which connect regularly to SAP for every query they perform and this query is not optimised? In that case, SAP performance will suffer greatly. Not just for this application but for all other web applications now waiting longer to be able to get their data from your SAP backend.
The graph above is from Gekkobrain DevOps for SAP, where we have traced a specific web service. It shows that on March 11 there were 299 unique people using the web service with a total number of executions of 25,670.
First fun fact: Do you know how many people actually use the various web applications in your company?
To the right, we have sorted the users by Relative Runtime Index and clicked on the second user (you can see, his initials are bold). This means that his details now show up on the top graph along with the average numbers. As you know, we are no fans of averages in Gekkobrain, because an average could mean that 50% of your users are very unhappy and another 50% are very happy. We always make room for a granular approach, so you can drill down to specific users or user groups.
One SAP user has 30 times slower response
And so, what do we learn from looking at this particular user?
Well one obvious fact that stands out is that this user’s average runtime is peaking at 30 seconds and otherwise lies consistently above 10 seconds whereas the average runtime for the majority of users is around 1 second. Again, these too are averages and so further analysis will no doubt be interesting. DevOps will fire up its intelligent algorithm and suggest setting up a trace to figure out, what this user is actually doing that causes response times to be so bad. It might not even be the user but a configuration missing from his profile.
Second fun fact: Do you know, if specific users or user groups have a different usage pattern or unsatisfactory response times? DevOps uses statistical algorithms to calculate if clusters of users experience a similar performance degradation or if the webservice runtime seems to rely more on the amount of data being fetched.
Third fun fact: Do you decide on a web applications succes based on users or user satisfaction? If so, DevOps can measure it for you, so you can talk at an informed level with the people, who developed your web application.
We can also learn from these graphs that memory doesn’t seem to be terribly affected by the many concurrent users (30,000 requests a day), but runtime goes up. The 1 second average is acceptable, but there may be many users like this, who sees a dramatic degradation and others who are not affected.
But it also tells us that it might be worth while to look into the custom code behind this service, since certain calls or usage patterns causes runtime to spike. DevOps will look into the code for you and do the troubleshooting and root cause analysis, since the issue might be caused somewhere else in the call stack.
And there’s a fourth fun fact: How much time do you spend on troubleshooting and conducting root-cause analysis? How quickly can you do that by eliminating wrong assumptions, and can you spot problems before they register as broken scenarios? Gekkobrain DevOps for SAP will save you thousands of hours on this a year. And that’s guaranteed.