Comments (6)
Hi all.
I went through all the performance PRs and issues here, but none of them (1, 2) was really fully right or was fully solving the issue for me.
So, I went ahead and created my own fork (partly based on other suggestions here). Parsing the huge Stripe OpenApi Spec is back to ~1 second.
Fork: master...NickSdot:cebe-php-openapi:improve-performance
An important fact, one major performance hit – in my case – is not solely caused by cebe/php-openapi
but by a bug in symfony/yaml
which we depend on here. I am trying to get this fixed upstream. It sadly is still not merged, so I currently override the class in question in my project.
Parsing the Stripe spec in fact ran for ages and eventually failed. The actual cause was kinda hard to spot. This is, because the cebe/php-openapi
(understandably) was not validating for this external misbehaviour. Hence, I want to especially highlight this change in my fork b65633f
Maybe someone is interested to try my fork and see if it will solve your issues as well. I am keen to PR this here or to any fork. Just let me know.
cc: @cebe, @kohlerdominik, @marcelthole, @Aribros
Cheers
from php-openapi.
Thanks for the feedback. I also have performance issues on a big project of mine but I had no time to look into this yet. The fact that it takes much less time on your fork is some valuable info . I'll check that out.
from php-openapi.
Hi @cebe
Looks like the fix from @marcelthole makes things significantely faster here. Could you already have a look at it?
However, @marcelthole your fix introducing caching for references. But could you also find out, WHY resolving references is now so much slower than in 1.4?
from php-openapi.
not exactly. If i look into the diff one part is the huge amount of ReferenceContext::reduceDots
calls in the current version.
Here the difference of the xdebug trace
from php-openapi.
I confirm performance issues.
I have studied the code and have a suggestion: is it possible, in addition to the built-in ReferenceContextCache
, to have a fallback to the user cache? Then the results of parsing and resolving $ref
will become available between library calls - and this answers exactly the reason that creates performance problems, right?
I mean, it's not enough to have a $ref
-cache INSIDE one library call, it's necessary that the results are shared BETWEEN calls - and this is achieved by relying on a custom cache.
In my opinion, it should be possible to pass to the new ReferenceContext
user cache (for example, PSR-6 CacheItemPoolInterface
). I suppose if a custom cache is passed to each ReferenceContext
constructor, then this should solve problems with the performance of parsing and resolving $ref
BETWEEN calls.
UPD I found that in my case, performance problems were caused by frequent cache misses due to https://gitlab.com/yii2-extended/yii2-psr6-cache-bridge/-/issues/3 .
Therefore, please consider all mine of the above as an abstract feature suggestion, not a bug report.
from php-openapi.
Quick heads up that the Symfony bug I was referring to in my previous comment got merged: symfony/symfony#52408
from php-openapi.
Related Issues (20)
- Symfony 6 support HOT 2
- Missing functions to remove elements ? HOT 1
- Referenced Parameters compiling to Object instead of Array HOT 4
- Speccy uses dompurify with XSS vulnerability HOT 5
- Add a way to create schemas HOT 1
- Add (or document how to) read schema properties HOT 4
- Reference parsing doesn't work in the CLI tool using relative paths. HOT 3
- Wrong error message when using an undefined property for a schema object property definition HOT 1
- Convert the code-base to use Symfony Console HOT 1
- Make `symfony/yaml` dependency optional
- References to incorrect components should be considered invalid HOT 1
- Unable to reference other local json file HOT 2
- Duplicate OperationIds should be considered invalid
- Support for PHP 8.1 and 8.2 HOT 1
- Further library maintenance HOT 9
- Discriminator mapping throws validation error on valid discriminator mapping and accepts incorrect one. HOT 1
- Add support for symfony/yaml version ^7 HOT 3
- Nexmo/api-specification no longer exists HOT 2
- Security vulnerabilities funded by trivy
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from php-openapi.