DDC-2832: Performance issues with APCu #3537

New Issue

admin · 2026-01-22T14:21:48+01:00

admin commented

2026-01-22 14:21:48 +01:00

Originally created by @doctrinebot on GitHub (Dec 2, 2013).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user mnapoli:

We have stumbled across a very weird performance issue lately. It's kind of hard to explain, and I struggle to understand, but maybe it will ring a bell to someone.

Here is our cache configuration:

$doctrineConfig = new Doctrine\ORM\Configuration();
// ...

switch (APPLICATION_ENV) {
    case 'test':
    case 'production':
        $cache = new ApcCache();
        break;
    default:
        $cache = new ArrayCache();
        break;
}

$doctrineConfig->setQueryCacheImpl($cache);
$doctrineConfig->setResultCacheImpl($cache);
$doctrineConfig->setMetadataCacheImpl($cache);

In *test* & prod environment, we observe the performance issue. In dev environment, no performance issue.

Furthermore, if I comment out just setMetadataCacheImpl, then no performance issue in test & prod.

Now we have New Relic, so we have a bit of profiling, and here is what it shows:

... skipping to interesting bit
88s Doctrine\ORM\PersistentCollection::matching
  88s Doctrine\ORM\Persisters\BasicEntityPersister::loadCriteria
    43ms Orga_Cell - SELECT (MySQL query)
    88s Doctrine\ORM\Internal\Hydration\AbstractHydrator::hydrateAll
      88s Doctrine\...\SimpleObjectHydrator::hydrateAllData
        50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        47ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        59ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        52ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        51ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        45ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        58ms Doctrine\...\SimpleObjectHydrator::hydrateRowData

(the stack trace is the one provided by New Relic, maybe their tool shows an incomplete stack trace? However judging by the content of the method and the numbers of rows, it seems correct)

As you can see, the numbers don't add up at all! A dozen of sub-calls takin 50ms each doesn't add up to a 80 seconds method call.

Keep in mind that when I disable the MetadataCache, then 80s turns into _{300ms and everything works as expected. That's a lot of difference.}

So this is very weird.

Few more information:

the operation runs in a worker, not a HTTP request
we see the same behavior in every other operation, not just this one
the PHP process uses 100% CPU of one core
the RAM is not full ( 50% used)
APCu is not full
APCu is at last version

We are going to try to replace APCu with Memcached and see if it improves things :/ I have no idea if the problem is related to Doctrine or APCu.

Any idea?

Originally created by @doctrinebot on GitHub (Dec 2, 2013). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user mnapoli: We have stumbled across a very weird performance issue lately. It's kind of hard to explain, and I struggle to understand, but maybe it will ring a bell to someone. Here is our cache configuration: ``` $doctrineConfig = new Doctrine\ORM\Configuration(); // ... switch (APPLICATION_ENV) { case 'test': case 'production': $cache = new ApcCache(); break; default: $cache = new ArrayCache(); break; } $doctrineConfig->setQueryCacheImpl($cache); $doctrineConfig->setResultCacheImpl($cache); $doctrineConfig->setMetadataCacheImpl($cache); ``` In **test\* & *prod** environment, we observe the performance issue. In dev environment, no performance issue. Furthermore, if I comment out just **setMetadataCacheImpl**, then no performance issue in test & prod. Now we have New Relic, so we have a bit of profiling, and here is what it shows: ``` ... skipping to interesting bit 88s Doctrine\ORM\PersistentCollection::matching 88s Doctrine\ORM\Persisters\BasicEntityPersister::loadCriteria 43ms Orga_Cell - SELECT (MySQL query) 88s Doctrine\ORM\Internal\Hydration\AbstractHydrator::hydrateAll 88s Doctrine\...\SimpleObjectHydrator::hydrateAllData 50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 47ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 59ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 52ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 51ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 45ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 58ms Doctrine\...\SimpleObjectHydrator::hydrateRowData ``` (the stack trace is the one provided by New Relic, maybe their tool shows an incomplete stack trace? However judging by the content of the method and the numbers of rows, it seems correct) As you can see, the numbers don't add up at all! A dozen of sub-calls takin 50ms each doesn't add up to a 80 seconds method call. Keep in mind that when I disable the MetadataCache, then 80s turns into <sub>300ms and everything works as expected. That's a lot of difference. So this is very weird. Few more information: - the operation runs in a worker, not a HTTP request - we see the same behavior in every other operation, not just this one - the PHP process uses 100% CPU of one core - the RAM is not full (</sub> 50% used) - APCu is not full - APCu is at last version We are going to try to replace APCu with Memcached and see if it improves things :/ I have no idea if the problem is related to Doctrine or APCu. Any idea?

admin added the Bug label 2026-01-22 14:21:48 +01:00

admin closed this issue

2026-01-22 14:21:48 +01:00

admin commented

2026-01-22 14:21:48 +01:00

@doctrinebot commented on GitHub (Dec 2, 2013):

Comment created by mnapoli:

FYI: switching from APCu to Memcached solved the problem. So the problem really is with APCu.

Now is that a problem in Doctrine or APCu?

@doctrinebot commented on GitHub (Dec 2, 2013): Comment created by mnapoli: FYI: switching from APCu to Memcached solved the problem. So the problem really is with APCu. Now is that a problem in Doctrine or APCu?

admin commented

2026-01-22 14:21:49 +01:00

@doctrinebot commented on GitHub (Dec 13, 2013):

Comment created by @beberlei:

Cannot really be our issue. The APCu driver is really simple and not doing magic.

@doctrinebot commented on GitHub (Dec 13, 2013): Comment created by @beberlei: Cannot really be our issue. The APCu driver is really simple and not doing magic.

admin commented

2026-01-22 14:21:49 +01:00

@doctrinebot commented on GitHub (Dec 13, 2013):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Dec 13, 2013): Issue was closed with resolution "Invalid"

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#3537