Tracing Slow Drupal Requests With OpenTelemetry and Valkey

Slow responses from a Drupal site can involve work in several services before content reaches the frontend. OpenTelemetry traces record the relationships between instrumented operations, while Valkey metrics describe conditions in the cache server. Together, they can help developers locate the part of a request that needs investigation.

On a decoupled site, the frontend retrieves content from Drupal through an application programming interface (API). The time taken to answer that request may include cache access, database queries and calls to other services. A slow Drupal endpoint therefore needs an explanation that follows this work across components, while also checking that faster responses contain the correct content.

The tools provide different kinds of evidence. A distributed trace can show elapsed time across instrumented services and operations; cache-server metrics can show memory pressure, hit and miss counts, connections and evictions over the same period. Neither measurement alone establishes the cause of a slow Drupal response. The following deployment is an illustrative troubleshooting scenario, not a recorded case study or performance benchmark.

Consider an illustrative Drupal 11 deployment with a separate frontend server. That server calls Drupal's API, where the application checks a cache bin configured to use Valkey. If the required cached result is unavailable, Drupal performs the work needed to build it, which could include database queries or an external service call. This is a simplified request path, not a measured deployment.

The contributed Redis module provides the connection between Drupal's cache system and Valkey. It explicitly supports Valkey and offers PHP clients including the PhpRedis extension and the Predis library. Configuration selects the cache bins that use the external backend, so the request path depends on which data has actually been moved there.

The Linux Foundation announced the Valkey community on 28 March 2024 after Redis Inc. changed its licensing. Valkey continued from Redis 7.2.4 under the BSD 3-clause licence. That history explains the Redis-compatible ecosystem behind Drupal's integration; the announcement does not establish tracing capabilities or performance results.

In the example, a trace could connect the frontend's API call to Drupal's handling of it. Individual spans, the timed operations within a trace, could record a database query, a cache-client operation or a call to another service. Their durations help distinguish where the recorded time was spent. That visibility depends on instrumentation covering those operations.

OpenTelemetry's context-propagation documentation explains how the frontend and Drupal can retain that connection across a service boundary. Its default propagator uses the World Wide Web Consortium's Trace Context specification, including the traceparent request header. The receiving service uses the identifiers to relate its span to the upstream operation. Preserving the header supplies context; instrumentation still has to create the spans.

PHP's automatic instrumentation requires the OpenTelemetry extension, Composer autoloading, the software development kit, instrumentation libraries and configuration. Installing the extension alone does not generate traces. Drupal's contributed OpenTelemetry module describes visibility into request processing and database queries, but cache-client and external-call coverage must be checked for the chosen installation.

The resulting telemetry takes a separate route from the content response. An OpenTelemetry Collector can receive, process and export records to an analysis backend. The frontend receives Drupal's content while the backend stores and presents the trace evidence. Deploying a Collector does not itself add visibility inside an uninstrumented operation.

You May Like

Interview

The Work Behind the Workflow: Stas Zhuk and the Future of DDEV

Interview

The Work Behind the Workflow: Stas Zhuk and the Future of DDEV

A long cache-client span identifies time spent in that operation, but does not by itself explain conditions inside Valkey. Valkey's 28 September 2026 monitoring guide describes exporters that expose server data to Prometheus, a system for collecting time-series metrics. Valkey does not provide a Prometheus endpoint directly. Memory use, keyspace hits and misses, and connection counts provide another view of the period in which the request ran.

Suppose repeated database work appears in traces while the cache hit ratio falls. That combination makes cache behaviour worth investigating, without proving why entries were unavailable. Comparing memory use and eviction counts with the timing of content changes can help narrow that investigation. A server-wide hit ratio also covers many operations, so it cannot establish what happened to one request without corresponding application evidence.

Content changes introduce a correctness check alongside latency. Drupal's cache tags describe dependencies and allow affected entries to be invalidated across cache bins. In the example, changing the content must invalidate the relevant cached result so the next request can obtain updated data. A test that only confirms a fast cache read leaves that behaviour unexamined.

Memory policy can affect whether new results can be stored. Lagoon's Valkey documentation notes that Drupal may create cache keys without an expiry time. An eviction policy limited to expiring keys can then leave a full server unable to make space for new entries. Lagoon's cache configuration uses allkeys-lru, allowing any key to be evicted according to when it was least recently used.

That configuration assumes the data can be recreated. Lagoon distinguishes its ephemeral cache service, which loses data on container restarts, from a persistent service for queues or application data that must survive. The Redis module can also provide queue and lock backends. Their requirements need to be considered before applying an eviction or persistence policy chosen for replaceable cached content.

A distributed cache introduces another deployment constraint. A Drupal issue opened on 21 July 2026 reports CROSSSLOT errors during drush cr, the cache-rebuild command, against an Amazon Web Services (AWS) serverless Valkey backend. The report concerns operations involving keys assigned to different cluster hash slots. A maintainer's 6 August response states that cluster support had not been merged.

The issue describes a cache-prefix workaround that places keys in the same hash slot, at the cost of no longer distributing those keys across nodes. The separate RedisCluster integration issue remains under development. A clustered design therefore needs checks of cache rebuilds and invalidation as well as ordinary reads, rather than assuming that a successful connection establishes complete support.

The deployment's release choices also matter. OpenTelemetry's PHP implementation lists traces, metrics and logs as stable, while the Drupal module lists 1.0.0-beta7 for Drupal 9–11 and no supported stable release. The stable Redis 8.x-1.11 release supports Drupal 9.3–11; Drupal 12 compatibility was merged into its 2.x development branch on 15 August 2026. Drupal's 12.0.0-beta1 release notes reserve beta releases for compatibility and upgrade testing, not production.

For an existing Redis deployment, migration is a separate question from Drupal client support. Valkey's migration guide covers open-source Redis versions through 7.2, with compatible protocol, configuration and persistence formats. Data files produced by Redis Community Edition 7.4 and later are incompatible with Valkey under that process. Teams need to establish whether cached data can be rebuilt or whether retained data requires a different transfer method.

The final performance comparison should return to the original API request. Valkey's 25 August 2026 benchmarking guide explains why default command tests do not reproduce a production keyspace, value sizes or cache-miss behaviour. Drupal comparisons need response times and error rates under representative load, including warm-cache requests, requests after invalidation and behaviour when the cache is full or unavailable. Connected traces and server metrics can then explain the measured result, alongside the cost of collecting that telemetry.