The sweetest fruit salad recipe for energy saving services

Chapter 2: Outbound pressure control

(This story begins in Chapter 0. Launching an energy-saving rocket to the stars)

In this chapter, we are describing our steps to protect the consumed services based on their SLA, limiting the maximum number of requests sent in parallel.

The chosen mechanism to avoid overflowing the consumed service is to define the maximum connections to keep open for each client. This is achieved by using the reactor HttpClient with a fixed connection provider (instead of the default elastic provider):

HttpClient
  .create(ConnectionProvider.fixed(“ConsumedService”, maxConnections, acquireTimeout, maxIdleTime, maxLifeTime))

The maxConnections is defined as the max requests in parallel provided by the consumed service (declared on its SLA) divided by the (maximum) number of Kubernetes pods that will conform the cluster. To ensure that, in the most demanding scenario, all the pods have a number of connections affordable by the consumed service.

By opening our favourite JVM profiling tool, we can check the Active, Idle, Pending and Total connections for each “ConsumedService”, as shown here:

Later in this series of articles we will describe the steps to perform profiling tasks in Kubernetes.

The trip continues in Chapter 3. Retry Policy