[résolu] Performance des scripts php

Bonjour à tous et bon lundi

Suite à quelques problemes de ralentissement des pages, je me suis posé la question du temps d'execution de mes scripts.
J'utilise souvent des cms, spip, wordpress, plume... et sur certain site surtout les sites spip, j'arrive à des temps d'execution entre 200 et 800 ms pour les pages mise en cache. impossible de descendre en dessous, mais cela est rarement au dessus non plus (sauf au moment de la regeneration du cache ou cela peut aller jusqu'a 2s )
Je précise que le serveur est plutot performant.

Cela me semble beaucoup surtout au vu que par exemple la page sur laquelle je suis en train d'écrire à été generée en 2ms...

Je voudrait simplement avoir votre avis sur le sujet, trouvez vous cela excessif, raisonable ou me conseillez vous de changer complétement de méthode...
Modifié par matmat (19 Oct 2007 - 19:21)

les cms produisent rarement des pages à la vitesse de la lumière.
c'est leur principal inconvénient, il y a un certain nombre de requêtes superflues pour permettre de gérer l'ensemble du site dynamiquement (apparence, contenu), par rapport à un script "sur mesure" qui n'effectuera que les opérations minimales.

un temps optimal se situe (en moyenne, cela dépend bien sûr de ce que le script doit effectuer) entre 10 et 80ms.

au final, tout dépend du serveur et de la rapidité avec laquelle sont délivrées tes pages. si tu estimes que cela ne se ressent pas lors de la navigation et que tout le monde est satisfait... alors cela peut convenir.

10 et 80ms... effectivement avec un cms, il me faudrait un serveur avec 10 processeurs...

spip fait, pour les pages mise en cache, entre 6 et 10 requetes, et je ne crois pas qu'il soit possible même en optimisant les boucles aux maximum de descendre à moins de 200 ms.

Le bon coté de l' histoire c'est que de faire ces mesures m'a permis de trouver au sein de mes pages d'énorme erreur de programation, j'avais en effet sur certaine pages des includes sans cache qui génerée des requetes ce qui donné des effets désastreux.

Personne jusque la ne s'est jamais plaint de la lenteur de mes pages (il faut que je corrige au plus vites mes derniéres erreurs sinon cela vat bientôt m'arriver), mais c'est vrai que comme les connections sont de plus en plus rapide la question de la génération de la page devient un sacrée plus.

La connection transfert casi instantanément, les nouveaux ordi font tourner le navigateur pour qu'il affiche les pages instantanement... que reste il au bout? la rapiditée des scripts et du serveur.

C'est un point trés atractif de ce forum, je trouve qu'on revient plus facilement sur des pages rapides, que si elles donnent une impression "pâteuse".
Modifié par matmat (15 Oct 2007 - 16:27)

Pour la perception de la vitesse, tout dépend aussi le nom de visiteurs simultanés. Du 500ms peut être acceptable, si y'a un gars ou deux par heure...

Pour affiner tes mesures, tu peux utiliser une extension style xDebug, qui permet de profiler complètement une application. Tu pourra alors voir en détail quel fonction ou quel bloc de code prend le plus de temps, et est donc à optimiser en priorité.

Merci bien, je vais essayé xDebug...

Mes sites n'ont pas des milliers de visites par jour, mais bon un peu plus d'un gars ou deux par heure, je dirais plutot de 10 a 100 par heure. Ce qui me confirme bien qu'il y a un probléme quelque part...

Je viens de lire cet article, l'article dit si j'ai bien compris qu'une page html vat 2 fois plus vite qu'une page php qui vat 20 fois plus vite que le plus rapide des frameworks php pour afficher hello word. Je n'ose pas imaginer le résultat avec un cms...

On en conclut donc, indépendament du temps de production, que si l'on souhaite une qualité maximum utiliser un framework ou un cms n'est pas une bonne idée...

matmat a écrit :
spip fait, pour les pages mise en cache, entre 6 et 10 requetes, et je ne crois pas qu'il soit possible même en optimisant les boucles aux maximum de descendre à moins de 200 ms.

tout dépend des requêtes, de la configuration du serveur, des tables utilisées, des index mis en place, du cache mysql, et du script afférent. on peut écrire un script qui produit 6 requêtes (le forum doit tourner autour de ça si mes souvenirs sont bons) en 10-30 ms.

il me semble aussi que les lenteurs sont dût plus à l'enorme quantitée de fonction php qu'aux requetes mysql. Par contre sur un site de bien immobilier, j'ai des résultats absolument affreux a ce niveau là, en cache pas de probléme, mais lors de la modification des fiches, arg on monte à 100 requetes par page...
Modifié par matmat (16 Oct 2007 - 15:59)

J'avais vu passer une fois un test qui préconisait des noms de fonctions et de variables courts pour gagner du temps... je ne sais pas si ça change vraiment quelque chose.

(ça ne change rien en réalité)

QuentinC a écrit :
J'avais vu passer une fois un test qui préconisait des noms de fonctions et de variables courts pour gagner du temps... je ne sais pas si ça change vraiment quelque chose.

Premature Optimization is the root of all evil

J'avais écrit un petit article il fut un temps :
http://www.estvideo.com/dew/pages/phpbench/

Mais n'aborde qu'un vingtième de ce qu'il y aurait à dire...

dew a écrit :
Mais n'aborde qu'un vingtième de ce qu'il y aurait à dire...

Ca aborde surtout ce qui est moins essentiel, nan ? Il faudrait faire des benchs plutôt sur les accès base de données, qui représentent le plus de problème dans le monde php.

