Tag: Performance

SAP Netweaver gateway FIORI system performance

SAP netweaver gateway is used to host FIORI apps. Attention must be paid to the generic system performance of the system to avoid FIORI users to complain about performance.

Regular clean up jobs

Run program /IWFND/R_SM_CLEANUP in batch to clean up the application log. See note 2499354 – Report /IWFND/R_SM_CLEANUP. You can run with clean up scenario * for all, or select a specific scenario:

/IWFND/CLEANUP_APPSLOG will clean up the application log.

/IWFND/SUPPORT_UTILITIES will clean up support utilities.

See more on periodic tasks on help.sap.com.

Cache settings

Metadata cache settings

In customizing go to this path:

Setting should look like following in a productive system:

In a development system you should de-activate this cache.

HTTP/2 usage

Check if you have enabled HTTP/2 already. If not, activate it. See this blog.

Log level settings

In a productive system you can reduce data footprint and improve performance by reducing the log level settings. Only in case of issues, you can increase the log levels again.

To avoid excessive SLG1 logging of type “MESSAGE_TEXT”, make sure to apply solution from OSS note 3247600 – Fiori: /IWFND/MED170 – No service found for namespace ‘/IWBEP/’, name ‘MESSAGE_TEXT’, version ‘0001’.

Gateway error log

Go to transaction /n/IWFND/ERROR_LOG. Now select menu Error Log/Global Configuration. Now the configuration opens:

Set the Error log level in production to Secure. And check the days to realistic dates (settings above in the screen shot are per SAP advice).

Backend error log

Go to transaction /n/IWBEP/ERROR_LOG. Now select menu Error Log/Global Configuration. Now the configuration opens:

Set the Error log level in production to Secure. And check the days to realistic dates (settings above in the screen shot are per SAP advice).

Metering

Make sure you don’t keep all metering data too long. You can aggregate and delete it. See this blog.

Check search settings

Check your FIORI search settings. The setup of search is described in this blog and is very powerful. But search might not be needed at all, or most users want only to search for apps:

See note 2871580 – SAP Fiori Launchpad Settings: new Parameters for Enterprise Search for the settings to optimize, and SAP blog on explanation of the settings.

See note 2885249 – How to disable Enterprise Search in Fiori Launchpad to disable the enterprise search part.

See note 2051156 – Deactivation of search in SAP Fiori launchpad for deactivation.

Amount of tiles assigned to the user

The amount of tiles assigned to a user has a big impact on performance. Try to reduce the amount of tiles assigned to the user as minimal as possible.

See OSS notes 2829773 – Fiori Launchpad performance with a large volume of Tiles and 2421371 – Understanding Launchpad performance Issues.

Tables that are growing

Specific notes and solutions for tables that are growing fast in a netweaver gateway system:

Sizing

This should be simple one, but it isn’t. Sizing of Netweaver Gateway should not be done based on day or week average. Determine your peak times. And at those peak times check the CPU and memory load. If you take averages that include weekend and night, then system sizing might be totally fine. But to avoid complaints, you must be able to handle the peak load.

Full checklist

SAP has a checklist called “SAP Fiori launchpad best practice verification checklist”. Follow this link for the document.

Good other blog with checklist: follow this link.

ST07 Application monitor

The ST07 application monitor tool can help you in analysis of your system for performance and usability. It gives an overview of how many users are using which functional part of your SAP system.

Questions that will be answered in this blog are:

  • How to run the ST07 application monitor?

Application monitor

If you start ST07 you reach the application monitor start screen:

Here you can see how many users are defined and actually logging on across the modules. Basis is very high usually since this includes SMEN which is the start menu. The Other category is for Z transaction codes and/or addon software.

By double clicking on any line you can inspect the lower application levels.

DB access analysis

From the main screen, you can hit the button DB accesses to view which application parts are responsible for the majority of the database accesses:

Reporting performance issues to SAP

Questions that will be answered in this blog are:

  • Which information should I provide when reporting a performance issue to SAP?
  • What should I have already checked before submitting performance issue to SAP?

When to report a performance issue to SAP?

You can report a performance issue to SAP when you are sure it is caused by standard SAP.

There are 2 cases:

  1. Overall system performance
  2. Specific transaction performance

Validations to be done upfront:

What information to provide in a performance issue to SAP?

In case of specific performance issues, add as much specific information as possible. Try to have a case in a development, test or acceptance system as well. In these systems SAP can replay the performance issue without running the risk of hampering the end users performance. Add trace files (ANST, ST12) to speed up the analysis for SAP. It also makes debugging and running large trace files easier for SAP.

SAP checklists

Good checklists are present in OSS notes:

ST12 performance tracing

The ST12 performance tracing tool allows you to collect performance data for solving a performance issue for a single transaction.

Questions that will be answered in this blog are:

  • Which data is collected in a ST12 performance trace?
  • How do I execute a ST12 performance trace?
  • How do I analyse a ST12 performance trace?
  • How can I export a ST12 performance trace?

Performance trace collection

Start transaction ST12:

