Bonjour,
 
Qu'est-ce qui est préférable en termes de vitesse de chargement ?
 
- Avoir beaucoup (10 par page) d'include qui vont entraîner beaucoup de requêtes serveur mais du coup avoir des fichiers plus petits et les include seront mis en cache.
- Avoir des grosses pages pages longues à charger mais moins de requêtes serveur.
 
Merci beaucoup !

Eviter a tout prix les includes, cela bouffe de l'IO.
 
Opter pour une seule page, qui sera de toutes manière compilée avec xcache/apc/etc..

non
non
non

il vaut mieux faire des includes , pour garder des fichier lisibles. Utiliser un cache ram genre APC qui plimtie les accès disques

si
si
si
si
 
1/ il parle de perf, pas de maintenabilité.
 
2/ un include reste un include, donc xcache ou pas, l'IO sera sollicité; et sera dans l'absolu bcp plus couteux qu'une "simple page"
 
3/ rien n'empeche de programmer un script qui merge les fichiers php pour en faire qu'un seul sur les serveurs de prod.

1/un projet moyen , c'est 5 / 10 000 lignes: charger l'ensemble à chaque fois juste pour afficher la age d'accueil est clairement une optimisation ...
2/ le cout ne sera présent qu'une fois. Idem , c'est neglgeable
3/ oui ( a noter que certains framework comme symfony le font)

Sacrifier la maintenabilité pour un eventuel gain de perfs est du suicide. C'est le meilleur moyen d'avoir des bug.
Rappel des priorité
avoir un code qui fonctionne
pouvoir corriger ce qui ne fonctionne pas
avoir un code qui fonctionne vite

 
Premature optimization si the root of all evil.
Si tu pars sur des principes comme ça t'es bien parti pour faire de magnifiques pâtés de code impossible à maintenir dès que le projet grossit un peu.
 
Au passage pour l'auteur du topic, non les includes php ne vont pas générer beaucoup de requêtes, tout se passe coté serveur.

Désolé les gars, mais moi je n'aurai pas honte dans un schema MVC de mettre toute la framework dans un seul et gros fichier, et appeler le bon include concenrnant la page en question. Avec un moteur de template à la blitz.  Vous m'expliquerez en quoi cela ressemblera a du code spaghetti.
 
Secundo, quand je dis "eviter a tout prix" les includes, j'ai deja été amené a voir des tres tres gros sites internet qui chialait toutes les larmes de leur corps parcequ'ils avaient opté pour du "super propre" mais "super include".. et qu'au final ils n'en finissaient pas d'avoir des problemes.
 
Je ne dis pas de mettre tout le site en une seule page; mais savoir trouver le juste milieu pour pas que ce soit une pompe à IO. Si c'est un site peu frequenté, le gain n'est pas forcement visible.. par contre si il est amené à grossir il pourra nous remercier.
 
 

tu n'es pas le seul a faire des sites qui ont un peu de visibilité  
 
mon dernier site fait avec symfony :  

 
Tu mettrai tout ça dans un fichier ?  
donc le bot qui va charger la page d'accueil, ton serveur va se prendre 100K ligne de code en mémoire ?  
Tu appelles ça efficace ?

 
C'est pourtant la bonne approche. Tu commences comme ça, et c'est uniquement dans le cas où tu as des problèmes de perfs que tu commences à optimiser. Et c'est rarement les IO disque liés au chargement de fichiers qui limitent les perfs. Et quand bien même ce serait le cas, il y a toujours des solutions pour améliorer très fortement les choses sans pour autant revenir vers du code en gros paquets de plusieurs milliers de lignes dans le même fichier.

flo850:
 
symfony ! mais tu veux rire ou quoi ? Tu vas me dire que tu utilises Doctrine aussi ? qui est une bouze sans nom en terme de perf  au profit d'une maintenabilité.
 
Je ne dis pas qu'il faut charger tout le site en une seule page, je dis juste qu'il faut opter pour la philosophie du no-include au maximum. Evidemment que tu ne veux pas charger des libs de mail en home alors que ton site ne l'utilise que sur une seule page eloignée.. il ne faut pas me faire dire ce que je n'ai pas dis.
 
Le monsieur initiateur du topic nous demande quel est le mieux en vitesse entre :
 
- une page avec plein d'include
- une page sans include
 
Repondez sans faire de geekerie dites simplement "une page sans include".. faut savoir répondre a la bonne question sans partir dans des delires.
 
Maintenant, qu'il choisisse d'optimiser le truc differement, de tirer parti de notre enseignement pour evoluer et mettre en place un code qui n'est pas "bordelique" c'est son problème et il reviendra nous voir. La pour le moment, vous etes hors sujet.

