PHP Opcode Caching / Zend Acceleration et include_once vs require_once

Question

J'ai un collègue qui étudie la mise en cache d'opcode / l'accélération Zend (j'ai toujours supposé que ce sont les mêmes choses) pour notre application basée sur PHP. Ses repères semblent indiquer que nous ne voyons PAS un avantage en termes de performances si nous incluons nos (grandes) bibliothèques de classes avec require_once, mais nous voyons le bénéfice en termes de performances lors de l'utilisation de include_once.

Cela sent le poisson comme un poisson, mais je n’ai pas le temps de vérifier notre méthodologie de référence moi-même et mon collègue a plus de tolérance que moi pour l’odeur de poisson. :)

Est-ce que quelqu'un a déjà rencontré quelque chose comme ça? Si ce n’est pas le cas, avez-vous une idée de quelque chose qui pourrait causer l’augmentation des performances en passant de include_once à require_once?

Answer 1

Pour commencer, les deux appels (require_once et include_once) vérifient si un fichier n'a pas été inclus auparavant.

Ainsi, ils y parviennent tous les deux en recherchant le fichier dans tous les chemins disponibles et en vérifiant si le fichier n'a pas déjà été ajouté auparavant, etc.

Dans l’arrière-plan, ils évaluent toutes les différentes options (par exemple, plusieurs include_path, etc.), puis en créant le realpath à partir de cette forme abrégée, ils créent un identifiant unique. Il n'y a qu'un seul et même chemin, pas deux.

Ce n'est déjà pas le processus le plus rapide de la planète et se produit généralement à chaque requête avec PHP. Ajoutez ensuite une autre opération coûteuse qui est la statistique quand elle crée ce que j’ai appelé le realpath (realpath, car c’est en quelque sorte ce que realpath () permet de vérifier si le fichier existe.

Corrigez-moi si je me trompe, mais APC dispose d'optimisations spécialement pour ce cas.

En tout cas, maintenant sur la différence entre require_once et include_once, c’est-à-dire que require_once évalue le fichier (pour les erreurs de bas niveau , etc.) lorsqu'il l'inclut. Il s'agit d'une vérification supplémentaire dont vous pouvez vous débarrasser si vous avez suffisamment d'assurance qualité à la place pour qu'une erreur d'analyse ne puisse jamais se faufiler dans une inclusion.

Il est juste difficile de trouver le contraire. : -)

(Élément à prendre en compte: vous pouvez développer avec require_once et remplacer tous les appels par include_once lors du déploiement.)

Pour ce qui est du cache d'opcode, je vous recommande de APC . Cela a été discuté sur stackoverflow avant. Personnellement, je l’utilise / nous l’utilisons depuis un moment (nous traitons environ 100 000 visiteurs / jour avec 3 interfaces et 1 serveur) et nous sommes très heureux. APC est également optimisé pour la folie require_once / include_once.

Un effet secondaire plutôt intéressant est qu’APC vous permet également de stocker des variables PHP en mémoire - une sorte de persistant, etc.

Quelques points supplémentaires:

1. De nombreuses personnes affirment accélérer toute application avec __autoload .
2. Avec un cache de code opération, évitez les instructions conditionnelles require_once / include_once (dans les boucles ou dans le flux de contrôle, par exemple).
3. Certaines personnes disent que /absolute/path/to/file.php dans include_ ou require_once est plus rapide que de compter sur include_path.
4. L'ordre des chemins dans votre include_path est également important.

L’espoir que cela aide.

Answer 2

Je ne peux rien garantir car je n'y ai pas suffisamment réfléchi, mais oui, j'ai constaté des différences de vitesse entre les deux. Elles n’ont jamais été suffisamment significatives pour que je passe à include_once au lieu de require_once.

J'ai toujours supposé que la différence était due au fait que require_once devait faire plus de travail sous l'eau. au moins une erreur potentielle supplémentaire à préparer et à traiter, et beaucoup plus à faire lorsque le fichier requis n'existe pas.