NOTE : Network performance

Summary

Symptom

1. What is the focus of this note?

2. For which parts of the SAP environment is the network important?

3. Which symptoms indicate performance problems in the network area?

4. Which communications protocols are used in the SAP environment?

5. Which statistics are important for a network?

6. How can the statistics of a network be measured?

7. What must be taken into account when measuring the network statistics?

8. What other network tools exist?

9. What are good values for throughput and roundtrip time?

10. What is to be done if a communication has a throughput that is too low?

11. What is to be done if a communication has increased roundtrip times?

Other terms
FAQ, frequently asked questions
Solution

1. What is the focus of this note?

              This note cannot and will not provide an overview of all the aspects of networks. Instead, this note focuses on SAP-specific details and on performance aspects in particular.

2. For which parts of the SAP environment is the network important?

              A network is used when software resources communicate with each other across host boundaries, for example:

• Communication between the front end and the SAP system

• Communication between different SAP instances of an SAP system

• Communication of an SAP system with its database

• Communication between different SAP systems (for example, using RFC)

• Communication of SAP systems with non-SAP systems

              In addition, some communications within a host are also comparable with network communications (for example, the connection of an SAP instance with an Oracle database using TCP/IP).
              It is very important to include the network in performance analyses. Network performance problems are often recognized too late.

3. Which symptoms indicate performance problems in the network area?

              Time that is lost in the network usually results in "lost" time and apparently inconsistent time information for the partners who are involved in the communication. For example, a communication between an SAP instance and an Oracle database has the following typical symptoms:

• SAP transactions like SM50 or SM66 show a considerably higher number of database accesses than the Oracle session overview (for example, transaction ST04).

• SQL traces (transaction ST05) show considerably longer runtimes for SQL statements than the Oracle Shared Cursor Cache (column ELAPSED_TIME in V$SQL).

• SQL traces show individual runtime peaks that cannot be explained by other factors, such as disk accesses, or resource bottlenecks.

• The average database response time (transaction ST03N) increases even though Oracle does not seem to cause the problem.

              For more information, see Note 805934.

4. Which communications protocols are used in the SAP environment?

              Typical protocols on the individual layers are:

• Application layer

• Presentation layer:

• Oracle: TTC (Two Task Common)

• Session layer:

• Oracle: TNS (Transparent Network Substrate)

• Transport layer:

• SAP: NI (Network Interface)

• TCP

• Network layer:

• IP

• Data transfer layer

• Transfer technology layer

5. Which statistics are important for a network?

              The following properties are important for a network:

• Bandwidth:

           The bandwidth indicates what volume of data (typically in bits) for each time unit can theoretically be transferred by the technology used.

• Throughput:

           The throughput indicates what volume of data (typically in bits) for each time unit can be transferred by an application. The upper limit of the throughput is determined by the bandwidth. If different applications and processes use the same connection in parallel, the throughput that is actually possible may also be considerably lower than the theoretical bandwidth.

• Latency:

           The latency indicates how long it takes to send a request from a source to a target.

• Roundtrip time:

           The roundtrip time indicates how long it takes for an entire communication: source -> target -> source. It is usually about twice as long as the latency time.
              In addition, the reliability of the network is of central importance, that is, there should be as few communication errors as possible.

6. How can the statistics of a network be measured?

• Throughput

           You can use the SAP tool NIPING to measure the throughput that is currently possible:

• Start the NIPING server on <target_host> using:

                    niping -s

• Start the NIPING client on <source_host> using:

                    niping -c -H <target_host> -B 30000

• For example, the output is as follows:
  
  ------- times -----
  avg    4.695 ms
  max    36.867 ms
  min    0.658 ms
  tr  12479.766 kB/s
  excluding max and min:
  av2     1.178 ms
  tr2 49729.472 kB/s

• The approximate throughput is displayed in the last line. In this case, it is about 50 Mbyte/s, that is, 400 Mbit/s.

• For more information about NIPING, see Note 500235.

• Roundtrip time

           You can use the SAP tool NIPING to measure the roundtrip time:

• Start the NIPING server on <target_host> using:

                    niping -s

• Start the NIPING client on <source_host> using:

                    niping -c -H <target_host> -B 20 -L 10000

• For example, the output is as follows:
  
  ------- times -----
  avg    0.181 ms
  max    30.678 ms
  min    0.061 ms
  tr    107.963 kB/s
  excluding max and min:
  av2     0.178 ms
  tr2   109.808 kB/s

• The approximate roundtrip time is displayed in the line before the last line - in this case, it is 178 microseconds.

• It is useful to repeat this test several times to familiarize yourself with the typical values and differences.

• For more information about NIPING, see Note 500235.

7. What must be taken into account when measuring the network statistics?

              For different reasons, problems may occur when you measure network statistics:

