Performance Issue with 1.6.0 #101
Comments
|
Hmm, could you run a profiler (xdebug profile) and compare 1.5.0 and 1.6.0? I only see this diff: laminas:7f04939...laminas:d74d2da Unless the bridge config being processed is gigantic, I don't understand how this could happen 🤔 |
|
Will this snippet do? It's taken from my development environment and sorted by Duration Exclusive desc. I have a snippet of the same report using 1.5.0 further down. The Replacements:_construct is much faster in that report so appears much further down in the report when sorted this way. This is its entry, it only gets called once, while with 1.6.0 it is getting called 6836 times.
Zend Server Z-Ray - Request function statistics with FrameworkBridge 1.6.0Total rows: 1635
Zend Server Z-Ray - Request function statistics with FrameworkBridge 1.5.0Total rows: 1634
|
|
Hmm, interesting how Can indeed see how the inclusive The bridge keeps re-initializing itself each time too. |
|
@weierophinney I don't have clear insight on how the replacements logic is initialized: is the bridge supposed to scan the config each time? |
|
I assume this was collected on the test suite run? I suspect you might have module manager events not getting reset between tests, which results in more and more listeners attached to laminas-zendframework-bridge/src/Module.php Lines 19 to 24 in c1ca658 This would result in ever increasing amount of bridge's config post processor calls and twice the amount of Replacement constructor calls. |
|
No, not a unit test. This was an actual API request to the application on my development environment. |
|
This is very strange, since config post processing should ever happen once. And with config caching enabled it should not happen at all after the first call. In the call statistics you provided number of invocations for laminas-zendframework-bridge/src/Module.php Lines 41 to 46 in d74d2da And sure thing there are and |
|
What is worse, each time |
|
@cvigorsICBF unless you need this package I would recommend to get rid of it entirely since it is a Zend Framework transition helper. "replace": {
"laminas/laminas-zendframework-bridge": "*"
},This would also remove autoloading overhead it is causing. |
|
I'd like to remove it, as I see that it has been removed from other libraries like Form, View, Cache. I'll need to upgrade those libraries. It still seems to be a requirement of API-Tools. |
|
As @Xerkus notes, the instantiation of
The whole point of the listener is to scan config and rewrite ZF-related keys to their Laminas equivalents, and it only needs to be done once. The main change from 1.5.0 to 1.6.0 is that we check for configuration related to the bridge itself and use that to seed the replacements rules before running them; otherwise, the way it works is identical to the previous version, and checking for that configuration is almost negligible in terms of performance (it literally pulls a single key, and then makes sure it is an array of non-empty keys and non-empty values; if you don't have any defined, it's a no-op). If you are not defining that configuration, its usage is essentially identical, and shouldn't change much in performance. (The only thing I'm not happy about is the fact I have to initialize the As such, I'd love to know:
As for Laminas API Tools... the most recent versions of those libraries either have dropped the requirement, or likely can. Do you know which ones are bringing it in? You can use |
|
Does #102 solve this? |
It should; @cvigorsICBF , can you test 1.6.1, please? |
|
Thankfully not in development mode in production. Config cache is disabled though: The info I would have been providing so far would be from development where development mode is enabled. API Tools does seem to require it, api-tools-api-problem for example has it included in its composer.json composer why laminas/laminas-zendframework-bridge |
Yes, I am going to say that it does. |
|
Thanks you for the report. |
|
Thanks you all for the very quick response to this issue. It is very much appreciated. |
BC Break Report
Summary
The zendframework-bridge is a dependency of other libraries we use, e.g. API Tool, Laminas Cache, Laminas Form, and after doing a composer update from 1.5.0. to 1.6.0, performance of our application has taken a significant hit.
Each request to the application takes around 1 second longer and phpunit tests run time has increased significantly.
Previous behavior
Application performance was good
PHPUnit tests completed < 2 mins
Current behavior
Application performance has degraded significantly, with requests taking an extra second to process
PHPUnit tests complete in 10 mins.
How to reproduce
The best way to reproduce is to run the unit tests.
The unit tests that uses Laminas Test's AbstractControllerTestCase->dispatch() show a significant reduction on time to complete.
Downgrading to zendframework-bridge 1.5.0 allows the unit tests to complete in the expected time.
I will look into providing a working example of the issue, but it will be next week before I can do this.
As this is a widely used library, and seems to cause a performance reduction and not a break, I think others may be experiencing poorer performance by their applications, I wanted to get this issue raised as soon as possible
The text was updated successfully, but these errors were encountered: