[Bug]: Bad performances upon Symfony Route cache miss

[B-Galati]

Bug report

Hi! Since we upgraded from 0.98.1 to 1.15.2 (yes big jump).

We noticed some performance degradation on some Symfony routes with low usage (< 0.1 req/s).

So I started investigating and noticed some weird Redis span at the end of our process as you can see on the screenshot at the end.

After investigation it looks like the Redis call comes from SymfonyIntegration when the option DD_TRACE_SYMFONY_HTTP_ROUTE is enabled.

At this stage, I think that somehow, cache misses make the route to be way slower than usual but I don't have any formal proof.
It is expected?

PHP version

$ php -v
PHP 8.3.29 (cli) (built: Dec 19 2025 07:35:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.29, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.29, Copyright (c), by Zend Technologies
    with blackfire v1.92.57~linux-x64-non_zts83, https://blackfire.io, by Blackfire
    with ddtrace v1.15.2, Copyright Datadog, by Datadog
    with datadog-profiling v1.15.2, Copyright Datadog, by Datadog
    with ddappsec v1.15.2, Copyright Datadog, by Datadog

Tracer or profiler version

1.15.2

Installed extensions

[PHP Modules]
amqp
apcu
bcmath
blackfire
calendar
Core
ctype
curl
datadog-profiling
date
ddappsec
ddtrace
dom
exif
FFI
fileinfo
filter
ftp
gd
gettext
hash
iconv
igbinary
imagick
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
random
readline
redis
Reflection
session
shmop
SimpleXML
soap
sockets
sodium
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache
blackfire
datadog-profiling
ddappsec
ddtrace

Output of phpinfo()

Datadog PHP tracer extension
For help, check out the documentation at https://docs.datadoghq.com/tracing/languages/php/
(c) Datadog 2020

Datadog tracing support => enabled
Version => 1.15.2
DATADOG TRACER CONFIGURATION => {
    "date": "2026-02-04T16:40:10Z",
    "os_name": "Linux",
    "os_version": "x.xx.xx-generic",
    "version": "1.15.2",
    "lang": "php",
    "lang_version": "8.3.14",
    "env": "prod",
    "enabled": true,
    "service": "some service",
    "enabled_cli": true,
    "agent_url": "agent_URL",
    "debug": false,
    "analytics_enabled": false,
    "sample_rate": -1,
    "sampling_rules": [],
    "tags": {
        "infra": "rancher",
        "product": "v3",
        "is_sandbox": "false"
    },
    "service_mapping": {
        "curl": "kalos\/curl",
        "guzzle": "kalos\/guzzle",
        "pdo": "kalos\/pdo",
        "phpredis": "kalos\/phpredis"
    },
    "distributed_tracing_enabled": true,
    "dd_version": "2026.02.04.0",
    "architecture": "x86_64",
    "instrumentation_telemetry_enabled": false,
    "sapi": "cli",
    "datadog.trace.sources_path": "\/opt\/datadog\/dd-library\/1.15.2\/dd-trace-sources\/src",
    "open_basedir_configured": false,
    "uri_fragment_regex": null,
    "uri_mapping_incoming": null,
    "uri_mapping_outgoing": null,
    "auto_flush_enabled": true,
    "generate_root_span": false,
    "http_client_split_by_domain": false,
    "measure_compile_time": true,
    "report_hostname_on_root_span": false,
    "traced_internal_functions": null,
    "enabled_from_env": true,
    "opcache.file_cache": null,
    "sidecar_trace_sender": false,
    "loaded_by_ssi": false
}

Upgrading from

0.98.1 -> 1.15.2

[B-Galati]

We can see the spike appearing consistently every hour

And between the spike it's OK!

[B-Galati]

I know it's expected that it is slow and hence the cache but it's way too slow and it's NOT OK to hijack the cache.app service like this 😅

This service could be configured to something totally un-efficient for this use-case, like an ArrayAdapter.

In general, that kind of info are built in Symfony cache directly to make these usecases efficient. That would require to setup a small Symfony Bundle though.

IMHO I see 2 solutions:

• Simply remove the feature, it just does not worth all the complexity just to fetch $route->getPath()
• Make the feature opt-in thanks to a new env variable but explain how it works with cache.app for instance. (Maybe modifying the behavior of DD_HTTP_SERVER_ROUTE_BASED_NAMING would do the job?)

[B-Galati]

@PROFeNoM @realFlowControl @bwoebi I would really appreciate if one of you could take a look 🙏

[cataphract]

Hello, I was the one who implemented this feature in #2992 . This was already the third iteration for calculating http.route for Symfony, and you've identified the trade-offs correctly. Unfortunately, I was unable to find an accurate and fast solution, hence the cache. Perhaps for the cache we could have used something with less user-visible side-effects and less dependent on app configuration, but the reasoning what that it would work best in the majority of cases. And for the other cases, the feature can be disabled.

However, it can certainly be argued that we should have gone for safer defaults, or perhaps extend the validity of the cache entry for longer than 1 h. I'll see what the people on the APM team think.

[B-Galati]

@cataphract Hi and thanks for the answer!

What do yout think about the solutions I proposed?

[B-Galati]

@cataphract friendly ping 🙏

[cataphract]

@B-Galati I'm going to explore the possibility of caching the full route collection, and to do it only once (invalidating it only when the cache is cleared or comparing with the modification time of the compiled route regex).

[B-Galati]

@cataphract on our end, we don't need that kind of info in Datadog, what do you think about adding a new variable to opt-out from this behavior?

[cataphract]

@B-Galati we'll keep the current setting that disables this feature

[B-Galati]

@cataphract The current setting? You mean DD_TRACE_SYMFONY_HTTP_ROUTE? I need to keep this option to have proper resource name and other info on the root span.

What I don't need is this one the screenshot (the one function responsible for the cache hijack and slowness):

What do you think?