When comparing KrakenD with other solutions, a key difference is that its Total Cost of Ownership is actually lower, and you can save a lot of money in infrastructure.
On the hardware side, KrakenD is very light and consumes very low resources. For instance, the consumption pattern of the baseline (we will see this definition below) is around
100-200MB of RAM and can work on production with
0.5 vCPU. This baseline can process thousands of requests per second.
So, what are the server specifications (or container limits) I need to set for KrakenD?
It depends. For starters, there is no minimum size needed to operate KrakenD, and there is no certain type of hardware that you need to have. You can use anything from bare-metal to virtualized environments and Docker containers. In fact, you can run KrakenD in the small virtual servers with very good results.
Your final server size or container limit depends on many factors, like your choosen configuration and enabled components, the performance of your backends, the timeout settings, the network, the concurrency, and other factors.
The proper right way to determine this size is load testing the gateway.
Whatever is the server size you choose, the recommended approach is having more small machines rather than one or two big ones.
Keep an eye on network usage, as it is the first limit that KrakenD hits on public-cloud instances with limited throughput. Your KrakenD machines can be at a 10% of CPU/memory usage and still you can reach the maximum amount of traffic your provider allows you to use.
Let’s put some generalistic examples so you can quickly get an approximation in the following table. The recommended size is per KrakenD node, and assuming you have high throughput. And try to scale horizontally rather than vertically. You can use these numbers to start with sizing, albeit they are not written in stone:
|vCPUs||Memory||Gateway features and purpose|
|Baseline gateway (see definition below) with high throughput. No token validation, nor memory/cpu intensive operations and transformations.|
|Baseline gateway plus light cryptography algorithms in token validation, and moderate logging.|
|All purpose gateway|
|Massive traffic and several memory/cpu intensive operations, complex cryptography.|
|Numbers above this will be when you use KrakenD to cache content, make use of high-memory or CPU functionalities massively, or your environment pushes the gateway to consume more resources. Machines like this might indicate that you have a hidden problem.|
The baseline is a gateway with the following specifications enabled:
When extending the baseline, there are a few usual suspects responsible for memory or CPU consumption when the througput is high. Computationally complex components put the gateway under more pressure, and a downsized machine will show sympthoms of suffering on CPU/Memory. This is the TOP 10 usages that make the gateway work more:
3s) and what is more important, that KrakenD timeouts are larger than backend timeouts. You don’t want KrakenD cutting connections while your backend keeps working on something the end-user will never see.
Cache-Controlheader) of deciding how much memory KrakenD will need, the cardinality, and for how long!. Make sure you do not let the KrakenD cache go over its memory limit to see failures in its execution.
HS256) over very expensive algorithms like the
RS256. A special emphasys on high SHA algorithms like
RS512as they can make you dimension your CPU to x2.5 or more compared to
RS256. If extra security is a must, consider using
RS512to avoid a big impact. The more cryptographic complexity you add, the more CPU you are going to need.
DEBUGlogging level in production versus not having logging at all has a huge difference in throughput (between x2 and x5 vs the baseline). Choose a level that provides you sufficient information to make decisions on production, and avoid having KrakenD writing every single detail of the interaction, and dedicate those resources to your end-users.
All the components above are resource-efficient but they offer full flexibility. Depending on the configuration you choose they can lead to an increased consumption of resources when compared with the baseline.
The documentation is only a piece of the help you can get! Whether you are looking for Open Source or Enterprise support, see more support channels that can help you.