nther
Tolkmit, vice president of corporate marketing at SAP.
Since its release in 1994, the number of installations of the NT version of R/3 has increased substantially. Today, 28 percent of all installations and 42 percent of new installations are on Microsoft's enterprise OS.
Testing NT Servers
SAP has defined a complex certification procedure that includes functional, stress, and performance tests to guarantee that a server provides the necessary reliability and scalability.
IXOS's (Munich, Germany) Competence Center for Windows NT on R/3 (R/3NTC) performs all certification tests on behalf of SAP. There are now 18 certified server platforms. They are from these companies: Amdahl, Bull/Zenith, Compaq, Data General, Dell, Digital Equipment, Fujitsu, Hewlett-Packard, Hitachi, IBM, Intergraph, Mitsubishi, NCR, NEC, Sequent, Siemens Nixdorf, Tandem, and Unisys.
Certification is not a one-time occurrence. Instead, it's a process that includes regular tests to ensure th
at the system still operates perfectly when there are new NT releases and hardware upgrades. In an initial test phase, engineers monitor critical components (e.g., processor, mainboard, and I/O controller), peripherals (e.g., hard drive, memory, and network adapter), and noncritical components (e.g., monitor and graphics adapter).
The functional tests evaluate the installation and upgrade of R/3, the underlying database, and the OS. They also include verification of the R/3 base modules and a detailed backup/recovery test. Stress tests and performance tests run in a distributed, real-world environment that includes a database server and several applications servers. A typical stress test simulates 900 users running the Sales and Distribution (SD) benchmark on nine applications servers and one database server.
The minimum stress-test duration is 8 hours with an average CPU load of 60 percent, generated by a standardized benchmark program that invokes R/3 base functions and the most popular transact
ions of various modules. A database backup running simultaneously increases the system load.
Scalable Systems
The R/3 benchmarks measure performance on different platforms. They also help SAP's hardware partners to adapt their servers to work in the most optimal way with R/3 and provide consultants and network managers with guidelines for fine-tuning various installations. Because SAP's benchmarks are available on all OSes, they can be useful in comparing configurations and hardware architectures, but also OS and database performance.
The most widely quoted benchmark deploys the R/3 SD module. Because SD is the most CPU-intensive module, the certification performance tests also use the SD benchmark. It works with predefined data that resembles the data sets of a large company. It simulates a typical user's actions and executes the most popular transactions of the SD module.
The results of the SAP standard benchmarks include average dialogue response times (e.g., 100 SD benchmark use
rs obtain an average response time of 1.2 seconds) and throughput in SAP Application Benchmark Performance Standard (SAPS) units. For example, 100 SAPS correspond with 2000 processed order-line items per hour in the SD benchmark. The benchmark simulates the entire work flow of an order-line item, including delivery notes, list orders, and creation of invoices, which translates into 6000 screen changes and 2000 postings per hour.
A typical R/3 benchmark curve shows average response time over the number of users. Typically, it remains constant over a broad range and then rises abruptly to the high-load range. The constant area reveals the basic response time that corresponds directly to the hardware characteristics. Even if you use sophisticated tuning techniques, you won't reduce basic response times.
The high-load range, which is where the benchmark curve leaves its horizontal course and rises exponentially, defines the maximum number of users. However, you shouldn't think that the maximum number
of users in a certain configuration isn't variable. With the right R/3 buffer sizes and optimal load balancing as well as optimization of database buffers, indexes, and storage parameters, it is, in almost all cases, possible to increase the number of concurrent users up to a point.
It's not difficult to interpret the benchmark results. They clearly reveal that in a three-tier NT configuration with separate Pentium Pro-based database and applications servers, the maximum number of real users is around 2500. In a central configuration with database and applications servers in one system, up to 200 real users will gain reasonable average response times. Considering that an R/3 installation typically has a few hundred users, it's obvious that the performance of NT Server is not a limiting factor in mission-critical R/3 applications. The benchmark results revealed by IXOS during the last three years show that software optimization and the dramatic increase in computing power of Pentium and Alpha servers hav
e made NT a viable OS alternative for R/3. The figure
"R/3 Benchmark Results"
shows that the maximum number of users, as a result of the SD benchmark, rose from 220 in June 1995 to 1116 in March. (One SD benchmark user corresponds to three real users.)
However, if you plan to run an R/3 installation with more than 2500 users, you may want to go for a homogeneous Unix configuration. If you still want to use NT, you can use a Unix database server coupled with NT applications servers. Both configurations can easily serve more than 2500 users.
Scalability is not the only crucial issue in mission-critical applications. High-availability concepts and sophisticated clustering solutions (see the sidebar "Higher Availability for R/3 Under Windows NT") are equally important. There are a few possible fail-over scenarios (see the table
"Switch-Over Scenarios"
). The selection of a scenario depends on individual user requirements such as the overall performance of clu
ster nodes and the combination of server OSes (e.g., the DBMS on the Unix server outside the cluster and Central Instance [CI] on the NT server inside the cluster). Typically, the R/3 CI and the DBMS reside inside the cluster. If one of these cluster nodes fails, the other one immediately takes over all the services of the failed node.
The first clustering NT solutions for R/3 were on display at CeBIT this spring. Expect to see commercially available R/3-specific Wolfpack components later this year (see this month's Software Lab Report "Wolfpack Howls Its Arrival"). However, clustering solutions for R/3 that include load balancing inside the cluster may not be on the market before 1998.
R/3 Soars on Windows NT
