Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Major Performance issue even with new caching?

Ouverte
  • Quelque chose ne va pas ?
#156 7 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
38/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
openapi, php
Domaine
api, performance

Piste de recherche

Commencez par la reproduction minimale sur github.com/lextira/openapi-parse-test et exécutez test.php sur le fork basé sur v1.4 et la release officielle v1.6. Examinez le chemin de résolution des références et le comportement du cache, en utilisant la spécification OpenAPI liée comme charge de travail. Le travail est considéré comme terminé lorsque le chemin v1.6 n'affiche plus la régression de parsing signalée par rapport au fork.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

needs investigation

Hi @cebe

Almost 2 years ago we had a rather big issue with the performance for parsing an API-spec, where all components were store in another (the same) file. It took a couple of minutes to process. My collegue then proposed this PR #65

We ended up using this fork for the last two years now. This week I'm updating dependencies, and having seen that you merged #67 made me realize, that I can finally get rid of our fork.

However, running our test-suite after the update was rather painful: Instead of ~1s to parse our specification, like with our fork, it now took ~30s. I spent a couple of hours analyzing, but I couldn't find the issue. It looks like resolving references is painfully slow, it seems to take 100-300ms for each reference. Clearly, this was much faster in version 1.4, where our fork originates.

Therefore, I hope you can find a minute to look into it as well. I prepared a minimal test setup:

$ git clone https://github.com/lextira/openapi-parse-test
$ composer update

# now we have a composer install with our fork, see https://github.com/lextira/openapi-parse-test/blob/master/composer.json
$ php test.php
Start Reading...
Read took 1248 miliseconds!
Parsed file is 791837 characters long.

$ git checkout with-openapi-1.6
$ composer update

# new we are at the latest release of the official repository
$ php test.php
Start Reading...
Read took 37302 miliseconds!
Parsed File is 791837 characters long.

So with v1.6, reading the exact same file from the exact same URL takes almost 30 times longer than with v1.4 (and our custom cache implementation, which is very similar to your implemented cache now). For context, the specification used for the test is our official API documentation and can be found here: https://docs.lexgate.ch/api/

Langage dominant
PHP
Étoiles
501
Forks
99
Aucune PR mergée en 30 j

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cebe/php-openapi

Toutes les issues de cebe/php-openapi

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.