Sensio Buzz Profiler Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. There is no service provider, no config/*.php to publish, and no facade. If you are working in a Laravel app, read this section as "what you'd have to port"; if you are in a legacy Symfony 2.x/3.x app, it applies directly.

Prerequisites (all of them, or nothing works):

• A Symfony 2.3–3.x application (the era of AppKernel).
• sensio/buzz-bundle — provides the buzz service.
• juliendidier/buzz-profiler-bundle — provides the data collector and the tracing/decorating client.
• This bundle — the glue that makes the default buzz service the profiled one, so you don't have to wire the decorator by hand.

Install:

composer require --dev olegstepura/sensio-buzz-profiler-bundle

Register it in the dev/test kernel only:

// app/AppKernel.php
if (in_array($this->getEnvironment(), ['dev', 'test'])) {
    $bundles[] = new Sensio\Bundle\BuzzBundle\SensioBuzzBundle();
    $bundles[] = new JulienDidier\BuzzProfilerBundle\JulienDidierBuzzProfilerBundle();
    $bundles[] = new OlegStepura\SensioBuzzProfilerBundle\SensioBuzzProfilerBundle();
}

Where to look first: the bundle is tiny — open its DependencyInjection/ extension and any compiler pass. Confirm which service id it targets (expected: buzz) and whether it aliases or decorates. That single file tells you everything about whether it will work in your app.

First use case: inject buzz into a controller, make one call, then open /_profiler, pick the request, and look for the Buzz panel. If the panel is there with your URL and timing, the glue worked.

public function indexAction(Buzz\Browser $buzz)
{
    $response = $buzz->get('https://example.com/api/ping');
    return new Response($response->getContent());
}

Implementation Patterns

Inject the service, never instantiate a client. The whole point is that the container-managed buzz service is the profiled instance. new Buzz\Browser(new Buzz\Client\Curl()) bypasses the profiler entirely.

class PingService
{
    private $buzz;

    public function __construct(Buzz\Browser $buzz)
    {
        $this->buzz = $buzz;
    }

    public function ping(string $url): string
    {
        return $this->buzz->get($url)->getContent();
    }
}

Wrap Buzz behind one gateway class. You get two things: a single place to swap Buzz for Guzzle or Symfony HttpClient later, and a single place to add logging/retry that survives the migration.

Custom clients: if you configure sensio_buzz with a non-default client (Curl, Socket), verify the profiler decorates that service. If the bundle only wraps the default, define your custom client as the one aliased to buzz rather than registering a second id.

Console commands: the profiler collector only exists during an HTTP request. If the same service is used from a command, guard any instrumentation:

if ($this->container->has('profiler')) {
    // only meaningful in a request context
}

Don't let dev-only decoration leak into command execution paths.

Testing: keep the bundle out of the test env unless you actually assert on collector data. Keeping it in test means every HTTP call gets wrapped, which slows suites and produces confusing stack traces from inside the decorator.

Migration note for Laravel devs: the equivalent day-to-day pattern is Http::withOptions() plus a Http::globalRequestMiddleware() or Telescope's HTTP watcher. There is no Buzz equivalent here — porting this bundle means porting a Symfony data collector, which is more work than writing a small Guzzle middleware.

Gotchas and Tips

• Buzz is abandoned. sensio/buzz-bundle was superseded by Symfony's own HttpClient. This bundle exists only to smooth over a transition that already happened years ago. With 1 star and 0 dependents, expect no fixes for any Symfony version past ~3.4.
• Symfony 4+ incompatibility is likely. Old-style service definitions (services.yml, %kernel.debug% arguments, no autowiring) generally fail to load under modern Symfony. You may get a container compile error before you ever reach a request.
• Verify the wiring, don't assume it. Run bin/console debug:container buzz --show-private and look at the class. If it reports Buzz\Browser rather than a profiler-specific wrapper, the decorator did not apply — the panel will be empty and it will look like your HTTP calls aren't happening.
• Clear the cache after registering the bundle. Symfony container caching means a mis-ordered registration looks like "the bundle does nothing."
• Service id collisions. If you have more than one Buzz client (e.g., an internal API client and a public one), the profiler will only see the one aliased to buzz. Profile the others by explicitly decorating them with the tracing client from juliendidier/buzz-profiler-bundle.
• Manual fallback. If the glue bundle misbehaves, drop it and decorate buzz yourself with a decorates: buzz service definition. You lose nothing — the underlying profiler bundle is what does the real work.
• Dev-only. Never register this in prod; the collector accumulates request/response bodies in memory and the panel is unreachable anyway.
• Debugging an empty panel: check (1) bundle is in the dev kernel, (2) the buzz service is decorated, (3) the request actually went through the injected service, (4) cache was cleared, (5) the profiler toolbar itself is enabled (web_profiler toolbar: true).
• For new work, skip it. Use Symfony HttpClient (profiled natively) or, in Laravel, Illuminate\Support\Facades\Http with Telescope. The only reason to touch this package is maintaining an app already pinned to Buzz — in which case vendor the two files, pin them, and plan the exit.