• If there is a resource bottleneck on one of the servers involved (CPU bottleneck, paging, and so on), poor NIPING results may also be caused by this resource bottleneck.

• To catch temporary outliers, you must constantly monitor the network. Individual NIPING tests are not sufficient to do this.

• Using PING to determine the roundtrip time causes problems because PING is based on the ICMP protocol, which the network may handle differently than typical SAP communications.

8. What other network tools exist?

              In addition to the tools mentioned above, the following tools are also available:

• TRACERT (WINDOWS) / TRACEROUTE (UNIX)

           You can use this tool to determine the stations between a source host and a target host:

Route to the target host:  tracert    <target_host> (WINDOWS)
                    traceroute <target_host> (UNIX)

• NETSTAT

           You can use NETSTAT to read details about the network configuration, for example:

Active connections: netstat
Routing table:     netstat -r

• NSLOOKUP

           You can use NSLOOKUP to check the name resolution of a server:

Details about the name resolution: nslookup <host>

• IPCONFIG (WINDOWS)

           You can use IPCONFIG to display the current network configuration.

Current information:            ipconfig
Renewing all network adapters: ipconfig /renew

9. What are good values for throughput and roundtrip time?

• Throughput

           On all communication paths that involve larger data volumes, we recommend that you use a network topology with at least Gigabit Ethernet. In this case, Gigabit Ethernet results in typical throughputs of 400 Mbit/s.
           For connections that are not critical, or for communication channels with less data traffic, you can also use topologies with a lower bandwidth. For example, 100 Mbit Ethernet typically allows a throughput of 80 Mbit/s.

• Roundtrip time

           Increased roundtrip times may cause performance to deteriorate gradually. This applies even more, the greater the number of fast, small communications. For example:

• If you execute many fast queries on an Oracle database and if the "Time / User Call", therefore, is only 1.0 ms, a roundtrip time of 0.5 ms has a considerable effect and prolongs the average database accesses by 50 %.

• If the "Time / User Call" on Oracle is 10 ms instead, the network causes only an overhead of 5 % if it has a roundtrip time of 0.5 ms.

           Therefore, it is difficult to define values that are generally good. However, for performance-critical LAN environments (for example, a server network between SAP and the database), you can assume that the following threshold values apply:

• Good value: Roundtrip time <= 0.3 ms

• Moderate value: 0.3 ms < roundtrip time <= 0.7 ms

• Below average value: Roundtrip time > 0.7 ms

           For WAN environments, considerably longer roundtrip times are often acceptable.
           If both communication partners run on the same server and if, therefore, no classic network communication is required, roundtrip times are typically lower than or equal to 0.1 ms.

10. What is to be done if a communication has a throughput that is too low?

              The following approaches are available:

• Determine the main cause of the large load on the network. Individual SQL statements that read a high number of data records from the database and that are executed several times in parallel may already cause an overload on 100 Mbit networks. Therefore, with regard to Oracle databases (for example), check whether there are individual SQL statements with a high number of fetches or processed data records. Perform this check in accordance with Note 766349. Backups and replications may also have significant bandwidth requirements. Therefore, these operations should not use any critical communication channels (for example, the server network between SAP and the database).

• Ensure that critical communications run in their own network segment and that they cannot be interrupted by an external load.

• Check whether you can use a higher bandwidth by implementing short-term measures (for example, by reconfiguring the network).

• Switch to a network topology with a higher bandwidth.

11. What is to be done if a communication has increased roundtrip times?

              If you experience performance problems due to the roundtrip time, you can improve the situation as follows:

• If the problem is caused mainly by an increased roundtrip time, take account of the following points:

• Consult your network partner for the analysis and optimization of the network topology. The TCP/IP settings, such as the Maximum Transmission Unit (MTU) or the TCP Window Size, may affect network performance considerably.

• If possible, execute time-critical activities with a high number of roundtrips (for example, SAP background jobs) locally on the target server (for example, on the database server).

• When you use an Oracle database, ensure in accordance with Note 562403 that the Oracle Net configuration (TCP.NODELAY, SDU, DEFAULT_SDU_SIZE, and so on) is optimal.

• If the high number of roundtrips is also a cause of the problem, try to reduce the number of roundtrips:

• In the case of database accesses, avoid executing many individual database queries from the ABAP and try to bundle several queries instead.

• Test whether increasing rsdb/max_blocking_factor and rsdb/max_in_blocking_factor improves the situation for individual SQL statements or for the entire system. For Oracle, also refer to Note 881083 for more information about this.

Header Data

Release Status:	Released for Customer
Released on:	23.12.2008  17:00:30
Master Language:	German
Priority:	Recommendations/additional info
Category:	FAQ
Primary Component:	BC-NET Network Infrastructure
Secondary Components:	BC-DB-ORA Oracle

Affected Releases

Release-Independent

Note 1100926 - FAQ: Network performance

Posted in: Network,Performance,SAP,SAP Note