Purpose

If you find performance problems in a BSP application, it's not easy to track down the reason of the issue.

This Wiki page shows a possible method how to find the reason of a performance issue.

Overview

From time to time, the question of application performance arises. Since it is also an inevitable question in the area of web applications, naturally BSP (Business Server Pages) also meets the unsettling question: how can be the performance checked?

Several Customer Messages also asked this question, along with: “Why is BSP application XY so slow?”, “I’ve written a program in BSP but it’s slow. Why?”

It’s an exceptional case that in this Wiki article I can answer all of these past questions, because the answers were all the same: in every case, BSP was NOT the reason/source for the delay. Of course, first it had to be proven that BSP is "innocent", but that took several hours/days to pinpoint the source of the problem – and the actual problem could had been found earlier, if the target of suspect wasn't BSP in the first place.

Basically, this Wiki could end right here, right now, saying: “BSP performance issue? No way, several years of practice has shown that it’s ALWAYS an application/hardware issue. Bye!” – instead, let’s take a deeper look: if the suspect of BSP slowness arises, how can be the source determined?

That one exception...

This isn’t that kind of exception that SAP_BASIS release XX truly had a performance error, implementing SAP Note XYZ will solve it – because there were none. The reason is simple: Business Server Pages is a framework, and it simply processes given and received information/data. As such, if the input is wrong, it will be handled quickly via other mechanisms. If the output is wrong (and usually this is the case), it needs to be tracked down. Before you take the next steps, you should inspect the only exception, when BSP is “forced” to be slow:

Let’s say, you have a really, really large table – and you want to display it. The brute force method is to simply display the entire thing: 20 or 30 columns, and several thousand lines. It’s possible that nearly 100 000 fields will be displayed.

BSP has a built-in function, called “paginator”, which can display the table in several pages – thus only showing a small part of the huge table at once. If you use this, the display will be quick and painless. However, if you don’t use the paginator, the display will be slow and painful. The reason? Too large data stream causes an issue, and the later processing (a JavaScript on the page determines the user-selected field by scanning through every row and column of the table) will be problematic.

Strictly said this is not a BSP error again. The collection of data is not a BSP task, and the processing of the table on the finished page is a JavaScript task. No BSP involved in both sides!

So, if you recognize this scenario (large table displayed slowly), the solution is: use paginators.

However, if this is not the case, read on…

The strategy

Relax soldier, the operation will be just a few steps:

- If an end user complains about slow reaction time, first it needs to be determined: which page is slow? The title of the page won’t be enough, and the called URL might be misleading. So, to find the problematic page, we’ll use an HTTP sniffer: HTTPWatch. (But other sniffers, e.g. Fiddler or Firebug can be used too.)

- After the source page has been identified, we can start a performance-trace then evaluate the results in transaction SE30. This will show which method is "guilty".

- Finally, let’s put a breakpoint in this method. Standard debugging will show the center of slowness.

Basically, that’s it! In the following I will show an example of a “slow” BSP program, and how the source of the issue can be found.

(Naturally, this is only a made-up example, but it will show how these steps can be used in practice.)

Example

Phase 1: HTTPWatch Trace

Let’s say an end user complains about a slow response time in his/her daily work. Of course we will need the exact program/site name, but the end user probably will answer the site’s title, and if the BSP application is used within a Portal environment, the generic Portal URL (e.g. mycompany.com/irj/portal) is insufficient.

