In a prior blog we provided some tips on Managing HANA memory. In this article we will further explore the improvement with ESS (Embedded Statistics Service) available on HANA from SPS 7 revision 74 or higher. As a quick recap, memory consumption by the hdbstatisticsserver can be heavily impacted by the volume and frequency of various statistics collected by the HANA statistics engine, mainly the columnar tables in _SYS_STATISTICS schema. These tables provide stats for monitoring by tools such as the HANA Studio, SAP DBA Cockpit and Solution Manager, as well as external SAP management tools like IT-Conductor and HANA Management Pack for SCOM.
We've had the opportunity to work with HANA both as a Startup porting our application to HANA as well as with our SAP customers running HANA in production scale BW or ECC environments. In the R&D environment we have limited hardware capacity and thus resources, especially memory is always a constraint, so we learnt ways to monitor, and automate to optimize our performance and use of the system. In the customers' production environment, we have seen original architecture plans double in nodes and/or memory before they even got to performance testing phase.
As far back as I can remember, and that's more than 20 years working in SAP Basis, since the days of R/3, there's always been this 2 second average response time per dialog step (or simply 2 second response) benchmark as acceptable performance of an SAP OLTP system. Depending on the customer, some will tweak that to fit their business, and I have seen it range from 0.5 second to as high as 5 seconds. Honestly, it's a misleading indicator of performance because on any given mid-size SAP ECC production system with about 500 concurrent users, that number quickly becomes a useless measure with more transaction mix between SAP and custom code. To put it into perspective, a system may have a 0.5 second response time, but there are constant complaints from users with bad response times. Why? It's the law of averages. The more number of small transactions there are (those who run relatively quick), the more they bring down the system average into an attractive average response time, even though there are transactions that run forever and frustrate the hell out of those users who need to run them as part of their daily business process. It's because dialog steps are not created equal.