Details

    • Type: Bug Bug
    • Status: Confirmed
    • Priority: High High
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0-beta4
    • Fix Version/s: None
    • Component/s: Caching
    • Labels:
    • Environment:

      2.0.0-beta4

      Description

      Hello,

      Trying 2.0.0-beta4 I suspect an issue with Memcache

      Loading Admin UI with Memcached is way way slower than Redis or just filesystem.

      It is easily testable with Launchpad. Here is some screenshot.

      To switch from one to another I just changed the ENV vars.
      From:

                  - CACHE_POOL=cache.memcached
                  - 'CACHE_DSN=memcache:11211'
      

      to

                  - CACHE_POOL=cache.redis
                  - 'CACHE_DSN=redis:6379'
      

      As Symfony Cache seems to be used, the only reason would be that now,
      data stored in the Cache are bigger and Memcache does not really like that.

      Look the difference Memcache on the right, Redis on the left

      Also I have done a Backfire profile:
      https://blackfire.io/profiles/0ea71da7-a023-46ec-a69f-3580b8e75552/graph
      => getMulti of Memcached is slow that is the issue.

      1. Memcached-EmptyCache.png
        654 kB
      2. Memcached-SecondLoad.png
        579 kB
      3. Redis-EmptyCache.png
        438 kB
      4. Redis-vs-Memcached.png
        1.14 MB
      5. Redis-vs-Memcached-2.png
        829 kB
      6. Refis-SecondLoad.png
        393 kB

        Activity

        Hide
        André Rømcke added a comment - - edited

        For those coming here looking for a quick solution: TL;DR; move to Redis! (it's the officially recommended cache solution now)

        For those wanting to read the fine print and possible help solve the issue with Memcached, read on.

        It seems that Memcached has issue with cache lookups for things that are not in cache yet, so tags lookup results in lookups for items that does not exists until the given tags gets invalidated. This we might be able to improve over time, but it's a Symfony issue on how it deals with tags which causes issues with Memcached as opposed to a eZ issue so it won't happen anytime soon.

        Another possible issue to be on the lookout for is slowness errors when cache items being larger then memcached 1mb limit, meaning they don't get cached: https://groups.drupal.org/node/116764

        Anyone able to verify this, and if so share some info?

        • Verify that it's only the tags lookup issue
        • If however cache size is also the culprit, then report which cache keys have this issue so we can reverse which cache code is responsible. A bit on the side, but it might help to make sure igbinary or msgpack is installed as php-memcached will take advantage for more compact serialization decreasing network traffic and cache object size. (same is also true for php-redis)
        Show
        André Rømcke added a comment - - edited For those coming here looking for a quick solution: TL;DR; move to Redis! (it's the officially recommended cache solution now) For those wanting to read the fine print and possible help solve the issue with Memcached, read on. It seems that Memcached has issue with cache lookups for things that are not in cache yet, so tags lookup results in lookups for items that does not exists until the given tags gets invalidated. This we might be able to improve over time, but it's a Symfony issue on how it deals with tags which causes issues with Memcached as opposed to a eZ issue so it won't happen anytime soon. Another possible issue to be on the lookout for is slowness errors when cache items being larger then memcached 1mb limit, meaning they don't get cached: https://groups.drupal.org/node/116764 Anyone able to verify this, and if so share some info? Verify that it's only the tags lookup issue If however cache size is also the culprit, then report which cache keys have this issue so we can reverse which cache code is responsible. A bit on the side, but it might help to make sure igbinary or msgpack is installed as php-memcached will take advantage for more compact serialization decreasing network traffic and cache object size. (same is also true for php-redis )

          People

          • Assignee:
            Unassigned
            Reporter:
            Sébastien Morel
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: