Skip to content

revert #30525 due to performance penalty #32165

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 26, 2019
Merged

revert #30525 due to performance penalty #32165

merged 1 commit into from
Jun 26, 2019

Conversation

bendavies
Copy link
Contributor

@bendavies bendavies commented Jun 25, 2019

Q A
Branch? 4.3
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

This reverts #30525, because it introduced a large performance penalty.

Here is the effect of that PR when I upgrade my Api Platform project from 4.2.9 to 4.3.1:
https://blackfire.io/profiles/compare/28bfbc61-3649-4896-bd03-7201239134cd/graph?settings%5Bdimension%5D=wt&settings%5Bdisplay%5D=landscape&settings%5BtabPane%5D=nodes&selected=Symfony%5CComponent%5CVarExporter%5CInternal%5CExporter%3A%3Aexport%403&callname=main()

The reverted PR targeted master. This should go in 4.3?

@bendavies bendavies requested a review from sroze as a code owner June 25, 2019 09:08
@bendavies bendavies changed the base branch from master to 4.3 June 25, 2019 09:08
@nicolas-grekas
Copy link
Member

Master then is 4.3 now so yes, this should target 4.3. But can we have a deeper analysis so that we better understand what's going on? The reverted PR had merits I suppose.

@dunglas
Copy link
Member

dunglas commented Jun 25, 2019

I'm in favor of reverting in the meantime, this change looks to impact badly most API Platform projects.

@bendavies
Copy link
Contributor Author

From the profile, it seems the reverted PR caused many many cache lookups and writes.

@nicolas-grekas nicolas-grekas added this to the 4.3 milestone Jun 25, 2019
@fabpot
Copy link
Member

fabpot commented Jun 26, 2019

Thank you @bendavies.

@fabpot fabpot merged commit 3d37cc9 into symfony:4.3 Jun 26, 2019
fabpot added a commit that referenced this pull request Jun 26, 2019
This PR was merged into the 4.3 branch.

Discussion
----------

revert #30525 due to performance penalty

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | yes
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets |   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        |

This reverts #30525, because it introduced a large performance penalty.

Here is the effect of that PR when I upgrade my Api Platform project from 4.2.9 to 4.3.1:
https://blackfire.io/profiles/compare/28bfbc61-3649-4896-bd03-7201239134cd/graph?settings%5Bdimension%5D=wt&settings%5Bdisplay%5D=landscape&settings%5BtabPane%5D=nodes&selected=Symfony%5CComponent%5CVarExporter%5CInternal%5CExporter%3A%3Aexport%403&callname=main()

The reverted PR targeted master. This should go in 4.3?

Commits
-------

3d37cc9 revert #30525 due to performance penalty
@bastnic
Copy link
Contributor

bastnic commented Jun 26, 2019

THANKS!

FYI, a cache warmup with symfony 4.3 with apip : https://blackfire.io/profiles/d20d4c31-f68c-406a-b691-94dba2422d6b/graph. With both this problem and this one #32188.

Yep, 16mn cache warmup... 14 for this one and 1.5 for the new PR (#32188).

Deepin Capture-écran_zone de sélection _20190626150630

@fabpot fabpot mentioned this pull request Jun 26, 2019
@deviantintegral
Copy link
Contributor

From the original issue I filed at #29977:

Is optimizing for the "most properties will need to be extracted case" best?
Are there commonly used cached backends where rewriting the same cache key like this will cause problems?

Do we have any idea if either one of these cases is what's happened? In our case, it's the opposite, and without the original PR we see additional seconds in latency. It'd be great if we could figure out something that handles both cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants