What the Performance Agent found in a Drupal site for 90 cents

We had a customer about to try the Performance Agent for the first time, and wanted to see it work on something they controlled before walking anyone through it. So they set up a throwaway Drupal project, wrote some custom module code, and deliberately planted an N+1 query in it. The kind of thing that's easy to write and easy to miss in review.

Then they ran the agent.

The bug they planted

It found the N+1. That was the pass or fail test, and it passed. The finding pointed at the custom code, explained the cost in plain terms, and came with a patch they described as ready to apply.

Good, but that was the bug they'd put there to be found. They hadn't told the agent anything about it, just pointed it at the application.

The bug they didn't

The second finding was the one that made them write it up. The project had Redis provisioned as a service, and as far as anyone could tell Drupal was using it. It wasn't. The cache backend had never actually been wired to the Redis relationship, so every cache read was quietly falling through to the database. The agent estimated that this accounted for about half the request time on the routes it looked at.

Nobody planted that. It's an ordinary way for a Drupal project to end up: you add a service, the config that should point at it never lands, and nothing makes enough noise for anyone to notice. A profile would show you a lot of database time. It wouldn't tell you the reason was a cache that thought it was Redis. Getting from one to the other means holding the profile, the service topology and the application config side by side, and that's the part the agent does that a profiler on its own can't.

The rest

The remaining findings were tuning: opcache settings and autoloader optimization, both with patches. Not dramatic, but exactly the sort of thing that goes on a list and stays there.

The numbers

The whole run took a few minutes. The model spend on their own API key was $0.90. The task container compute for a few minutes of runtime is a rounding error next to that. They'd left the default $5 budget ceiling in place and didn't get near it.

Why the profile matters

Most AI assistants for production problems reason over logs, metrics and traces. Those tell you an endpoint got slow at 14:02. They don't tell you which function is responsible or what to change, because that information lives in the profile and in the code.

The Performance Agent starts from the profile. It reads Blackfire profiles and continuous profiling data from the deployed environment, uses traffic to decide which endpoints actually matter to users, and then reads the source to work out the fix. The Redis finding is a good example of why the combination matters. No single one of those inputs would have produced it.

Try it on something you control first

Take a project where you know at least one thing that's wrong. Plant something if you have to. Run the agent, check whether it finds the thing you know about, and then pay attention to whatever else it turns up, because that second part tells you whether it's worth pointing at production.

Setup is a few lines in .upsun/config.yaml, an API key from Anthropic or OpenAI stored as a sensitive variable, and a redeploy. The docs cover it. It runs on Upsun Cloud and it produces a report rather than changing anything.