Hello,
Currently, Api Platform does not ship with any cache warmers.
This typically makes the first request to each route slow as a cache is primed on demand. (hitting one api route does not prime all routes, so the effect is compounded).
I've just been hit by a stampede in production because of this, causing a small outage, so not ideal.
The following classes are candidates for being warmed:
However, this is not so easy.
The starred (*) factories take an array of $options, which are currently not known in the CLI context, and are provided from the router/current request, and will vary per route.
Generally speaking, most of the slowness is due to reading from PHPDoc. So, I think it makes sense if we could have a specialized cache for PHPDoc, and we could add a cache warmer for that. (But probably it should only be used in production?)
That assessment looks correct.
Here is a profile of 1st vs 2nd request (with an already warmed prod cache)
https://blackfire.io/profiles/compare/2517aaf4-8564-4137-b15c-dec2025568e3...4243edce-efdd-4198-be41-7d77f5a80636/graph
It's a bit hard to look at because of all the decoration, but the majority of the time is spent at phpDocumentor\Reflection\Types\ContextFactory, so ApiPlatform\Core\Bridge\Symfony\PropertyInfo\Metadata\Property\PropertyInfoPropertyMetadataFactory
relevant discussion: https://github.com/api-platform/core/issues/2593
Yep @soyuka, same problems.
In dev mode, phpDocumentor\Reflection\Types\ContextFactory is called too much time because all the stack is made to be cacheable in single switch mode. The same file is read again again and again. Just adding a static cache per default reduce every call in dev mode and the first call in prod mode.
I will just leave it here:


Warmers are really needed ;)
So, this is the first call? Then it's cached? Thanks!
never cached without api_platform.metadata_cache set to true. Cf #2593, in my case it's 1600 calls for only 78 files. Just adding a simple static cache in the class show the enormous performance gain.
IMO we should use cache in dev. I plan to take a look very soon. https://github.com/api-platform/core/issues/2593#issuecomment-472436211
Update: See https://github.com/api-platform/core/pull/2629
Hmm... Symfony PropertyInfo's PhpDocExtractor already has a local cache for DocBlocks: https://github.com/symfony/symfony/blob/v4.2.4/src/Symfony/Component/PropertyInfo/Extractor/PhpDocExtractor.php#L36-L39
FYI, https://github.com/symfony/symfony/pull/32188 got merged, so phpdocextractor is no more an issue since Symfony 4.4
Note: having cache warmers is also a requirement for running in read-only environments, which is the direction Symfony is trying to move toward.
Most helpful comment
Generally speaking, most of the slowness is due to reading from PHPDoc. So, I think it makes sense if we could have a specialized cache for PHPDoc, and we could add a cache warmer for that. (But probably it should only be used in production?)