ERP on SCALA-R - we test the performance of a bunch of SAP and Oracle Database

Small introduction

We at IBS wanted to go to Habr from the time when computers looked like in this picture. But constantly something was missing: either time, experts, or interesting stories. Finally, everything coincided and we launch our blog - mainly about the inside of our test lab (IBS InterLab), where it-infrastructure solutions are developed and technologies for customers are tested, plus a few other areas of corporate IT. We will rarely write, at least this summer, but we will try to produce the most useful material. Thank.

Go

Today, probably, almost the entire large business somehow works with ERP or other heavy business applications. Naturally, over time, the need arises to move to virtual machines. Solving this task from a snap is a dangerous business, as a whole bag of surprises always comes out along the way, each of which may well turn out to be a complete failure of the project. To prevent this from happening , the IBS InterLab team is engaged in testing various technologies for the client’s tasks, and as part of such studies, we managed to obtain results that may be interesting and useful.

How did it all start?

For the tasks of one of the customers, we did comparative testing of the performance of the tandems SAP + Oracle Database and SAP + HANA. We pursued several goals: to find out the behaviors of the new HANA DBMS for the Russian market and to see the possibilities of working with the HANA-certified computer complex from Huawei (we will certainly tell about this separately).

However, life is a dynamic thing, and very soon (by the standards of the universe, and scientific and technical progress, too), the SKALA-R universal convergent complex developed at IBS appeared on the horizon . And although we did not have time to work out special difficult tests (but we will definitely do it in the near future), we simply scratched our hands to evaluate its real capabilities when working in combat conditions. It was important not just to check “works / doesn't work” - we were 100% sure that it works.

I wanted to compare performance with some well-known product. Therefore, they decided to continue testing the SAP + Oracle bundle on our platform in order to compare it with the VMWare bundle test already performed.

Input data

The test complex used earlier was implemented in the cloud, which only increased the itch in our hands, as it made the comparison somewhat easier. So, in the SCALA-R cloud, an identical virtual machine was created, differing only in that if the previous one was implemented using a different hypervisor, then in this test we used a hypervisor from Parallels. A LUN assembled on a disk array using Raidix software was connected to this virtual machine. And it was with the latter, and more precisely with its scaling, that we had certain difficulties: it was necessary to correlate the performance of the disk subsystems - previously used and included in SCALA-R.

We solved this problem by comparing direct performance measurements in IOPs. It turned out that in the initial test the real performance of the virtual disk subsystem was 1,500 IOPs, and the measured performance of the dedicated LUN in SCALA-P was 1,900 IOPs according to IOMeter, which almost reached the theoretical 1998 IOPs calculated using a calculator . At the same time, for completeness, it should be noted that we managed to achieve the result of 1900 IOPs only after a significant increase in the size of the test data, since the disk array cache worked too hard on small volumes, and we received exorbitant 37100 IOPs.

That's about with this understanding of the ratio of hardware resources, we started testing. But again, it should be noted that the DBMS was used small in tests (slightly less than 1 GB), which predetermined the active influence of the cache on test results.

Test process

During testing, three dozen different kinds of queries were run, implemented both through a program written in ABAP and through standard SAP R / 3 functionality.

The first group of tests . Here we used 2-3 tables with a large number of records and fields in them (about 100), from which samples of several directions were made. At the same time, filtering criteria were selected in such a way as to several times change the number of returned records for different tests:
- A selection of individual database fields (rows 1 and 3). Three fields were selected, then filtering conditions ensured the return of a large volume of records (several hundred thousand) or small.
- A selection of all record fields (rows 2 and 4) from the same table. Filtration conditions remained similar.
- A selection of all record fields (rows 5-7, 13, 15, 17) from the same table. Filtering was carried out by key and non-key fields.
- Selection of one record field (lines 8-12, 14, 16, 18) from the same table. Filtering was carried out in the same way - by key and non-key fields.
The second group of tests. In this case, aggregate type queries were used for lines 19-21, that is, implying the execution of aggregation operations: the amount was calculated for the “posting value” field when grouping records by company codes and posting currency. This task was included in the testing program, since HANA is positioned as a system optimized for analytical applications (namely, to perform aggregation requests).
The third group of tests. The next round of tests included performing non-filtering selections (lines 22-25), which were carried out using the tool built into SAP (view table contents - transaction SE16), which allows you to view table contents. At the same time, the maximum limit for the number of returned records was set for this utility - 50,000.
The fourth group of tests. The last ones were synthetic tests, which are part of the standard SAP R / 3 functionality (lines 26-29) and proprietary data extractors for the SAP BW analytical reporting system (lines 30-34), which import data from R / 3 into BW. Extractors took data according to specified criteria: mainly periods for which documents should be selected.

Each test was run twice to evaluate cache performance levels. According to their results, it became obvious that during the first operation, all data is read from the data storage system, and during the second operation, the cache mechanisms are optimized. At the same time, in order to exclude the influence of the Oracle server cache, before performing a new type test, we zeroed it.

And now, for what everything was started, the test results. In theory, no special explanations are required for them, since everything is clearly presented in the tables. But if you have any questions, you can always ask them in the comments, and we will promptly and fully respond. So, look.

To summarize

Since we did not claim absolute scientific accuracy, we will draw conclusions in a fairly free form:

First , you can clearly see how the Oracle software cache works: a single run is enough to significantly reduce the time required to complete the operation. This can be attributed to the benefits of Oracle.
Secondly , the amount of time spent on each first test turns out to be approximately the same, and almost equivalent - the performance ratio of disk subsystems (1500IOPs / 1900IOPs). At the same time, it should be noted that the subsequent performance of the same type of tests on SCALA-R improves the results, which is explained by the inclusion of the disk array cache, which, in previous tests, seems to be a little filonil.
Thirdly , we will be as impartial and objective as possible, but at the same time, we note that our SCALA-R did a very good job of supporting ERP. We have obtained quite adequate results on a platform that has competitive functionality, but with a significantly lower cost compared to conventional solutions on hypervisors and disk arrays from well-known manufacturers. Despite the fact that for the purity of the experiment, it was decided to conduct a test on the "default" settings.

If you have something to add, ask, object or, so to speak, add to our “book of complaints and suggestions”, we will be glad to continue the discussion in the comments.

Experts worked on the post: Alexander Sashurin and Alexander Ignatiev with the active participation of Andrei Sungurov.

Thanks to them.

IBS Interlab Team .

Tags: