_close_expire_connections is unexpectedly expensive with tls connections

[bdraco]

It looks like the cause is calling into anyio get_extra_info because this function does a lot of work under the hood https://github.com/agronholm/anyio/blob/e0529a31e819064fcf1eaf7df55d1712a30bed6b/src/anyio/streams/tls.py#L230

All that httpcore wants is is_readable

httpcore/httpcore/_async/http11.py

Line 290 in 5518172

and self._network_stream.get_extra_info("is_readable")

but it looks like the extra call results in a few bonus calls that get thrown away

[TayfurYldz]

This specific hot path has changed since the profile in the report.

Current AnyIOStream.get_extra_info() no longer obtains a mapping of all TLS/socket extras and then selects is_readable. It handles each requested key explicitly. For "is_readable" it does only:

sock = self._stream.extra(anyio.abc.SocketAttribute.raw_socket, None)
return is_socket_readable(sock)

Likewise, SSL object/address/socket queries each request only their corresponding typed AnyIO attribute.

That is the right shape for this call site because HTTP11Connection.has_expired() only asks for "is_readable" when the connection is idle; constructing unrelated TLS metadata on every pool expiry scan was unnecessary work.

So before optimizing _close_expired_connections itself, I would rerun the original profile against current httpcore/AnyIO. If this path is still expensive, the new profile should be substantially narrower: obtaining SocketAttribute.raw_socket plus is_socket_readable(). At that point it would make sense to benchmark whether repeated readability probes across all idle connections are the remaining cost, rather than optimizing the old “collect every extra” behavior which current main no longer uses.

In other words, the reported diagnosis appears to have been addressed at the backend abstraction level; the useful next step is a current-version profile to see whether there is a second bottleneck underneath it.