A full TLS handshake is the most CPU-intensive thing Apache does per connection. Session resumption exists to avoid paying that cost on every reconnect: a client that recently completed a handshake can resume instead of redoing the asymmetric cryptography. When resumption silently stops working, every connection pays full price, and the only symptom is rising CPU with no error in the log.

The most common way resumption breaks in Apache 2.4 is the server-side session cache: it was never configured (the default is no cache at all), it is not shared across child processes, or it has quietly filled up. A full shmcb cache logs nothing. It evicts old sessions, the resumption rate drops, and CPU climbs. This article covers how the cache works, how session IDs differ from session tickets, how to size shmcb, and how to detect the silent-full condition from resumption rate and cache statistics.

What the session cache is and why it matters

TLS offers two resumption mechanisms with completely different server-side requirements:

Session IDs (server-side cache). After a full handshake, the server stores the negotiated session parameters under an ID and hands that ID to the client. On reconnect, the client presents the ID; the server looks it up and, if found, resumes. The critical property: the lookup happens in server memory. Apache runs many child processes, and a reconnecting client will very likely land on a different child than the one that created the session. Unless the cache is shared memory, resumption only works within the originating child. On a server with dozens of children, most resumption attempts miss and fall back to a full handshake.

Session tickets (RFC 5077). The server encrypts the session state into a ticket and hands it to the client. On reconnect, the client presents the ticket; the server decrypts it and resumes. No server-side storage is involved, so tickets work across child processes automatically, with no shmcb cache at all. In Apache 2.4.11 and later, SSLSessionTickets defaults to on.

The catch with tickets is key management. Without SSLSessionTicketKeyFile, mod_ssl generates random ticket keys at startup, so tickets are invalidated by every restart and cannot be shared across a cluster of Apache nodes behind a load balancer. The mod_ssl documentation also warns that using tickets without restarting the web server with appropriate frequency (for example daily) compromises perfect forward secrecy, because the same ticket key protects all resumed sessions. Session IDs in a shared cache do not have that property.

The operational position for most deployments: use shmcb for session IDs, and make a deliberate decision about tickets rather than inheriting the default.

How shmcb works

shmcb is a shared-memory cyclic buffer provided by mod_socache_shmcb. You configure it with:

SSLSessionCache shmcb:/var/run/httpd/ssl_scache(512000)
SSLSessionCacheTimeout 300

The path is a data file used to coordinate the shared segment; the size in parentheses is the buffer size in bytes. SSLSessionCacheTimeout defaults to 300 seconds and controls how long a cached session stays valid. Since Apache 2.4.10, the same timeout also applies to session tickets.

Three behaviors matter operationally:

  1. The buffer is cyclic. When it fills, old entries are scrolled out to make room for new ones, before they would have expired naturally. This is eviction by overwrite, not an error condition as far as Apache is concerned.

  2. Eviction is silent. Nothing is logged when sessions are scrolled out. The only symptoms are a falling resumption rate and rising CPU from full handshakes: everything looks configured, and nothing complains.

  3. The module is not loaded by default in 2.4. In Apache 2.2, mod_socache_shmcb loaded automatically. In 2.4 the LoadModule line is typically commented out. If you configure SSLSessionCache shmcb:... without the module, startup fails with SSLSessionCache: 'shmcb' session cache not supported. Maybe you need to load the appropriate socache module (mod_socache_shmcb?). This is the classic 2.2-to-2.4 migration trap. There is also a related failure, AH00820: shared memory segment too small, reported by operators when the configured size cannot accommodate the session volume; one reported case was resolved by explicitly setting SSLSessionCacheTimeout 300 so entries expired instead of accumulating.

flowchart TD
  C[Client reconnects] --> D{Resumption offered}
  D -->|Session ID| L[shmcb lookup in shared memory]
  L -->|Hit| R[Resumed session, cheap]
  L -->|Miss or evicted| F[Full handshake, expensive]
  L -->|Cache full: oldest scrolled out| F
  D -->|Session ticket| T[Decrypt ticket with ticket key]
  T -->|Key valid| R
  T -->|Key rotated or restart| F
  F --> CPU[Rising TLS CPU, no error logged]

Note the structural difference: the ticket path never touches the cache. The session-ID path depends entirely on it.

Where this shows up in production

After any restart. The session cache lives in memory. Every restart, graceful or hard, empties it, and the server takes a burst of full handshakes while it refills. This is normal cold-start behavior, but on a CPU-constrained box it can be a visible latency event. Frequent restarts (aggressive config management, log rotation that signals Apache to restart) make it a recurring tax rather than a one-time one.

