The concept of energy savings through SAP NetWeaver was first raised during the SAP Influencer Summit in December 2010 by Peter Graf, who used similar data to show how SAP development takes advantage of energy savings possibilities, which result in lower cost for operating our software and reduces carbon emissions.
In this blog I want to explain a bit more in detail how this calculation was done and on which assumptions it is based on. To make my case, I will use the example of SAP NetWeaver Process Integration (PI) software, as it is the area I worked on for many years and which I am most familiar with.
To demonstrate this idea, SAP carried out testing of its new SAP NetWeaver Platform using the SAP Application Performance Standard (SAPS). SAP defined a medium-sized landscape as being 37,500 SAPS for an SAP NetWeaver Process Integration (PI) customer.
Based on this definition, they found that the savings potential for PI is in the region of:
- 60% less energy consumption or around 32,000 kWh/yr
- 16 tons of CO2 savings per landscape/year
- €6.5k saving potential per landscape/year
Medium-sized PI landscapes
As we do not have 100% correct customer data on sizes of PI installation systems, we decided to undertake an expert evaluation of small, medium, and large PI customer installations. With input from the SAP field organization, PI product management, PI sizing experts, and regional implementation team experts, we decided to make the assumption that a small PI customer has installed 5.000 SAPS for production system, 15.000 SAPS for medium and 30.000 SAPS as large customer in production.
Customer landscapes consist not just of of the production environment, but also development and quality assurance systems; so we decided to take the factor 2,5 times of the production system for the complete customer landscape. Usually the quality assurance environment is of the same size of production, whereas development has half the size of production. The result led to the conclusion that a medium sized PI landscape is about: 37.500 SAPS.
Why we calculated with "SAPS"
With the help of SAP Standard Application Benchmark results at www.sap.com/benchmark, statements can be made as to CPU consumption and memory consumption of particular software components. SAPS is an artificial calculation to decouple software from hardware influences. That gave us the possibility to exclude improvements in the hardware environment from the improvements of the software.
How these savings are reflected in the SAP (Quick) Sizing
Improvements achieved on the software level can either mean customers can reduce their hardware demand, or process more messages in regards to PI usage. We did the calculation in a way where we kept the number of messages the same and expected the customer will reduce his hardware. The calculation is based on a mix of scenarios executed as integrated scenarios on a PI system. For the PI centric folks: 75.000 asynchronous messages of 100 KB size and 25.000 synchronous messages of 20 KB size with simple mapping and receiver determination executed in one hour executed on standard PI dual stack set up. That gave a SAPS demand of 15.000 SAPS in a classic PI dual stack usage with 66% hardware usage. Now, that can be executed on AEX as the Java only deployment option of PI with 61% less SAPS and hardware demand. These numbers have been tested and verified therefore the customer and partners will see the same results using SAP PI sizing tool.
How to transfer SAPS to energy consumption, costs of energy, and carbon emissions
All hardware needs different amounts of power resources to achieve a certain number of SAPS. By introducing the SAP Power Benchmark, the approach is that a hardware vendor does not only show that his hardware set up can provide the requested SAPS, but although how much energy input is needed to achieve this. As we could not calculate for all hardware vendors, we decided to take the average measured values for up to date hardware from 2010. With further improvements on hardware these values have to be adopted, but as hardware is in place for several years and older hardware is much more energy-intensive, we think things will be fine for this year.
To calculate the energy costs and potential customer cost savings we took the price of 0,2 € per one kilo watt per hour (kWh) in Germany, which is certainly different for other countries and business customers buying and consuming high numbers of energy. The same is true for the carbon emissions created to produce one kWh, because that is dependent on the energy mix of nuclear power, natural gas, coal, renewal energy in the individual country. For Germany that was 506 grams of carbon per kWh according to BDEW and as the energy mix is not unusual we took this number for the calculations. Result: 16 tons of CO2 savings per landscape/year.
How savings can be achieved
The main reason is that with integrated configurations all steps can be executed on one stack in our case Java. That reduces the persistency steps from 3 and more in "dual stack times" (ABAP + Java) to in average to one now. As we learned that especially write operations to hard discs are in average close to two times more power demanding then cpu and memory usage that already gives the major part. Additionally, there is no further need to connect one or two times from ABAP to Java stack at runtime, which results in further savings in resource consumption.
Another very big advantage with PI 7.3 and the Java only deployment option is that it only brings the software resources with it which are absolutely needed for PI. That reduces installation times, software patching times and restart times of the Java server. The times measured SAP internally on hardware with good read write operations are around two hours for AEX installation and one and a half to two minutes for a restart of Java server. Due to advanced installer and new PI 7.3 ctc scripts (SAP service Marketplace Logon Required) these numbers will be achievable for customers, too. Customers can get the benefits immediately as the product is generally available since 31. May 2011.
What we can learn for other SAP application developments
Process tasks in one step and in one technical stack together as long as possible, as the AEX does the main part. Reducing write operations to hard discs significantly reduces power consumption. Therefore, you shoul limit the amount of time for processing in memory and write only to disc your logs and application date where it is really necessary!
What the future holds
There are many areas where SAP can improve the carbon footprint of its software solutions. On the company level, on demand solutions could help eliminate the need for each customer to deploy and operate their own system and system landscape, and then provide the hardware and training for people to run these applications. Another possibility could be the in-memory approach to reduce read/write operations.
Individuals can also play a role. Many improvement possibilities are already known in people’s respective areas of expertise. Maybe you have own findings and best practices you’d like to share. Feel free to post and discuss!
This publication is part of SAP’s Green IT initiative, which is based on the following three pillars:
- Energy - reducing energy consumption
- E-waste –minimizing waste through sustainable sourcing and recycling
- Dematerialization –substituting high carbon products and activities with low carbon alternatives
SAP is committed to optimizing these three areas in its own IT operation, with its product development organization, as well as offering compelling solutions and services to our customers. If you need more information please refer to www.sap.com/greenit