Let’s solve this issue by installing the HTTPWatch tool (the free version can be downloaded from http://www.httpwatch.com ). After installation has finished, display the tool in the browser, and press the Record button.

Figure 1: After HTTPWatch has been installed, press Shift+F2 on your keyboard, or select Tools → HTTPWatch from the browser to display this application. Press the button to start capturing network traffic.

Recreate the steps which has shown delay-problems, and after they’re done, you can stop recording by pressing the “Stop” button.
Figure 2: After the steps have been recreated, press the button to prevent capturing any further network traffic.

A huge number of information can be read from the results, but in this case the time statistics are interesting to us, because we can see the most time has been spent at the page “zimportantcalc/calculation.htm” – exactly 10.264 seconds. (Told you it’s a made-up example!)

So, now we know where the symptom appears, but as expressed earlier: it does not necessarily mean that the reason is here too. For this reason, let’s head into…

Phase 2: SE30 (Performance) Trace

We need to find the exact code point where the delay happens, and this is something HTTPWatch can’t show. We need an SAP tool, and transaction SE30 is here to help us.

But first, we need to start the tracing in transaction SICF.

This transaction contains the services for several applications, and BSP applications can be found here too.
Figure 3: Entry page for transaction SICF. Here, Service Name “zimportantcalc” has been entered, because we want to see the details of this Service. Press F8 or the ("Execute") button to advance to the next screen.

In this example, our application is located under sap/bc/bsp/sap/zimportantcalc. After the service is selected, you can turn on through menu Edit → Runtime Analysis → Activate the performance tracing.

Figure 4: After F8 or ("Execute") has been pressed on the previous screen, this screen will be shown. In the menu, select Edit → Runtime Analysis → Activate for the performance trace.

Figure 5: The entry screen for the Runtime Analysis. Here you should enter which User should be traced (this results in less redundant information and easier evaluation of the resulting data).

Repeat the steps in the web browser which causes the issue, and after the delay-problem has been recreated, you can turn off performance tracing in transaction SICF by selecting the service again, and going through the menu Edit → Runtime Analysis → Deactivate.

Figure 6: Select menu Edit → Runtime Analysis → Deactivate after recreation is done.

Figure 7: Press button to stop tracing. If a specific user was traced, here the user can be given (otherwise it is not necessary to give a specific user).

Go to transaction SE30, and evaluate the tracing by selecting the relevant Performance Data File, and clicking .
Figure 8: Entry screen for transaction SE30. Notice that in “Performance Data File” the data file for application “zimportantcalc” is already selected - this is because this was the last tracing. If you can’t see the needed data file here (because e.g. a different tracing has been done last time, so a different trace file can be seen here), press button and select the needed file here.

In the following chart, you can see where the most time is being spent:
Figure 9: After previously pressing the button, this chart shows which part consumes the most time. In this case, it seems to be clearly an ABAP-coding issue. Probably the application code is wrong?

Press the ("Hit list") button to see a very detailed result of the traced events!
Figure 10: In this detailed list, the different calls are sorted by their time consumption. In this scenario, it can be seen that the most time is taken by Method CL_O2DDD420J0ID1GLXPEFLVCNQ7S9=>_ONLAYOUT.

Now we know which method takes very long to proceed. But what is this cryptic Method name? Did SAP create this to discourage customers to develop BSP applications, or only this simple example uses it for a strange reason?

When using BSP applications, during runtime BSP pages receive a generated class name, so it is not so easy to determine exactly which code is faulty (just like in this case). But this can be easily solved: just click with the cursor on the method’s line, then press button (“Display Source Code”).
Figure 11: After “Display Source Code” has been pressed, it can be seen that Application ZIMPORTANTCALC with Page “Calculation.htm” was hidden behind the previous cryptic Method name.

Now we can see in which page the issue truly occurs! All we need is the last step:

Phase 3: Truth Prevails

So, the only thing left is: go to transaction SE80, and place a breakpoint on the problematic method:
Figure 12: This is a simple, general debugging tool in transaction SE80: after selecting the relevant Application and Page within SE80's Repository Browser, a breakpoint has been placed.

Repeat the steps to recreate the delay in the web browser again, and this time the application will stop at the breakpoint. Simply go forward step-by-step, and eventually you will stumble upon the command which caused all the pain:
Figure 13: Problem is solved! In this easy example, the reason for the delay is shown on the picture: command WAIT UP TO 10 SECONDS.

In this simple case the reason for the delay was a WAIT UP TO 10 SECONDS command. This command will simply delay the program for a specified amount of time (here: 10 seconds). Naturally, in real life this could be a call to an application’s method, reading from database, etc.

It’s also worth to mention that if the sudden slowness seems to be random (so it doesn’t happen always on the same line of code), the reason could be e.g. a content provider error, database error, etc.

Conclusion

It’s hard to estimate how many hours of analysis have been wasted by blaming Business Server Pages for a slow performance. Had these steps been executed earlier, the source of the real issue would be found earlier.

Keep in mind these steps when you hunt down a possible bug. And if you decide to open a Customer Message for a problematic scenario which seems to be nearly irresolvable, be sure to execute this analysis, and provide the results.

At this point, the component of the problematic area should be known. However, if you are in doubt, chances of a faster solution via Customer Message will sky-rocket if you ask the relevant application-support first.

Happy hunting!

Page tree

Purpose

Overview

That one exception...

The strategy