Considérations sur les performances PHP?

Question

Je construis un site PHP , mais pour l'instant le seul PHP que j'utilise est une demi-douzaine d'inclusions sur certaines pages. (J'utiliserai probablement quelques requêtes de base de données éventuellement.)

Les simples instructions include () constituent-elles un problème de rapidité ou de mise à l'échelle, par opposition à un HTML statique? Quels types de choses ont tendance à provoquer l’enlisement d’un site?

Answer 1

À proprement parler, le code HTML direct sera toujours utilisé plus rapidement qu'une approche côté serveur car le serveur n'a pas à interpréter le code.

Pour répondre à la question plus importante, il y a un certain nombre d'éléments qui entraîneront l'enlisement de votre site. il n'y a pas de seuil spécifique pour le moment où votre code pose le problème par rapport à PHP. (Gardez à l'esprit que beaucoup de sites de Yahoo sont gérés par PHP, alors ne pensez pas que PHP ne peut pas évoluer).

J'ai remarqué que les sites PHP les plus lents sont ceux qui en contiennent le plus nécessaire pour afficher une page spécifique. OSCommerce (oscommerce.com) est l'un des paniers d'achat les plus populaires pilotés par PHP. Cependant, il a la mauvaise habitude d’inclure toutes les fonctionnalités de base (au cas où cela serait nécessaire) sur chaque page. Ainsi, même si vous n'avez pas besoin d'afficher une "boîte d'information", la fonction est chargée. D'autre part, il existe de nombreux frameworks PHP (tels que CakePHP, Symfony et CodeIgniter) qui adoptent une approche "chargez-la comme vous en avez besoin".

Je conseillerais ce qui suit:

1. N'incluez pas plus de fonctionnalités que nécessaire pour une page spécifique
2. Séparez les fonctions de base (utilisez une approche MVC si possible)
3. Utilisez require_once au lieu de include si vous pensez que vous avez imbriqué des inclus (par exemple, la page A inclut le fichier B qui comprend le fichier C). Cela évitera d'inclure le même fichier plusieurs fois. Cela arrêtera également le processus si un fichier est introuvable; aidant ainsi votre processus de dépannage;)
4. Cachez les pages statiques au format HTML si possible - pour éviter les réparations lorsque les choses ne changent pas

Answer 2

Certainement, include () est plus lent que les pages statiques. Cependant, avec les systèmes modernes, vous ne verrez probablement pas cela comme un goulot d'étranglement pendant une longue période, voire jamais. Les avantages de l’utilisation de ce logiciel incluent de garder les parties communes de votre site à jour dépassent les performances minimes, à mon avis (avoir une navigation différente sur une seule page parce que vous avez oublié de la mettre à jour entraîne une mauvaise expérience utilisateur et par conséquent un mauvais pressentiment envers votre image. site / entreprise / peu importe).

L’utilisation de la mise en cache n’aidera pas non plus - la mise en cache du code sera plus lente qu’une simple include (). Le seul moment où la mise en cache vous sera bénéfique est que vous fassiez des calculs intensifs (très rares, sur des pages Web) ou que vous récupériez des données dans une base de données.

Answer 3

On dirait que vous participez à une optimisation prématurée. Si l’application n’est pas construite, même si vous devez prendre en compte vos préoccupations en matière de performances, votre préoccupation principale devrait être la rédaction de l’application.

Comprend sont une réalité de la vie. Ne vous inquiétez pas du nombre, gardez votre code bien organisé (la structure des dossiers PEAR est une bonne chose, si vous ne savez pas de quoi je parle, regardez la structure des fichiers de classe Zend Framework).

Concentrez-vous sur l’écriture de l’application avec un minimum d’abstraction. Regroupez tous vos appels de base de données dans une classe (ou des classes) afin de minimiser la duplication de code (principes KISS et autres) et, le moment venu, de refactoriser et d'optimiser vos requêtes, elles sont centralisées. Découvrez également des tests unitaires pour éviter la régression.

Une fois l'application lancée, ne nous demandez pas ce qui est plus rapide ou meilleur, cela dépend de chaque goulet d'étranglement. Il se peut que même si vous avez beaucoup d'inclusions, vos boucles vous font perdre votre temps, ou peu importe. Utilisez XDebug et profilez votre code une fois qu'il est opérationnel. Recherchez les segments de code qui prennent une quantité de temps démesurée, puis effectuez une refactorisation. Si vous vous concentrez trop sur les performances entre include et include_once, vous finirez par chasser un fantôme lorsque ces demandes de boucle synchronisées prennent votre petit-déjeuner.