Sympa ce truc  
Perso je dis mesurer microtime entre les instructions du code, avec
 $key += time en ms depuis la dernière mesure
 $keynb++;
 $avg[$key]=$key/$keynb;
 arsort($avg);print_r($avg);

qui permet de retrouver une valeur moyenne de calcul (qui ne sera jamais le même entre fonctions, requêtes sql, utilisation proc, disque & mémoire etc ..)
donc d'identifier rapidement les goulots d'étranglement

(désolé pour les puristes, j'ai installé aucun module pour mesurer ça sur mon server)

+10000 pour skeye et flo850. Une bd mal structurée ou des requêtes pas optimisées sont bien souvent plus la source de ralentissement d'un site que les includes php

 
Il faut savoir répondre en voyant plus loin que le bout de son nez, surtout.
L'auteur du topic est clairement un débutant. Lui répondre uniquement que "une page sans include c'est mieux car plus rapide", à mon avis c'est irresponsable.  
Ça l'incite à ne pas rechercher en priorité à coder proprement.  
Les IO ne peuvent générer de problèmes de perfs visibles que sur des sites à très gros trafic, et uniquement avec un très grand nombre d'includes.

oui  , et oui  
 
un site qui va etre limité par les IO disque va déjà etre important , c'est a dire un trafic énorme et/ou une base de code énorme
 
cas 1 : Trafic enorme , peu de code : les IO ne sont pas le goulet d'etranglement
cas 2 : Trafic moyen , grosse base de code :  avoir un code maintenable est plus important que de gagner 1ms ou 2 . Et comem tu le dis , il faut garder de la modularité pour ne pas charger la lib mail là ou elle ne sert pas.
cas 3 : trafic enorme, grosse base de code : Dans le cas ou les IO seraient un facteur limitant, il suffit de mettre apc sur le serveur pour qu'il se charge de ne faire qu'une IO de temps en temps.  
 
 
Pour le reste ( delire , bouze, troll ), je ne suis pas sûr que ce soit utile.
 

 
j'utlise le slow query log aussi sur le serveur, c'est assez pratique.  
Moi non plus je n'ai pas d'outils de mesure sur le serveur de rpod, ça coute trop cher en perfs

Non mais c'est quoi ces conneries de tout fouttre en 1 seul fichier?

Poopidoo: Les sites dont tu parles et qui ramaient parce qu'ils avaient privilégié la lisibilité par rapport aux perf doivent simplement se dire qu'ils ont engagé des bon progs mais un mauvais sys-admin. J'ai jamais testé les solutions PHP de pré-compilation des fichiers mais je sais qu'elles existent. Donc tu loades ton module dans Apache et il va-précompiler ton fichier, de manière à ce que les includes ne génèrent plus d'IOs (un comme Tomcat le fait avec les Servlets quoi). Bon sang j'en reviens pas qu'en fin 2010 il y ait encore des gens qui prônent ce genre d'optimisation :s .

Edit: Grilled

Si ça vous intéresse un petit script pour mesurer le temps d'exécution des scripts d'une appli web en php :  

<?php
 function ppwaStartTime()
 {
     global $PPWA_START_TIME;
 
     $timeparts = explode(" ", microtime());
     $PPWA_START_TIME = $timeparts[1].substr($timeparts[0], 1);
 }
 
 function ppwaEndTime()
 {
     global $PPWA_END_TIME;
 
     $timeparts = explode(" ", microtime());
     $PPWA_END_TIME = $timeparts[1].substr($timeparts[0], 1);
 }
 
 function ppwaScriptExecTime()
 {
     // In seconds
     return bcsub($GLOBALS["PPWA_END_TIME"], $GLOBALS["PPWA_START_TIME"], 6);
 }
 
 function ppwaLogScriptExecTime()
 {
     $bRestaureUmask = FALSE;
     $sLogFile = dirname(__FILE__).'/LogScriptsTimes/Log'.date('Ymd').'.log';
     if (file_exists($sLogFile))
     {
         if (!is_writable($sLogFile))
         {
             // Change the access rights (because of php scripts executed by CRON with another user than apache)
             chmod($sLogFile, 0666);
         }
     }
     else
     {
         $iUmask = umask();
 
         // Change the default umask
         umask(0);
         $bRestaureUmask = TRUE;
     }
 
     ppwaEndTime();
     $fTime = ppwaScriptExecTime();
 
     file_put_contents($sLogFile,
                       $_SERVER['REQUEST_URI']." #|# $fTime #|# ".implode(' #|# ', sys_getloadavg())." #|# ".date("Y-m-d H:i:s" )."\n",
                       FILE_APPEND);
 
     // Restaure the umask
     if ($bRestaureUmask)
     {
         umask($iUmask);
     }
 }
 
 // Start to measure the PHP script execution time
 ppwaStartTime();
?>

 
Après, probablement dans le fichier de conf de l'appli (sinon, dans le fichier qui est appelé en premier systématiquement), mettre ces lignes :

// ---- For benchmark ----------------------------------
 require dirname(__FILE__).'/../../ProfilePHPWebApp.php';
 register_shutdown_function('ppwaLogScriptExecTime');
 //------------------------------------------------------

 
Pour les outils d'analyse des logs produits (affichage des 30 scripts les plus longs avec le min/avg/max du jour, leur moyenne sur une période ou le nb de pix max de temps d'exe sur une période), me contacter en MP pour un envoi des fichiers Le plus intéressant est de voir le nb de pics max de temps d'exe pour un script relevés sur plusieurs jours mais consolidé sur la journée, pour repérer les heures où y'en a le plus... Ca lisse les pics ponctuels et met en exergue les pics répétitifs...

