Skip to content
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

Performance degradation when updating from 10.17.0.7 to 10.19.0.9 #859

Open
adri opened this issue Mar 19, 2024 · 13 comments
Open

Performance degradation when updating from 10.17.0.7 to 10.19.0.9 #859

adri opened this issue Mar 19, 2024 · 13 comments

Comments

@adri
Copy link

adri commented Mar 19, 2024

Description

When updating from 10.17.0.7 to 10.19.0.9 we saw an average response increase of ~10ms, from ~37ms to ~47ms. After reverting the response time decreased.

SCR-20240319-nqxl

Steps to Reproduce

I don't know

Expected Behavior

No performance impact

Your Environment

Symfony v7.0
PHP 8.3.2
Debian 12

@adri adri added the bug Something isn't working label Mar 19, 2024
@newrelic-php-agent-bot
Copy link

Hi @adri! Thank you for bringing this to the team’s attention. Could you contact New Relic support by following these steps. This way we will be able to gather additional details about the issue at hand. If your subscription level does not include technical support support plan, the other option available to customers with free plans is to use New Relic’s community support channel: Explorers Hub. For all available options on how to get support, please see these resources.

@ruudk
Copy link

ruudk commented Mar 21, 2024

@newrelic-php-agent-bot What does that performance degradation has to do with our support plan. We are paying customers. We report that your latest SDK degrades performance. And the previous did not. Clearly something is off.

@zsistla
Copy link
Contributor

zsistla commented Mar 21, 2024

@ruudk thanks for the question, and we'll try to clear up the intent. The performance degradation has nothing to do with the support plan and is an issue we are investigating. Sometimes (as in this case), in order to investigate further, we need certain details from customers that cannot be shared in a public repo. Our method for collecting this data in a manner to provide privacy and security to the customer is via our support channel which can be reached in various ways (as detailed in the bot message).

@slt
Copy link

slt commented Apr 16, 2024

We noticed this when our systems were upgraded from v10.17.0.7 to v10.18.0.8, our endpoints were performing dramatically worse, even basic nothing endpoints like health checks.

We build our base docker containers with the latest versions nightly so within a few days of the v10.18.0.8 release it was very clear something had gone wrong.

This is a health check endpoint that does nothing but return a string

image

This is a more involved endpoint which is usually consistently <60ms

image

Given the change log, we thought perhaps it was due to JIT finally being available.

New features

PHP's Just-In-Time Compilation is no longer disabled when the PHP Agent is enabled. PHP has this on-by-default starting with PHP 8.0.

We have since tested with many different configurations of JIT, including JIT off and it seems to us at least this performance regression is due v10.18.0.8 itself and not JIT. It seems the same issue is also present in v10.19.0.9

We've rolled back and pinned to v10.17.0.7 and are watching this issue & release announcements hoping for a fix, just commenting here to give it weight.

If it helps, our newrelic.ini has long had the transaction_tracer disabled to minimise performance impacts

newrelic.transaction_tracer.enabled = false
newrelic.transaction_tracer.detail = 0

@ebeltramo96
Copy link

We noticed the same as soon as we merged the new version, we had to roll it back to v10.17.0.7

@zsistla
Copy link
Contributor

zsistla commented Apr 19, 2024

@slt @ebeltramo96
Would you be please be able to provide more details about your system:
OS
PHP version(s)
frameworks in use

If you follow the bot instructions, our support team could work with you to collect additional information such as debug logs and other sensitive system info in a secure manner.

@ACenterA
Copy link

ACenterA commented May 7, 2024

10.20.0.10 has been released:

10.20.0.10

Anyone knows if this bug still occurs with that version?

@ppp0
Copy link

ppp0 commented Jun 28, 2024

Clearly to be seen after upgrading from 10.17.0.7 to 10.22.0.12, albeit not so dramatic as reported above (~5%)
image

@adri
Copy link
Author

adri commented Jul 17, 2024

Unfortunately upgrading to 10.22.0.12 still results in +12-13ms response times for us.
SCR-20240717-kvrm

@ruudk
Copy link

ruudk commented Sep 12, 2024

Would you be please be able to provide more details about your system: OS PHP version(s) frameworks in use

If you follow the bot instructions, our support team could work with you to collect additional information such as debug logs and other sensitive system info in a secure manner.

OS: Debian 12 bookworm
PHP: PHP 8.3.11
Framework: Symfony 7.1

@zsistla I just created a Case #00224017

@ZNeumann ZNeumann removed the bug Something isn't working label Oct 7, 2024
@workato-integration
Copy link

@lavarou
Copy link
Member

lavarou commented Oct 8, 2024

As @slt pointed out, release 10.18.0.8 added support for PHP’s Just-In-Time Compilation. This support required changes to how New Relic PHP Agent hooks into Zend Engine. I.e. for PHPs 8.0+ it no longer uses the method of overriding zend_execute hook but it uses observer API instead. This change came with an increased overhead. New Relic PHP Engineering team is looking into options to reduce the overhead when observer API is used.

@flokain
Copy link

flokain commented Oct 24, 2024

thx for looking into this. This is blocking us from using distributed tracing, so we hope this is fixed soon.

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

No branches or pull requests