Per-handler memory estimation, more accurate estimate for metadata handler #5346

The behavior of process_next_response is worth clarifying as the returned future does not nececessarily wait for all enqueued respones to be finished before resolving. We also rename the method to better reflect its purpose.

Currently we release resources after the response is enqueued in connection_context and response processing is called, but it may not have been sent at this point as we require in-order responses but second-stage processing may happen out of order. In this change, we instead tunnel the resource object through to the place where the response is written, and release it there. FIxes redpanda-data#5278.

This lets us share it with the request processing code which would also like to do type list based manipulation of the request types.

We already had concepts for one-phase and two-phase handlers, and this concept is simply the union of those two handler concepts, i.e., "any" type of handler.

We wish to reclaim the name handler for the generic handler interface introduced in the next change.

This is a polymorphic handler class (abstract class with virtual methods), as well as concrete instantiations of the interface for each of the existing handlers, which can be looked up by API key. This lets us treat handlers generically without resorting to template functions which must be specialized for each handler type. This reduces code bloat significantly as we do not duplicate code paths for our ~45 handler types. For example, requests.cc.o drops from ~11 MB to ~5 MB after it is switched to the any_handler approach.

The handler_interface already gets good functional coverage as it is added to the core request path in requests.cc, but we also include this unit test with basic coverage.

Preceding changes in this series introduced a runtime polymorphic handler class, and this change switches most of the request handling to use it. In particular, we replace the large switch on API key which dispatches to a template method to a lookup of the handler method and virtual dispatch. Some handlers that need special processing like the authentication/SASL related ones still use the old approach for now.

Currently we use single memory estimate for all kafka request types, but different API calls may use wildly different amounts of memory. This change allows each handler to perform an API-specific calculation instead.

In connection_context, we now use the handler-specific initial memory use estimate, rather than a single estimate for every handler type.

The session_resources type was a private member of connection_context, but as we want to use it more broadly, move it out as a standalone public class. Additionally, pass it by shared_pointer in preparation for later changes will feed it into requests.

Single-stage handlers have a handler template which means that handler objects can be declared in a single line specifying their api object, min and max API versions. This change extends this nice concept to two-stage handlers as well.

Passing the connection context to the estimator allows the estimator to use the various subsystems to estimate the memory use of a given request.

Currently we estimate that metadata requests take 8000 + rsize * 2 bytes of memory to process, where rsize is the size of the request. Since metadata requests are very small, this end up being roughly 8000 bytes. However, metadata requests which return information about every partition and replica may easily be several MBs in size. To fix this for metadata requests specifically, we use a new more conservative estimate which uses the current topic and partition configuration to give an upper bound on the size.

Prior to this change, we used only the topic and partition data to estimate the size of the metadata response. Now, we also include the approximate size of the broker metadata portion of the response, which may be important if the list of brokers is very large or they have very long hostnames.

We already check the bounds so the cpp core guideline presumably does not apply and we don't want to pay the price for the additional bounds check inside at().

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Per-handler memory estimation, more accurate estimate for metadata handler #5346

Per-handler memory estimation, more accurate estimate for metadata handler #5346

Commits on Jul 14, 2022