In this weblog, you will get information about sizing aspects for a system used for the system landscape directory (SLD) of SAP NetWeaver.
This information (and updates of it) will be included in future versions of the Planning Guide – System Landscape Directory.
As a starting point, we recommend that you stick to the recommendation for an AS Java system given in the implementation documentation of SAP NetWeaver. This normally fits most use cases of the system landscape directory. For large use case scenarios, you can perform normal AS Java sizing. For more information about:
- Hardware recommendations given in the implementation documentation, see SAP Service Marketplace at service.sap.com/instguidesnw
- Sizing of SAP NetWeaver in general, see SAP Service Marketplace at service.sap.com/sizing
For example, we recommend to run the system landscape directory of SAP NetWeaver 7.0 at least on a host with a 64-bit dual core CPU with not less than 4 GB of RAM and on up-to-date hardware for the other parts as well (like disks, etc.).
Running the system landscape directory on more powerful hardware should reduce the processing times assumed below for the estimation of the system load.
We recommend that you run the system landscape directory on a non-clustered system. If you run the system landscape directory of SAP NetWeaver 2004 or SAP NetWeaver 7.0 on a clustered system, make sure to disable the cache of the system landscape directory. For more information, see SAP Note 825116.
If you plan to run the system landscape directory on a system shared by several applications, be aware that all applications running shared on this system will compete for hardware resources.
Estimation of System Load
The following rule of thumb helps you to judge the hardware requirements based on the load in a system landscape directory caused by SLD data suppliers. To compute the data received by one SLD data supplier, we assume the following maximum processing times for the system landscape directory (based on the hardware listed above):
- 10 seconds for data received from the data supplier of an ABAP system
- 30 seconds for data received from the data supplier of a Java system
For example, if you have 60 ABAP and 30 Java systems connected to your system landscape directory and each of these systems sends data twice a day (which correlates to the standard data supplier configuration), you would get a maximum processing time for data suppliers of 50 minutes (60 ABAP systems * 2 messages per system and day * 10 seconds/per message + 30 Java systems * 2 messages per system and day * 30 seconds/per message = 3000 seconds per day = 50 minutes per day).
These assumptions do not consider peak loads of the system landscape directory. So, it could be a problem for the system landscape directory if all data suppliers send updates at the same time. As a result, we recommend that you add further reserves and use factors of safety.
Also, if you want to reduce the load of your system landscape directory, you could consider to reduce the frequency how often data suppliers send updates to the system landscape directory and try to deconcentrate the time when the single data suppliers send updates to the system landscape directory. For example, by reducing the update frequency from twice to once a day, you halve the corresponding processing time to handle data supplier data in the system landscape directory.
In our example, a system as proposed above could process the data of the data suppliers of both over 1000 ABAP and 1000 Java systems, but only if the updates are sent spread over the day. As this can hardly be guaranteed, you should restrict the number to several hundred connected systems, reduce the update frequency or use a stronger host.
In addition, load is generated by UI access (browsing data in the system landscape directory) and clients that read data from and write data into the system landscape directory (such as SAP NetWeaver Administrator, SAP NetWeaver Process Integration, and SAP Solution Manager). The corresponding load is hard to judge as it strongly depends on your system landscape and how you use the single clients that rely on the system landscape directory.