Cost and Performance Optimization in Functions

Introduction

Catalyst enables memory provisioning for each function you create, based on your requirements. You can select a memory for your function when you are creating it, or edit its configurations any time you need. The flexibility to customize a function’s memory configuration over the default allocated memory allows you to optimize your Catalyst usage and manage resources better. You can monitor your application’s performance, prioritize your needs, make informed decisions for each use case, and draw substantial benefits from it.

This help page will explain the correlation between memory provisioning in functions and cost optimization, by explaining the pricing calculation methods of Catalyst functions with a few experiements. An increase in the memory provisioning of compute-intensive functions ideally results in a lower execution time, which in turn reduces your expenses in Catalyst. However, the optimal configuration varies from one use case to another, depending on the complexity of the operations performed in the function.

Pricing Calculations

This section explains the pricing model of Catalyst Functions. The table shown below displays the credits used for different function execution time range:

This table displays the credits consumed proportionate to the execution time, for each memory configuration in functions:

The cost of execution of functions is calculated as follows:

Cost of Execution of Functions = Number of Functions * Number of Credits based on the Execution Time * Number of Credits based on the Memory Consumed 

For example, here’s the calculation of the credits consumed in three different scenarios:

• If a function takes 4 sec with 128 MB, credits used = 1 * 1 * 1 = 1 credit
• If a function takes 8 sec with 256 MB, credits used = 1* 5 * 2 = 10 credits
• If a function takes 0.5 sec with 512 MB, credits used = 1 * 0.5 * 4 = 2 credits

Experiments with Memory Configurations for Cost Optimization

Let’s discuss optimal memory configurations of functions and cost minimizations, by taking a look at the observations made in two real-life experiments.

Experiment 1

A function performs a bubble sort of numbers from 1 to 100 arranged in a reverse sorted array. Application Performance Monitoring charts depicting the average response time for this function configured in three different memory settings: 128 MB, 256 MB, 512 MB, are shown below.

It was observed that the function with 128 MB took 35 milliseconds, the function with 256 MB took 29 milliseconds, and the one with 512 MB took 16 milliseconds to execute.

Let’s now calculate the credits consumed in each of these cases:

Case 1 with 128 MB: 1 * 0.5 * 1 = 0.5 credits

Case 2 with 256 MB: 1 * 0.5 * 2 = 1 credit

Case 3 with 512 MB: 1 * 0.5 * 4 = 2 credits

Experiment 2

Another function performs a bubble sort of all numbers between 1 to 10000 in a reverse sorted array in multiple passes, with each pass converting an array from an ascending order to the descending order, and back to the ascending order again. This function is configured in two different memory settings: 128 MB and 512 MB.

The execution data of this function in two memory settings reveals that the function with 128 MB took 6994 ms and the function with 512 MB memory took 3391 ms to execute.

Let’s now calculate the credits consumed in each of these cases:

Case 1 with 128 MB 1* 5 * 1 = 5 credits

Case 2 with 512 MB: 1* 4 * 1 = 4 credits

Inferences

We can draw the following inferences from these observations:

• In compute-intensive or CPU-centric use cases, the performance of a Catalyst function improves exponentially, the higher the memory you configure for it.
• In use cases that involve less intensive operations, the credit consumption is directly proportional to the increase in memory configurations.
  

Conclusion

Based on these inferences, we can come to the following conclusions:

• It is wiser to opt for higher memory configurations for functions that contain heavy computation logic.
  
  For example, assume that you make 10,000 function calls per month of the function described in experiment two. With 128 MB of memory, the function will consume 50,000 credits per month, whereas with 512 MB of memory the function will consume only 40,000 credits per month. This will save you 10,000 credits per month, and 1,20,000 credits per year, if the same pattern continues.*
  

• If a function does not contain compute-intensive logic, you can allocate memory suitable to the function’s requirements. For example, if you allocate 256 MB or 512 MB for a simple function that only consumes 100 MB of memory, it will be a waste of resources and expenses, and the response time would still remain the same.

The difference made by customizing a function’s memory and picking the ideal configuration for it is significant in terms of cost optimization and performance enhancements. There is no one-size-fits-all when it comes to choosing the right configuration for your functions.

As a general rule of thumb, you can start with the lowest memory setting and perform a trial-and-error until you find the optimal memory configuration. Catalyst Logs and Application Performance Monitoring can act as powerful tools to help you in the process. You can play around and experiment with the customizations and tools provided by Catalyst, until you obtain the right solution for your use case and usage.