Skip to Content
Product Information
Author's profile photo Marco Dorn

Optimise your SAP BTP, Cloud Foundry runtime costs

Recent talks with customers motivated me to write this blog post on how you can optimize your consumptions and therefore charges for SAP BTP, Cloud Foundry runtime when using the consumption-based models of SAP BTP. The runtime is charged by “GB of memory”, but it wasn’t obvious which amount of memory is taken into consideration.

When you deploy an application either via the user interface or by defining its attributes via YAML, you set the amount of memory which is reserved for each instance (or a default of 1024 MB is set). In the UI, this is called “Memory Quota” and inside a YAML, this is the value

modules.parameters.memory

This value is reported in the respective Cloud Foundry App Usage event (further described here at “memory_in_mb_per_instance“) along with the number of app instances.

Each hour, this is metered for each application instance in each Space inside a Global Account. At the end of a month, the hourly values are summed-up, divided by 730 hours, and rounded-up to the next full GB which is then charged in case the Global Account is based on the consumption-based model (CPEA or Pay-as-You-Go). An elaborate example for this calculation is given in the SAP Help Portal.

Start analysing

To start optimizing the above value, open your deployed application. You can see the defined value in the UI at “Quota Information > Memory Quota”. The maximum you can define for each instance is the “Instance Memory Limit“.
The memory available for the whole subaccount is shown in the brackets of “Memory Quota” called “available memory“ (see the second “Note” box here).

Further down below in the “Instances” section, you can see how much of the memory quota per instance is currently used. This is visualized with by the green bar of “Memory Usage”.

If you want to analyze the memory usage over time, you can use the “SAP Application Logging Service for SAP BTP“. It retains logs for 7 days and inside the Kibana dashboard of the service instance, you can open “Four Golden Signals > Saturation” and there see the “Memory load” over time. At the top right, you can change the time frame for the charts.

Furthermore, keep in mind that the assigned memory relates to the assigned CPUs. Each GB of memory relates to 1/4 CPU. Therefore, it is important to consider as well the “CPU load” over time which is displayd above the memory load chart.

After learning about the required memory+CPU and potential peaks, you can apply changes to the Memory Quota. Keep in mind that “if an instance exceeds this limit, Cloud Foundry restarts the instance. If an instance exceeds its memory limit repeatedly in a short period of time, Cloud Foundry delays restarting the instance.“ (source)

On top, keep in mind that apps based on certain technologies require a minimum of memory, like Java-based applications.

Avoiding trouble with help of the Application Autoscaler

Once you know the limits you need to set per instance for the vertical scaling, you can start thinking about horizontal scaling to dynamically add instances upon load or time schedule. Have a look into the “Application Autoscaler” service offered inside the SAP BTP to learn more about this.

Efficient Workload management on SAP Cloud Foundry using Application Autoscaler” elaborates on the topic, too.

Assigned Tags

      10 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Enric Castella
      Enric Castella

      Thanks a lot Marco for these tips.

      About the database, exist any strategy to optimize the HDI deployer app?

      I observed that after the deploy the application "DB deployer" is not necessary but automatically it's not possible delete as a last step in deployment.

      Regards

       

      Enric

       

       

      Author's profile photo Marco Dorn
      Marco Dorn
      Blog Post Author

      Hello Enric Castella,

      Could you please elaborate which database you refer to or which section of my post? I am not sure that I get your question.

      Best regards,
      Marco

      Author's profile photo Enric Castella
      Enric Castella

      Hi Marco,

      Sorry, I have not expressed myself well. I was referring to a CAP project, when deployed to the sub-account foundry, these projects generate an application:

      These applications seem to be used only for deploying, but if they are deleted afterwards, it does not affect the database or the API.

      My question was if there is any recommendation or mechanism to clean this type of applications and thus reduce the consumption of the account.

      Thanks in advance

      Regards

      Enric

      Author's profile photo Uwe Klinger
      Uwe Klinger

      Hi Enric,

      Unfortunately, I'm not aware of such a mechanism. But you can simply delete the app after successful deployment. Maybe you can add it to your deployment pipeline:

      cf delete my-api-db-deployer

      But what do you think cause costs? AFAIK only used memory is charged and the application will be automatically stopped. So it doesn't consume memory anymore.

       

      Best regards,

      Uwe

      Author's profile photo Kevin Hu
      Kevin Hu

      I think db deployer will be in stop status after the deployment. So shouldn't consume anymore memory usage.

      just checked mine, looks like no usage.

      You can safely leave it, or just delete the app. It will be re-created next time the developer deploys.

      Author's profile photo Kevin Hu
      Kevin Hu

      I think to put static web content in the HTML5 Repository instead and leveraging managed app router can be another factor to reduce cost of cf.

      Good to know SAP Application Logging Service for SAP BTP can be used to do this analysis, which is not a free service either 🙂. But I think the cost can be minimum as it is charged by tenant not by app.

      My Kibana dashboard btw. Looks good. Thanks.

       

      Author's profile photo Marco Dorn
      Marco Dorn
      Blog Post Author

      Hello Kevin Hu,

      Thanks for your interest in my post! You are right, there are paid plans for the Application Logging service. Next to that, there is as well the "lite" plan which is included in the overall SAP Business Technology Platform "Cloud Platform Enterprise Agreement" contract. It's not included in the PayG contract though.

      Best regards,
      Marco

      Author's profile photo Geert-Jan Klaps
      Geert-Jan Klaps

      Hi Marco Dorn,

      I'm looking into ways to optimize costs for CF-based applications, your blog already helped me optimize some of the applications. Thanks for these insights!

      Do you perhaps know if stopped applications are also counted towards the total consumed memory each hour? (I always thought that the actual consumed memory would be taken into account for consumption-based global accounts honesty)

      Reason for asking: in case of test / demo sub accounts in a consumption based global account we could e.g. automatically stop the running applications with some scripts running periodically. For example stop all applications at 10h PM and restart them at 8h AM. (saving about 10 hours of runtime every day and even more if we would not start the applications during the weekends for example)

      I can't seem to find a clear answer in the help documents or in other blogs.

      Best regards,

      Geert-Jan

      Author's profile photo Marco Dorn
      Marco Dorn
      Blog Post Author

      Hello Geert-Jan Klaps,

      Stopped applications are not reserving any memory, hence their instances are not charged. You could go ahead with such a script.

      Best regards,
      Marco

      Author's profile photo Geert-Jan Klaps
      Geert-Jan Klaps

      Hi Marco Dorn,

      Thanks for the information!

      Best regards,

      Geert-Jan