Dragonfly 1.32 adds blocking multi-pop and command percentiles

A consumer waiting for work across several lists needs to coordinate the choice of source with the removal of values. Polling the lists and later popping one creates extra requests and an interval in which the available data can change. Dragonfly 1.32, published on August 4, adds BLMPOP and BZMPOP, extending the multi-pop operations with waiting behavior. The same release adds optional command-latency percentiles and CONFIG REWRITE.

The additions are useful at different stages of operating a cache. Blocking multi-pop supplies an application operation, percentiles expose a distribution of execution work, and configuration rewriting persists runtime settings through the server's configuration path. Search improvements reduce some of the work those observations may describe. None of these changes alone establishes that every workload becomes faster.

I like Dragonfly where the multicore engine makes one larger process a practical option. A fuller set of compatible commands makes that option usable for more application patterns. The waiting and response behavior of the new commands matters as much as recognizing their names.

BLMPOP waits for a list and returns a batch

The BLMPOP implementation extends existing list multi-pop behavior with a timeout. The command identifies a set of keys, selects left or right removal and accepts a count. If it finds a source, its response contains the selected key and the values removed from that list.

BLMPOP 5 2 queue-a queue-b LEFT COUNT 10

This asks to wait up to five seconds for one of two lists and remove up to ten values from the left of the selected list. It does not request ten values from every list. The key in the response tells the consumer which list supplied the returned batch.

The implementation uses the blocking container machinery and marks the connection's blocked and paused state through that path. That is more than repeatedly executing the nonblocking variant. The server must register the wait, resume it when appropriate and return a response consistent with the eventual source selection.

The count changes the amount of work returned per wakeup. It can reduce repeated pop requests when several values are ready, while the timeout still bounds how long the caller waits for availability. Those are separate aspects of the operation, and a client needs to interpret an empty timeout result differently from a successful batch.

BZMPOP applies the waiting model to sorted sets

BZMPOP support adds a blocking form of sorted-set multi-pop. It parses a timeout in addition to the number of keys and the selection options. The key-discovery code also changes because the timeout shifts the position of the argument that supplies the key count.

That parsing detail is operationally important to a multicore engine. The server needs to know which keys participate before scheduling the transaction on their owners. Correctly interpreting the argument layout is therefore part of routing and coordination, not merely a user-interface concern.

When no key is ready, the implementation waits on watched keys. Its transaction handling also distinguishes execution inside a MULTI sequence, where that waiting behavior cannot proceed in the same way. A blocking command's ordinary connection behavior should not be assumed to apply unchanged inside another transaction mechanism.

Both commands extend the server's command coverage, but they retain the data structures' different selection semantics. Lists choose a side, while sorted sets use score ordering. An application choosing between them is selecting a work-ordering model as well as a waiting API.

Execution histograms expose more than a mean

The latency-statistics contribution records command execution durations in HDR histograms and exposes percentile values through INFO. The initial percentiles are the median, the 99th percentile and the 99.9th percentile. They describe different points in the observed execution-time distribution.

The released command registry makes collection optional through latency_tracking, disabled by default. That detail prevents an operator from interpreting missing percentile output as evidence that no slow commands occurred. The collection needs to be enabled before those observations exist.

INFO LATENCYSTATS

A histogram of server command execution is also a narrower measurement than complete client latency. Time before execution or after the server prepares a reply can affect a caller's experience. The recording point establishes which interval the percentile describes, so it is useful to retain that scope when comparing it with application telemetry.

Reset support clears command histograms with CONFIG RESETSTAT. Its regression checks that earlier command statistics disappear, while the reset command itself can contribute a new observation. Resetting an observation window changes what the later percentiles summarize, without changing the commands' underlying implementation.

Search can skip irrelevant document ranges

Search-result merging changes introduce a representation that can hold owned results or borrow existing index results. It provides a common way to combine them without first copying every source into the same intermediate vector. The distinction between owning a result and viewing an existing one affects allocation and traversal work.

A related iterator improvement supplies seeking to the first document ID at or above a requested boundary. For suitable block representations, the iterator can skip blocks whose last entry is below that boundary and then search inside the relevant block. Merging need not visit every smaller document ID individually.

The benefit follows the shape of the query and its index results. If the merge already knows it needs a later document ID, stepping through every earlier one performs work whose outcome is predetermined. Seeking uses the ordering of the index to avoid that work. It is a specific improvement to result combination, rather than a claim that every search stage has the same cost.

These implementation changes also explain why latency observations need command-level context. Search requests can exercise different combinations of indices and different result sizes. A percentile summarizes observed executions of the command, while the iterator mechanism explains one reason those executions may differ.

Rewriting configuration is a persistence operation

CONFIG REWRITE adds a server operation for writing the current configuration through its configuration-file machinery. The released command handler reports an error if the rewrite fails and returns success only when the helper completes. Accepting runtime settings and persisting them are separate operations.

That is relevant to deployments where configuration changes originate inside the running process. A successful runtime update does not itself establish that the next start will use the same values. Rewriting provides an explicit persistence step, while the deployment's own configuration-management policy still determines which file is authoritative.

I find the release useful because its additions connect application behavior with operational visibility. Consumers can wait for multi-item work through the new pop commands, operators can collect execution distributions, and search uses more direct access to ordered results. Each capability has a defined scope which makes it possible to adopt it without assuming a broader guarantee than the implementation supplies.