Product Information
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.
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
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
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
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
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.
Hi Kevin,
you've completely right. The deployer is only used to deploy the initial DB schema and update the schema. Its normal state is stoppend. And as far as I've seen stopped instances do not cost anything.
Best Regards
Gregor
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.
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
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
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
Hi Marco Dorn,
Thanks for the information!
Best regards,
Geert-Jan
Hi Marco , thank you for the great blog.
A couple of questions :
- in the following screenshot lte's say that the consumpiont will remain stable in the time , do i will be charged the cost for 69 MB or 256 Mb (tha is the memory quota available for the instance regardless the consumption) ?
- How the cost/memory would be deducted if I'm in CPEA Scenario with 50 GB available ?
Thank you in advance.
Hello Marco,
You are being charged of what you reserve per instance, i.e. 256 MB. Compare it to a flat with 256 m^2: even if you only use 69 right now, nobody will move into the remaining 187. You could get a smaller place, but if you at some point need again 256, it might not be available anymore.
Now the example breaks because at the end of the month, all the used MB of the whole Global Account are summed up and rounded up to the next GB.
Even if you could in theory use up to 50GB in that subaccount, it is only metered what you reserve for all instances.
Best regards,
Marco