Select the user ID that you want to trace (can be your own user) and leave the ST12 session open. In a second session execute your actions. When you are done, return to the ST12 session and press the End traces & collect button:

Confirm the traces to collect.

Evaluation of traces

On the Collected trace analysis screen section hit the Full screen button:

This will open the easier to use full screen mode for analysis:

Now you can expand the traces and use the ABAP trace, performance trace, SQL trace buttons to launch the required performance analysis tools.

For more background on the tools read the blogs about:

Downloading the trace file

You can download the generated trace file to export to different system or to send to SAP. For example you have recorded the trace in production and want to do the further analysis on the development system.

To export goto transaction ST13 and use tool ANALYSISBROWSER:

Then select menu option Download / Text Download / Export to frontend to download the trace to your desktop or laptop.

Background

OSS background notes on ST12 performance tracing:

Application server performance: ABAPMETER

Sometimes you might get very weird performance results in a productive system. In the end it might turn out that performance on an application server is ok, and on another one it is not ok. This can be because of different infrastructure per application server or different settings.

The ABAPMETER performance tool will help you to analyze the differences between application servers. It will fire a series of standardized tests to each application server.

Questions that will be answered in this blog are:

  • How to run the ABAPMETER performance tool to check for differences in application server response times?

Running the ABAP meter performance tool

Start transaction ST13 and select tool PERF_TOOL to goto the performance tools:

Now select the ABAPMETER tool and press execute:

The tool will now run the tests per application server. Pending on the amount of application servers it might take a few minutes.

Results are shown:

You can now see if there are significant differences between the application servers.

Even if all are the same, note 2879613 – ABAPMETER in NetWeaver AS ABAP also contains hints on some of the key values. They might show network issues.

Background

Background OSS notes:

Snapshot monitoring

Snapshot monitoring enables you to capture snapshot of current performance and usage of work processes. This can be used to analyze performance issues.

Questions that will be answered in this blog are:

  • How to setup snapshot monitoring?
  • How to analyze the results of snapshot monitoring?
  • How can I see SM50 processes running when there are issues?

Setting up the snapshot monitor

Start transaction /SDF/SMON for snapshot monitoring:

If you don’t have any snapshot monitoring yet, you will reach the schedule screen:

Now you can plan a separate snapshot monitoring run, or set up the daily run:

For each run: check to increase the Interval timing!

Analyzing the snapshot monitoring results

With the Analysis button you can analyze the results:

In the snapshot monitor (/SDF/MON) you can drill down:

Double clicking at the line shows you the SM50 processes running at that point in time:

This enables you to analyze issues that occur for example in the middle of the night, and you want to see what is running at that point in time.

References

The tool /SDF/MON has been replaced by the SMON tool in netweaver 7.5 (using tcode /SDF/SMON). You will find notes for both tools.

SAP wiki for snapshot monitoring can be found on this link.

Explanation OSS notes:

Bug fix OSS notes:

First aid kit for performance issues on ABAP stack

This blog will give some first aid kit tips on performance issues on ABAP stack reported by end users. The system is up and running, but still user(s) complain about performance. What to do first?

SM50/SM66

Basically the first analysis always starts with SM50 (or when you have multiple application servers SM66).

Checklist for SM50:

  • Are all the DIA dialog processes full or almost full? –> if yes, then performance as total system will be slow. Check to find source for having so much DIA’s active.
  • Are all the BTC dialog background processes full? –> if yes, then all other batches will wait.
  • Are the UPD processes full? –> if yes, then all the other updates have to wait.
  • Are the SPO processes full –> if yes, then all prints have to wait.

Now you have a first impression of the state of the system.

Asking the user the right questions

Go back to the user complaint and start to ask questions:

  • Is he the only user complaining? Or are multiple users complaining?
  • Is the complaint about online or background job? Users can complain like ‘system performance is slow, since my background job takes a long time to start’
  • Is the complaint for updating or querying?
  • Is the complaint about printing?
  • Is the complaint about about performance in general or a specific transaction?
  • Is the complaint running now, or was it in the past?

If possible ask the user to start the poor performing transaction now so you can monitor it in SM50.

Solution kit

Too little dialog processes

If you cannot quickly locate the source of the process that is causing to consume all the dialog processes, you best temporarily increase the amount of DIA processes in the operation modes in RZ04.

Background processes full

Check to find the source of the large amount of background processes. If still too few, you can temporarily increase the amount of DIA processes in the operation modes in RZ04.

Another option is to check if some jobs can be stopped and planned at a later time.

Update processes full

If the update processes are full, check if the update process is running correctly in SM13.

Spool issues

If no prints are coming out of the system, there might be an issue with spool number range. System can look like this:

OSS note 48284 – System cannot generate any more spool requests contains the workprocedure.

Another solution can be to delete old spools.

If there are too many prints and too little spool processes, increase the amount of SPO processes in RZ04.

Buffering issues

Use transactions ST02 and AL12 to check for buffering issues. Read more about SAP buffering in this blog.

SAP references