Bien qu'entre-temps, les meilleures suggestions soient de regarder le manuel de php.net et assurez-vous que s'il existe une fonction intégrée faisant quelque chose que vous essayez de faire, utilisez-la! Les extensions PHP basées sur le C seront toujours plus rapides que tout code PHP que vous pourriez écrire, et vous serez surpris de voir à quel point ce que vous essayez de faire est déjà fait.

Mais encore une fois, je ne saurais trop insister sur ce point, l'optimisation prématurée est MAUVAISE !!! Lancez votre application avec de bons niveaux d'abstraction, profilez-la, puis corrigez ce qui est en train de dévorer votre temps plutôt que de fixer ce que vous pensez pourrait manger votre temps.

Answer 4

Nah inclus sont bien, rien à craindre là-bas.

Vous voudrez peut-être penser à modifier un peu vos en-têtes de cache, mais à moins que vous obteniez des résultats significatifs, cela ne devrait pas poser de problème. En supposant qu'il ne s'agisse que de données statiques, vous pouvez même envisager de convertir le site entier en HTML statique (méthode la plus simple: écrivez un script qui saisit chaque page via le serveur Web et la dépose dans une structure de répertoires correspondante)

La plupart des applications Web sont limitées par la vitesse de leur base de données (ou quel que soit leur stockage externe, mais ce sera 9/10 fois une base de données), le code de l'application est rarement un sujet de préoccupation et il ne sonne pas. comme si vous faisiez tout ce dont vous avez encore besoin de vous inquiéter.

Answer 5

Avant de prendre des décisions à long terme sur la structure du code de votre site, je vous recommande de lire un peu sur modèle de conception modèle-vue-contrôleur . Bien qu'il y en ait d'autres, celui-ci semble gagner beaucoup de terrain dans les cercles de développement Web et le sera certainement pendant un certain temps. Vous voudrez peut-être jeter un coup d'œil à certains des autres modèles proposés par Martin Fowler dans son Patterns of Enterprise Application. Architecture avant de prendre une décision finale quant au type de conception le mieux adapté à vos besoins.

En fonction de la taille et de la portée de votre projet, vous souhaiterez peut-être utiliser un framework prêt à l'emploi pour PHP, tel que Zend Framework ou PHP On Trax, ou vous pourrez décider de créer votre propre solution.

En ce qui concerne plus particulièrement le rendu du contenu HTML, je vous recommande fortement d'utiliser une forme de modèle afin de maintenir votre logique métier séparée de votre logique d'affichage. J'ai découvert que cette règle simple de mon développement m'a fait gagner du temps lorsque l'un ou l'autre devait être changé. J'ai utilisé http://www.smarty.net/">Smarty et je sais que la plupart des frameworks existants ont soit leur propre système de gabarit, soit une architecture de plug-in vous permettant d'utiliser votre propre méthode préférée. Lorsque vous examinez les solutions possibles, nous vous recommandons d’en rechercher une capable de créer des versions en cache.

Enfin, si la rapidité du back-end vous préoccupe, je vous recommande vivement de rechercher des moyens de minimiser les appels de votre magasin de données back-end (qu'il s'agisse d'une base de données ou simplement de fichiers système). Essayez d'éviter de charger et de rendre trop de contenu (par exemple, un rapport volumineux stocké dans une table contenant des centaines d'enregistrements) en même temps. Si possible, cherchez des moyens pour que l'interface utilisateur charge des bits de données plus petits à la fois. Et si vous êtes particulièrement préoccupé par le temps de chargement réel de votre contenu html et de ses CSS, Javascript ou autres dépendances, je vous recommanderais de consulter ces suggestions des gars de Yahoo!.

Answer 6

Pour ajouter ce que JayTee a mentionné - la fonctionnalité de chargement lorsque vous en avez besoin. Si vous n'utilisez aucun des frameworks qui le font automatiquement, vous voudrez peut-être examiner la fonctionnalité __autoload () introduite dans PHP5 - en gros, votre propre logique peut être invoquée lorsque vous instanciez une classe particulière si ce n'est pas déjà fait. chargé. Cela vous donne la possibilité d'inclure () un fichier qui définit cette classe à la demande.

Answer 7

Pour accélérer votre application, la meilleure chose à faire est d'utiliser un cache Opcode, tel que APC . Vous trouverez une excellente liste et description sur Wikipedia .

En ce qui concerne les inclusions simples, veillez à ne pas inclure trop de fichiers sur chaque requête, car les E / S du disque peuvent empêcher votre application d’être correctement mise à l’échelle. Quelques dizaines d'inclusions devraient suffire, mais il est généralement judicieux de regrouper vos fichiers les plus souvent inclus dans un seul script afin que vous n'ayez qu'un seul inclus. Le coût en mémoire d'avoir quelques classes ici et là dont vous n'avez pas besoin de charger sera supérieur au coût des E / S de disque pour inclure des centaines de fichiers plus petits.