Dragonfly 1.31.1 repairs TLS reads and exposes handshake counters

A server can spend more work receiving the same amount of application data if its TLS read path repeatedly returns less useful input. Dragonfly 1.31.1, published on July 14, fixes a TLS short-read issue which the release notes identify as harmful to read performance. It also reduces excessive logging during handshakes and adds counters which make connection behavior easier to distinguish from command processing.

The combination matters because an encrypted connection has work before and around each database request. A problem establishing connections differs from inefficient reads on established connections. Looking only at operations per second cannot identify which stage changed. The patch adds information about both stages while correcting the reported TLS behavior.

I find Dragonfly attractive when a cache can use more of a single machine. That makes network processing relevant alongside the engine's ability to execute commands across cores. A faster command path cannot compensate automatically for connection churn or unnecessary work delivering its input.

A read count adds context to byte totals

Pull request 5494 exposes the existing I/O read count through a network metric. It places that count alongside the input-byte counter. Bytes describe volume, while read operations describe how that volume arrives through the server's read path.

Those quantities can move differently. Receiving the same volume through more read operations can indicate a change in batching or read behavior. The counters do not establish a cause by themselves, but they provide the ingredients for comparing operation rate with input volume. That is more informative than interpreting unchanged byte throughput as proof that the path performs unchanged work.

The release's short-read fix addresses performance, without claiming that a TLS read must always fill the requested buffer. The useful interpretation is that the implementation repairs a particular inefficient behavior. It does not redefine partial reads as universally invalid or promise one receive operation per application request.

Handshake starts and completions describe different events

The handshake statistics patch registers an SSL information callback and counts handshake-start and handshake-complete events separately. The server exposes them through INFO as total_handshakes_started and total_handshakes_completed. The patch also includes those fields in aggregation of connection statistics.

INFO STATS

These totals are useful because receiving a connection does not prove that it reached a completed handshake. The difference can include work still in progress as well as unsuccessful attempts. A gap between cumulative counters therefore needs interpretation over time, instead of being treated as an exact current count of failed clients.

The callback's comments also distinguish paths that skip the observed handshake state. Counter meanings come from the events being recorded, rather than from an assumption that every accepted connection increments each total once. That detail is useful when a deployment compares TLS behavior across different connection patterns.

Error counters can replace repeated log volume

Pull request 5492 counts disconnects or errors while accepting TLS connections. It adds a TLS-specific reason to the listener-accept error metric. The affected paths include failure while reading the initial bytes, an invalid TLS header and handshake failure.

The same changes rate-limit relevant log messages. A counter can preserve evidence that failures continue while avoiding one repeated log line per attempt. Rate-limited logs still provide examples of the error, and the counter supplies frequency information which those sampled messages cannot establish alone.

This is a concrete distinction between diagnostic detail and event volume. A stack of repeated messages may consume resources while telling an operator little more than the first few entries. Separating a counted event from its logged explanation permits both to have an appropriate representation.

Session caching is a separate configuration

TLS session-cache controls add an enable flag, cache size and timeout. The implementation configures the SSL context when caching is enabled. These settings concern repeated connection establishment, independently of the short-read behavior on established connections.

It is useful to keep those scopes distinct when explaining a performance patch. Reusing session state and improving reads address different portions of connection lifetime. Changing a cache setting cannot be assumed to repair every source of TLS overhead merely because both appear in the same release.

Migration gets a cooperative scheduling adjustment

The patch release also adds a tunable sleep to migration streaming. Its explanation says migration could consume most scheduling time and throttle I/O connections. The change introduces a short pause after a configured amount of serialization work, along with statistics describing streamer throttling.

The author calls it an intermediate solution and documents remaining unfairness among producers. That qualification is technically useful. Making migration yield more deliberately can improve sharing without proving that every waiting producer now receives equal service. The change identifies the scheduling behavior it adjusts and the limitation it leaves.

I regard the added counters as part of the repair's practical value. Dragonfly 1.31.1 distinguishes handshake progress from read activity and provides counted evidence of TLS acceptance errors. That gives an existing deployment more precise information about which connection work accompanies its command traffic after the update.