SAP survival guide for performance issues: SAP note 2442365 – Survival Guide for performance analysis on SAP system contains an excellent PDF attachment for analyzing performance issues.

OSS note 948066 – Performance Analysis: Transactions to use lists all relevant performance related transactions.

RFC connections with fast serialization

Fast serialization is an option in the RFC settings to increase performance.

Questions that will be answered in this blog are:

  • What is required to use RFC fast serialization?
  • When to use RFC fast serialization?
  • How can I switch to fast serialization without touching the RFC in SM59?
  • How do I make the settings for RFC fast serialization?

Fast serialization

Fast serialization is available since release Basis 7.51. Downport might be possible, but think twice if you want to do this. Background OSS note on fast serialization is 2372888 – Fast serialization in RFC.

The whole goal of fast serialization is simply to increase the performance.

The fast serialization option is set in the RFC destination on the tab Special Options at the bottom:

Note that in S4HANA destination NONE is using fast serialization by default. Keep it that way.

Switching to fast serialization without touching SM59

In SM59 when you touch the RFC it might request you to re-enter the password. You can still switch the existing RFC without touching SM59. The instruction is in OSS note 2315100 – Activation of new RFC serialization on client side. Run program SFASTRFCMAINTENANCE:

When to use fast serialization

Fast serialization can be used when both the sender and receiver side of the RFC connection supports it.

Fast serialization in custom or standard RFC function modules

In SE37 SAP can set an RFC enabled function module Interface Contract to Fast serialization required. If you have build custom RFC function module that also only works with Fast serialization you should set this option:

SWLT performance tuning worklist

This blog explains how to use the SWLT performance tuning worklist to find poorly performing Z code by combining SQL monitoring data from production and ATC results.

Questions that will be answered are:

  • How to setup the SWLT performance tuning worklist tool?
  • How to analyze the results from the SWLT performance tuning worklist tool?

Preparations

As preparation for the SWLT tool you must have run the SQL monitor in a productive system and created a snapshot of the data. This snapshot you can export and import in a development system (see note 2700312 – How to import SQL Monitor (SQLM) extracted data). In the development system you configure and run the ATC code check tool.

The SWLT performance tuning worklist tool will combine these results. As example we will use this poorly written Z code:

Running the SWLT tool

Start transaction SWLT:

You can reduce the scope by just taking the needed Z packages. Goto the tab Static Checks to select the appropriate result of the ATC run (for more on ATC read this blog):

Now select the SQL monitor tab to select your SQLM data snapshot you took from your productive system:

Now that all data is loaded, you can hit the execute button to start the SQL performance tuning worklist.

It might be you don't see the SQLM snapshot in SWLT. In that case create a new snapshot from SWLT directly.

The tool will now start to merge the results. In the example above you can see the following result:

In the total result select a line. On the bottom left you can see the SQL monitor results. Bottom right you can see the ATC check result. Clicking on the underlined program or SQL statement will bring you to the poorly performing ABAP code point.

Bug fix notes

3060630 – Runtime error RUNT_INTERNAL_ERROR while fetching SQLM data (e.g. via SWLT)

SQLM SQL monitor

This blog will explain about the SQLM tool to monitor expensive SQL statements in a productive environment.

Questions that will be answered are:

  • How to start and configure the SQLM tool?
  • How to analyze the results?

Configuration of SQLM tool

The SQLM tool does not require specific configuration or installation if you have a bit modern SAP system. To activate it start transaction SQLM and click on the Activate button for All Servers:

The trace is active now until the given time frame.

Example use of the SQLM transaction

First we start by writing a very bad performing Z program:

This program is really inefficient. After activation of the SQLM monitoring we run this program a few times.

Now we goto the SQLMD transaction (or from SQLM and then press display data button) to display the SQL monitoring results:

Selection can be done on total number of executions, execution time, amount of records. Result:

You see now the impact of our badly written program. Double click on the line will jump to the ABAP code point.

Creating snapshots

At the bottom of the SQLM start screen there are the buttons to create snapshots:

This results into the Snapshot screen:

You can create a snapshot here for later re-use. You can also download the snapshot to a different system by using these buttons: first export to file:

When you have the file, goto the target system and start SQLM and press create snapshot. Now use the option Create with Data Source File Import.

It is common practice to capture data in production by a basis administrator who exports it. Then the data download is handed over to an ABAP developer using the data as upload in SQLM database in the development system to improve poorly performing Z code. The developer can use the SWLT tool (see blog) to combine the SQLM data with the static code review data taken from the ATC tool (see blog).

Follow up use in SWLT

The SQLM data can be used as input in the SWLT tool: SQL performance worklist tool. This tool combines the SQLM data with the ATC tool results. Read more about SWLT in this blog.

Background information

More background information can be found in OSS note 1885926 – ABAP SQL monitor and 3242700 – ABAP SQL Monitor: Implementation Guide and Best Practices.

Useful blog (which is start of blog series on SQLM): link.

Impact on performance and memory is minimal. Description is fully documented in OSS note 3100598 – Memory Requirement and Performance Impact of the SQL Monitor.

OSS notes

Relevant OSS notes: