Apc Profiler Bundle Laravel Package

Getting Started

The stealth35/apc-profiler-bundle is a Symfony 2–era bundle that surfaces APC's built-in profiling/cache data (the apc.php UI) inside a Symfony app, so you can inspect opcode cache stats, memory usage, and per-request profiling without dropping a standalone apc.php file into your web root.

Minimal setup:

1. Install the extension first. This bundle is useless without APC compiled into PHP (apc.enabled=1, apc.enable_cli if you profile console). It targets legacy APC, not APCu — APCu ships a different apc.php and lacks the full profiler.
2. Require the bundle (expect a dev constraint — it is not maintained for modern Symfony):

   composer require --dev stealth35/apc-profiler-bundle
   

3. Register it in app/AppKernel.php, dev/test only:

   if (in_array($this->getEnvironment(), ['dev', 'test'])) {
       $bundles[] = new Stealth35\ApcProfilerBundle\ApcProfilerBundle();
   }
   

4. Find the route. After registering, run php app/console router:debug | grep -i apc — the bundle exposes an apc.php-style page under a route (typically something like /apc or /apc_profiler) that proxies the extension's profiling output.
5. First use case: open the route in dev, hit a few pages, then reload it to see per-request profile entries and opcode cache hit/miss ratios. That is the whole value proposition — a Symfony-owned, permission-guarded view of APC data instead of a public apc.php.

If you are on Symfony 3+/4+, do not start here. Confirm the bundle even boots before investing time; otherwise jump straight to the alternatives in the Gotchas section.

Implementation Patterns

Dev-only, route-guarded access. The single most important pattern: the bundle exposes profiling data over HTTP, so keep it out of prod (bundle registration + route) and, in shared dev environments, protect the route with your security.yml firewall or a basic-auth rule at the web server. Treat it exactly like _profiler.

Use it as a complement to the Web Profiler, not a replacement. The Symfony profiler tells you what your code did; APC's view tells you what the opcode cache and shared memory did — memory fragmentation, cache full events, hit/miss ratio, expunges. Workflow:

1. Benchmark a request in the Web Profiler for query/time breakdown.
2. Cross-check APC stats for cache churn (Cache full count, Expunges) — if these climb, your opcode cache is undersized regardless of app-level optimization.
3. Compare two branches by clearing APC between runs (apc_clear_cache() + apc_clear_cache('user')) so numbers are comparable.

Cache-tuning loop. Enable the bundle, run a representative request set, then adjust apc.shm_size, apc.num_files_hint, and apc.stat and re-measure. Because apc.stat=1 revalidates every file, profiling in a setup with apc.stat=1 will not reflect your production-with-apc.stat=0 numbers — mirror prod ini settings in your dev vhost for meaningful readings.

Integration tip — reuse the existing toolbar. If the bundle registers a data collector, expect APC stats to appear in the Symfony toolbar in dev. Use the toolbar for at-a-glance cache health during normal development and only deep-link to the full page when something looks wrong.

CI/testing note. Do not gate tests on APC being present. Detect the extension (extension_loaded('apc')) and skip profile-dependent assertions; the bundle has zero dependents and almost no community signal, so do not let it become a hard test dependency.

Gotchas and Tips

• Legacy and effectively unmaintained. 19 stars, 0 dependents, low health score. Treat it as a convenience wrapper you may need to patch, not a dependency you can rely on. Pin an exact version and vendor-fork it if needed.
• APC ≠ APCu ≠ OPcache. Most modern stacks run OPcache + APCu, and APCu's apc.php is not the same profiler. If your app is on OPcache, this bundle will report nothing useful. The practical alternatives are the Symfony Web Profiler, Tideways/XHProf, or Blackfire for request-level profiling.
• CLI and FPM caveats. APC historically required a threaded/mod_php SAPI for shared memory; under php-fpm behaviour and CLI, profiler data may be empty or per-process. Set apc.enable_cli=1 if you expect console data, and remember CLI and FPM have separate caches — stats are never combined.
• The profiler output is cached state, not a live trace. Numbers reflect whatever requests hit that worker since the last clear. Always clear before a measurement and note the worker pool size — with multiple FPM workers you are sampling one process's view, not the whole app.
• apc.stat skews results. Revalidation on every request inflates file-system work massively; do not benchmark tuning decisions with apc.stat=1 if prod uses 0.
• Security footgun. A reachable apc.php-style page leaks file paths, config, and cache contents. Never expose it in prod or on a public dev host; block by IP at the server if you cannot rely on Symfony security.
• Router/config quirks. Symfony 2 bundles of this era often auto-load routing via routing.yml imports (resource: "@ApcProfilerBundle/Resources/config/routing.xml"). If the route 404s, check both bundle registration and the routing import — a common reason people conclude the bundle is "broken."
• Extension points are thin. Expect to extend the controller or override the template to add auth/headers. Keep any such override in your own bundle so a composer update cannot silently wipe it.
• Debugging checklist when data is blank: is apc.enabled=1? is it legacy APC rather than APCu? are you on the same SAPI as the traffic you are profiling? did you clear the cache after deploying? did you look at the right worker? Nine times out of ten it is APC-vs-APCu or SAPI mismatch, not the bundle.