Tiens ça serait une idée d'article ça : comparer différents schémas de bases, style indexaction de colonne ou pas, connexions persistentes, optimisation des requêtes, etc.

c'est ce que je voulais dire par cette dernière phrase... il s'agit du chapitre n°0.

Effectivement (TODO : lire plus lentement les posts des autres)

C'est marrant j'ai lu cet article hier...
Bon j'ai fait plein de test avec la même base de donnée et des appels mysql/php sans scripts ou autre cms tout fait, et effectivement les résultats n'ont rien à voir : de 20 a 80 ms pour generée les pages sans cache, et avec un cache on descent à 1 ou 2 ms. D'ailleur a ce propos ce forum utilise t'il un cache?
Parceque j'ai du mal à comprendre comment, toujours d'aprés mes test, vous avez ces résultats. En effet, sans cache et avec un minimum de contenu et de script, je ne comprend pas comment on peut génerée une page avec en 8ms.
Pour information j'ai un cpu asser recent et un serveur apache sous window, et j'ai et peu prés les mêmes resultats sur des test en ligne.
Pour mesurer j'utilise microtime() avant et aprés le script, j'ai essayer aussi xDebug, cela donne à peu prés la même chose mais je l'ai enlever car il me plante Apache toutes les cinqs minutes.
Modifié par matmat (17 Oct 2007 - 16:39)

a écrit :
Premature Optimization is the root of all evil

OK donc je dois comprendre que c'est du couper les cheveux en 4 pour rien ?

Par contre, j'ai lu aussi que l'utilisation de la couche objet de php 5 ralentissait considérablement les scripts... c'est vrai ça ou bien c'est aussi des bêtises ?

Pour les temps de 8ms du forum alsa, honnêtement, je pense qu'il n'y a pas de cache non, Dew confirmera ou infirmera, mais c'est parfaitement possible.

Pour afficher une page de topic, à mon avis, ceci suffit :
1 - Si les sessions et cookies ne sont pas vides, on vérifie que les données sont valides et que l'utilisateur est bien connecté : 1 requête sur une table unique
2 - ON récupère l'id du topic en GET et on prend la ligne correspondante dans la table pour afficher le titre, le nombre de réponses, la catégorie, etc. : 1 requête avec éventuellement 2 tables impliquées
3 - Comme on a été malin et qu'on a stocké le nombre de réponses dans la table topics, on n'a pas à le recalculer et on n'a plus qu'à récupérer les 10 ou 20 messages de la page à afficher : 1 requête avec éventuellement 2 tables impliquées
4 - On peut faire quelques requêtes supplémentaires pour vérifier le nombre de MP dans la boîte, le nombre de connectés, etc : 1 à 3 requêtes

Total : 3 à 6 requêtes pour un forum léger et bien pensé
On est à des années lumières d'un phpbb à 20-25 requêtes...

Sachant maintenant que je suis sur un hébergement mutualisé pro, que ma page d'accueil fait 3 requêtes MySQL et qu'elle se génère en 30-40 ms dans les heures creuses... sur un serveur dédié, le 8ms, ça doit vraiment pouvoir se faire sans trop de problème.

a écrit :
Sachant maintenant que je suis sur un hébergement mutualisé pro, que ma page d'accueil fait 3 requêtes MySQL et qu'elle se génère en 30-40 ms dans les heures creuses... sur un serveur dédié, le 8ms, ça doit vraiment pouvoir se faire sans trop de problème.

c'est peut être la raison, parceque sur ma machine ou le serveur mutualisé même pour une requete je descend pas dans ces chiffres pour afficher les lignes d'une table. Je suis plutot comme toi entre 20 et 50 ms.

C'est sûrement la raison, et c'est simple à comprendre : 50, 100, 200, peut être même plus, de sites sont hébergés sur la même machine dans le cas d'un hébergement mutualisé.
Donc forcément, un script ne dispose pas de tout le temps processeur, ou très rarement : c'est possible si au moment précis où tu demandes la page, aucune autre page n'est demandée sur ton site ou sur un des autres sites hébergés sur la même machine.

Le plus bas que j'ai vu chez moi c'est 14,7 ms pour 3 requêtes permettant d'afficher un topic de mon forum. Mais c'est pas souvent, en général comme je disais avant ça tourne plutôt entre 20 et 60 ms. 100 à 200 ms si tu n'as pas de chance.
Modifié par QuentinC (18 Oct 2007 - 07:33)

QuentinC a écrit :
Premature Optimization is the root of all evil

Par contre, j'ai lu aussi que l'utilisation de la couche objet de php 5 ralentissait considérablement les scripts... c'est vrai ça ou bien c'est aussi des bêtises ?
S'il est évident que de l'orienté objet est un peu plus lent que du fonctionnel/script à l'arrache, ça reste toujours plutôt négligeable par rapport au reste.

J'ai mon propre framework, et dans ce qui prend le plus de temps, il y a d'abord les inclusions de scripts : l'ouverture et la compilation de scripts prend plus de la moitié du temps d'exécution. Ensuite y'a tout ce qui est SQL. Enfin vient les tests d'existence de fichier (is_file, is_dir, etc.).

Donc il vaut mieux avoir un seul fichier php de 50 Ko que 5 fichiers de 10 Ko, c'est ça ?
Parce que j'ai pris l'habitude, pour l'orienté objet de php, de faire une classe par fichier... j'ai tout faux ?