We performed some SAP Enterprise Threat Detection performance tests, regarding the SAP HANA database.
The goal of this test was to find out the average EPS (events per second) in relation to the retention time of the data in the hot database (in our case: SAP HANA). We chose for our test a retention time of 30 days. Of course you can keep the data longer in the database.
Following factors influence sizing of the HANA hardware
- Average Event rate (events per second, EPS)
- Retention time (days)
The following table provides some t-shirt sizes.
In order to do a proper sizing of SAP Enterprise Threat Detection, you need to have representative information about the amount of log data your systems are producing.
For SAP NetWeaver AS ABAP we suggest that you get a first indicator using the following rule of thumb:
- Ensure that Security Audit Log is fully turned on (logging all events / users / clients)
- For one week with average workload in your SAP application systems count the number of events logged by Business Transaction log (STAD, ST03N) and Security Audit Log (SM20)
Estimate for HANA RAM in GB:
Number of events (per week) * retention time (in days) / 50.000.000
Example: 1.800.000.000 * 30 / 50.000.000 = 1.080 GB, i.e. roughly 1 TB
Disclaimer: This rule-of-thumb estimate is just providing a first indicator for required HANA sizing. For a concrete implementation you should consult the SAP Enterprise Threat Detection Sizing Guide
If you need a very rough estimate about the EPS, you can also use this calculation
A user generates 0,05 – 0,2 log entries per second if he is actively working.
So if you have 5 000 employee working 3 hours a day in your SAP systems, you can calculate the number of events as following:
Peak times (all emoyees are working at the same time –> CPU intensive):
5 000 employees * 0,1 events/second = 500 events/second
Average(relevant for the size of the database):
5000 employees * (3/24) * 0,1 * = 62,5 events/second
– in our test enviroments we build up a large productive database but distributed the database across many blade servers. This can be for interest for very large instances to save costs (small instances versus one large one)
– please keep in mind that the calculation of the size of the database is related to the hot storage. See our official roadmap regarding our plans to hot and warm storage
The official sizing guide can be found here: http://help.sap.com/sapetd