Behind a load balancer with multiple Apache nodes. A client resumed on node A may reconnect to node B. shmcb is per-host shared memory; it is not shared across servers. Session tickets with a shared SSLSessionTicketKeyFile (a 48-byte key distributed to all nodes) are the standard answer for cross-node resumption. Without a shared key file, each node generates random keys at startup and cross-node resumption fails silently. Ticket key rotation requires a restart, and all existing tickets become invalid at that point.

As a CPU mystery. The signature is high CPU plus a high SSL connection rate plus an underperforming resumption rate. There is no dedicated Apache metric for handshake cost; you infer it from connection rate to port 443, CPU patterns, and the resumption rate itself.

Sizing the cache

The official mod_ssl documentation gives no sizing formula. The commonly used example, 512000 (500 KB), is a starting point, not a recommendation for your traffic. The honest method is empirical: configure a size, watch the cache statistics, and grow it until eviction stops.

The inputs to your estimate:

  • New full handshakes per second. Each one inserts an entry. This is your insertion rate.
  • SSLSessionCacheTimeout. Entries live for this long (default 300 s). Target capacity is roughly insertion rate times timeout, times per-entry size.
  • Headroom for bursts. A reconnect storm (mobile clients moving networks, a client fleet restarting after an outage) inserts at many times the steady-state rate.

Worked example with the unverified per-entry estimate above: at 50 new sessions per second and a 300 s timeout, you need capacity for about 15,000 live entries. At ~250 bytes each, that is roughly 3.75 MB, so the default-ish 500 KB example would evict aggressively under this load. Size up, then confirm with the counters below rather than trusting the arithmetic.

Do not overcorrect by setting an enormous timeout to avoid eviction. Long timeouts keep stale sessions in the buffer, increase the working set, and weaken the security property that old sessions die. Grow the buffer, keep the timeout sane.

Detecting the silent-full condition

mod_status exposes the socache statistics when the SSL session cache information is enabled (ExtendedStatus On). The counters you care about are: shared memory size, current entries, cache usage percentage, and the store/retrieve/eviction counters, including entries scrolled out before expiry and retrieve hits versus misses.

# The SSL cache block appears in the HTML status page, not the ?auto output
curl -s http://localhost/server-status | grep -iA25 "session cache"

# Direct resumption test against the live server:
# reconnects 5 times over one control connection and counts reused sessions
openssl s_client -connect localhost:443 -servername $(hostname) -reconnect 2>/dev/null | grep -c "Reused"

The openssl s_client -reconnect check is the ground truth: it performs repeated handshakes and reports how many were resumed. On a healthy cache you should see 5 of 5 reused (the control connection negotiates the session, then all reconnects resume it). Fewer means resumption is failing. Zero usually means no shared cache is configured at all (SSLSessionCache none is the 2.4 default, so a server that was never explicitly configured will fail this test).

Interpreting the mod_status counters:

Counter patternMeaning
Cache usage near 100%, scrolled-out counter increasingCache is full and evicting. Grow the buffer.
Retrieve misses dominating hits, usage lowClients are not returning (short revisit intervals) or timeout too short.
Retrieve misses high, usage highEviction is destroying sessions before clients come back.
All misses, usage near zero after trafficCache effectively unused. Check that SSLSessionCache is actually set and the socache module is loaded.

Correlate with two signals: CPU per connection on port 443 trending up while connection rate is flat, and time-to-first-byte creeping up as full handshakes get more common. Neither has an error log entry attached. That absence is the detection gap you have to close with monitoring.

Signals to watch in production

SignalWhy it mattersWarning sign
shmcb cache usage %Direct measure of fill levelSustained near 100%
Pre-expiry scrolled-out entriesThe eviction counter; the only record of silent evictionAny sustained increase
Retrieve hit/miss ratioEffective resumption rateHit rate below ~80% on a site with repeat visitors
openssl s_client -reconnect reuse countGround-truth resumption checkFewer than 5 of 5 reused
Apache CPU vs port-443 connection rateFull handshakes are the cost eviction createsCPU rising while connection rate is flat
Restart frequencyEvery restart empties the cacheMore restarts than deployments justify

How Netdata helps

  • Netdata charts Apache CPU utilization and connection counts per second, which makes the “CPU rising, connections flat” divergence visible as two curves separating, rather than something you infer during an incident.
  • The Apache collector samples server-status, so scoreboard and throughput context sit on the same dashboard as system CPU when you are ruling out other handshake-cost causes like a traffic spike or a new cipher configuration.
  • Because the silent-full condition logs nothing, the practical alerting path is this correlation: resumption proxies (cache statistics where collected, CPU per connection trend) against a baseline, with an alert on sustained deviation.
  • Netdata’s Apache HTTP Server monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.