Core: Let's talk about performances

[dupuchba]

Hi everyone,

I was playing with the bundle and I did a backfire.io profiling which was very interesting.
I just did a GET /poeple/3 API call with php 5.5.18 (no cache).

Note that Nelmio doc generation takes almost 30% of CPU time but I wasn't asking for it (we load it everytime).

I was curious to see your point of view about that.

Thank's everyone.

link here => https://blackfire.io/profiles/74457ce7-817a-4266-ad11-87c498d18762/graph

[dunglas]

The heavy operation is the PHPDoc parsing but this not especially related to NelmioApiDoc. It occurs for populating metadata :

• property type guessing (using the property info library)
• textual description for the Hydra documentation (so used by NelmioApiDoc of installed)

This an expensive operation but in production you should use the cache (see the performance chapter in the doc).

[dupuchba]

@dunglas I know (and I warned ^^) that caching metadata is a must have but I am still curious about nelmio optimization.

• Do we really need it on each request ?

[dunglas]

Have you enabled the Nelmio cache? Can you make another profile to show the difference when Nelmio is not installed?

[dupuchba]

@dunglas I'll do it next week, like you I really need holidays ^_^

[rolebi]

related to #198 ?

[theofidry]

@rolebi not really, #198 is really more on guidelines and doc. This case is an optimization of the bundle.

[Simperfit]

What is the state of this issue ?

[theofidry]

@Simperfit we need a good benchmark showing we can handle 2000 req/s just fine :P

[teohhanhui]

Usually, serialization takes up the bulk of the time. If we have generated normalizers (symfony/symfony#17516), that'll be a huge win. Or perhaps it may be possible to introduce some cache layer to prevent re-generating the serialized string each time?

[theofidry]

@teohhanhui make custom serializers and a property accessor for the benchmark 😄

[soyuka]

Usually, serialization takes up the bulk of the time.

+1, for example (development mode):

[soyuka]

Theoretically, if we know we have the same pattern per resourceClass, we should be able to cache some undergoing in the serializer no?
Also, if we have a collection, we know that it's items are deserializing the same way, might be room for improvement on this side.

[dunglas]

Yes, but we can do this directly in the Symfony component (a resource class is just a class after all). It will benefit for all usages of the Serializer.

[dunglas]

Btw, profiles in dev mode are biased because caches of the Serializer component are not enabled.

[soyuka]

More data

simple query, no relations, ~8k items, apcu cache enabled (dev mode because I need the profiler but I forced the cache)

https://blackfire.io/profiles/325404d0-c782-4f05-88ed-4676b6c3368b/graph

[soyuka]

We need to cache getIriFromItem because it calls getIdentifiersFromItem which is heavy in metadata parsing.

with #997 :

[Simperfit]

Since the PR has been merged I think this can be closed we improved alot the performance, if you have any idea on how to improve it more, PR are welcome ! :)