3

I'm struggling to identify the cause of 404's when using the Symfony2 profiler. I'm using Symfony 2.3 LTS.

I have the profiler enabled on our development environments and the issue is reproducible across several developer machines. Our configuration for the profiler is:

framework:
    profiler:
        dsn: "memcached://localhost:11211"
        enabled: true
        lifetime: 86400 # Keep profiles for a day at most

On some - but not all - pages we are seeing an error as follows:

**The page at https://local.dev says:**

An error occurred while loading the web debug toolbar (404: Not Found).

Do you want to open the profiler?

OK / Cancel

There are 5 404 requests for https://local.dev/_wdt/<token> and clicking Cancel takes us to a "Token not found" page at https://local.dev/_profiler/<token>

I've tried stepping through the code and so far have determined:

  • If I place a breakpoint in the ProfilerListener at onKernelResponse I can identify the unique parent token.
  • After $this->saveProfiles($profile);, I can manually query memcached using telnet for the token and receive the expected serialised array.
  • If I step through the code, I eventually find myself in TraceableEventDispatcher. In saveInfoInProfile there is a loop over the children items of the profile which calls $this->saveInfoInProfile($child, true);. There are 6 children items in my case here, and the first 5 are persisted as expected.
  • After 5 iterations of saveInfoInProfile the original token can be retrieved via telnet and still appears.
  • On the 6th (last) iteration, a call is made in MemcachedProfilerStorage to $this->getMemcached()->set($key, $value, time() + $expiration);.
  • Before this call is made, I can still retrieve the original token via telnet.

However, after this call is made, the telnet request for the original token returns empty. The key for this call is distinct from the original token, so it is not being overwritten.

This in turn triggers the 404 error I'm seeing client side.

Some additional potentially useful information:

  • The toolbar does work on some pages. It's pages within our admin interface that are having 404 toolbar errors.
  • We're using ESI and using Twig.
  • We're making calls to {% render(controller("ABundle:AController:anAction", {some:params})) %}
  • Eliminating one of the render methods from one of our Twig templates resolves the issue.
  • Reinstating that render method and commenting out a different one will also resolve the issue. Implying there are too many children or too much data (or something similar).

What could be causing this issue? How would I identify a fix?

As an aside, using the FileProfiler works correctly.

Thank you for any assistance!

edhgoose
  • 887
  • 8
  • 26
  • I'm guessing you have already checked the firewall/route yml files if they're configured correctly? (The 404 errors might be related to missing/commented routes in the `routing_dev.yml`) – tftd Jul 10 '15 at 13:47
  • The profiler does work on some pages, so the routing must broadly be working. I've further updated the question to include that snippet and some additional investigation which suggests the problem being contributed to by the render method in Twig. – edhgoose Jul 10 '15 at 14:11

1 Answers1

2

I have discovered the solution after much head banging.

It seems that due to the fact we're using many render's within our templates, lots of profiler data is being collected.

This profiler data is being pushed into memcached. And, because there is a lot of it, other data is being evicted. I discovered this by running: 

echo stats | nc 127.0.0.1 11211 | grep evic

And everytime I loaded a page, I saw the evicted_unfected and evictions climb.

The solution was to increase the size of memcached's memory pool from the standard 64MB to 256MB (or any other size).

This is done by passing the -m option at runtime.

edhgoose
  • 887
  • 8
  • 26
  • It wouldn't have crossed my mind this could be the problem... Thanks for sharing! :) – tftd Jul 10 '15 at 15:26