bon je laisse tomber, vous avez probablement raison. faites des includes de tous les cotés;faites egalement des bases de données super corellées avec tout plein de jointures parceque c'est "beau" et "propre"; mettez des couches d'abstractions jusqu'a 30 niveaux dans votre code php parce que ca excite les yeux; etc etc..
 
je rends les armes :-)

Tu as mesuré le gain apporté par  ton optimisation ?
une optimisation d'algo fait souvent  bien plus d'effet qu'une micro optimisation

utiliser une grosse machine comme symfony permet de passer plus de temps sur ce genre d'optimisation que sur les pouillèmes. A temps égal passé dessus, il y a moyen de produire plus et mieux avec un bon framework que tout seul dans son coin, et ça compense largement la perte de perfs. enfin de mon point de vue

Edit : et je dis ça malgré le fait que j'était réticent à utiliser symfony et que mes premières perfs étaient désatreuses

 
Les appels de fonction aussi c'est le mal pour les perfs à ce rythme là, donc tu fais ZERO fonction aussi ?

C'est un faux pb de toutes façons car les IO ça devient peu couteux vu que l'OS à un cache disque hein tu sais... donc on va très certainement souvent tomber dans le cas d'un cache hit et l'IO va pas prendre beaucoup de temps.
 
De toutes façons en MVC on va privilégier l'autoload plutôt que l'include bête et méchant ce qui devrait aussi limiter le soucis dans ce cas précis.
 
D'autre part et pour finir, les caches d'op-code et de page ça existe aussi.
 
Quoiqu'il en soit, les IO pour charger le code risques souvent d'être plus court que les IO de la BDD donc bon...

Des témoignages irréfutables pour un seul fichier pour tout mon projet
 

Dans une BDD bien conçu si t'as des jointures c'est que c'est nécessaire... T'as déjà fait du MERISE dans ta vie ou bien ?
 
Parce que si on t'écoutes j'ai l'impression que t'irais presque qu'a inclure la même donnée dans plusieurs table pour éviter les jointure quoi...

je te trouve assez agressif
Est ce que tu as fait des mesures ? est ce que tu as des choses un peu plus efficace qu'une attaque personnelle ?  

A part asséner des vérités et être méprisant, tu sais faire autre chose ?
Ta maman ne t'a jamais appris que la première étape de toute optimisation, c'est une mesure ? Elle aurait du.

²²²²

Et pour poopidoo, avec ton seul fichier tu dois gagner quoi ? Une miliseconde toutes les 100 requêtes ?

Personnellement, équipant tous mes serveurs avec la technologie poudre verte (http://www.poudreverte.org/) je n'ai aucun problème d'IO.

 
Inlining.  

Vous êtes que des tapettes de toutes façons. Les vrais boss de l'opti, ils fouttent tous les modules Apache + PHP dans un même fichier source, qu'ils recompilent, pour éviter les IO au chargement

À part ça je serais vachement curieux de voir la structure de sa table. Parce que s'il met toutes ses données dans la même table pour éviter les jointures, il doit juste avec un truc genre single-table-inheritance gigantesque avec des triggers dans tous les sens  pour la garder synchro

Non c'est juste que c'est une BDD orienté objet/document. (je suppose vu qu'il a parlé de no SQL)

Vous me faites rigoler.
 
La clé c'est le langage machine !
couches réseaux + serveur web + application, all-in-one.
Tout le reste c'est du ramassis de wannabe-geeks qui s'appuient sur des frameworks et des clusters parcequ'ils maitrisent pas suffisamment les fondamentaux !
 
 
 

L'abstraction apportée par le langage
cause elle-même bon nombre de lenteurs
comme harko n'oubliez point l'adage :
un bon soft se code en assembleur

Je crois justement que toi, tu ne sais pas.

Zut, j'ai loupé un tas de trucs ..
APC c'est long à installer/configurer, as-tu mesuré un gain en unités ?

register_shutdown_function('ppwaLogScriptExecTime');

Bonne méthode, j'utilise la même en 4 lignes ..