Inconvénient d'avoir beaucoup d'include ?

Inconvénient d'avoir beaucoup d'include ? - PHP - Programmation

Marsh Posté le 24-11-2010 à 17:39:05    

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 !

Reply

Marsh Posté le 24-11-2010 à 17:39:05   

Reply

Marsh Posté le 24-11-2010 à 18:12:46    

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..

Reply

Marsh Posté le 24-11-2010 à 18:18:13    

poopidoo a écrit :

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


Message édité par flo850 le 24-11-2010 à 18:18:49
Reply

Marsh Posté le 24-11-2010 à 22:54:51    

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.

Reply

Marsh Posté le 25-11-2010 à 08:12:16    

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


Message édité par flo850 le 25-11-2010 à 08:13:45
Reply

Marsh Posté le 25-11-2010 à 08:51:31    

poopidoo a écrit :

Eviter a tout prix les includes, cela bouffe de l'IO.


 
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.


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 25-11-2010 à 09:52:01    

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.
 
 

Reply

Marsh Posté le 25-11-2010 à 10:12:26    

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


SLOC    Directory       SLOC-by-Language (Sorted)
161433  lib             php=155635,xml=5738,sh=60
4427    apps            php=4262,xml=165
3109    plugins         php=3109
195     test            php=195
24      project         php=24
23      config          php=23
16      web             php=16
13      nbproject       xml=13
0       cache           (none)
0       data            (none)
0       log             (none)
0       top_dir         (none)
 
 
Totals grouped by language (dominant language first):
php:         163264 (96.47%)
xml:           5916 (3.50%)
sh:              60 (0.04%)
 
 
 
 
Total Physical Source Lines of Code (SLOC)                = 169,240
Development Effort Estimate, Person-Years (Person-Months) = 43.75 (524.98)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 2.25 (27.01)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 19.43
Total Estimated Cost to Develop                           = $ 5,909,759
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
 


 
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 ?

Reply

Marsh Posté le 25-11-2010 à 10:19:16    

poopidoo a écrit :


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.


 
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.


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 25-11-2010 à 10:48:43    

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.

Message cité 2 fois
Message édité par poopidoo le 25-11-2010 à 10:52:23
Reply

Marsh Posté le 25-11-2010 à 10:48:43   

Reply

Marsh Posté le 25-11-2010 à 10:52:43    

flo850 a écrit :

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

Sympa ce truc  :jap:
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)

 

Message cité 1 fois
Message édité par grosbin le 25-11-2010 à 10:55:08

---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 25-11-2010 à 10:53:29    

+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 :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 25-11-2010 à 10:54:02    

poopidoo a écrit :


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.


 
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.


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 25-11-2010 à 11:06:00    

poopidoo a écrit :

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.


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.
 

grosbin a écrit :

Sympa ce truc  :jap:  
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)
 


 
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

Reply

Marsh Posté le 25-11-2010 à 11:11:07    

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 :(


Message édité par esox_ch le 25-11-2010 à 11:11:36

---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 25-11-2010 à 11:20:13    

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

Code :
  1. <?php
  2. function ppwaStartTime()
  3. {
  4.     global $PPWA_START_TIME;
  5.  
  6.     $timeparts = explode(" ", microtime());
  7.     $PPWA_START_TIME = $timeparts[1].substr($timeparts[0], 1);
  8. }
  9.  
  10. function ppwaEndTime()
  11. {
  12.     global $PPWA_END_TIME;
  13.  
  14.     $timeparts = explode(" ", microtime());
  15.     $PPWA_END_TIME = $timeparts[1].substr($timeparts[0], 1);
  16. }
  17.  
  18. function ppwaScriptExecTime()
  19. {
  20.     // In seconds
  21.     return bcsub($GLOBALS["PPWA_END_TIME"], $GLOBALS["PPWA_START_TIME"], 6);
  22. }
  23.  
  24. function ppwaLogScriptExecTime()
  25. {
  26.     $bRestaureUmask = FALSE;
  27.     $sLogFile = dirname(__FILE__).'/LogScriptsTimes/Log'.date('Ymd').'.log';
  28.     if (file_exists($sLogFile))
  29.     {
  30.         if (!is_writable($sLogFile))
  31.         {
  32.             // Change the access rights (because of php scripts executed by CRON with another user than apache)
  33.             chmod($sLogFile, 0666);
  34.         }
  35.     }
  36.     else
  37.     {
  38.         $iUmask = umask();
  39.  
  40.         // Change the default umask
  41.         umask(0);
  42.         $bRestaureUmask = TRUE;
  43.     }
  44.  
  45.     ppwaEndTime();
  46.     $fTime = ppwaScriptExecTime();
  47.  
  48.     file_put_contents($sLogFile,
  49.                       $_SERVER['REQUEST_URI']." #|# $fTime #|# ".implode(' #|# ', sys_getloadavg())." #|# ".date("Y-m-d H:i:s" )."\n",
  50.                       FILE_APPEND);
  51.  
  52.     // Restaure the umask
  53.     if ($bRestaureUmask)
  54.     {
  55.         umask($iUmask);
  56.     }
  57. }
  58.  
  59. // Start to measure the PHP script execution time
  60. ppwaStartTime();
  61. ?>


 
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 :

Code :
  1. // ---- For benchmark ----------------------------------
  2. require dirname(__FILE__).'/../../ProfilePHPWebApp.php';
  3. register_shutdown_function('ppwaLogScriptExecTime');
  4. //------------------------------------------------------


 
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...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 25-11-2010 à 11:20:55    

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 :-)

Reply

Marsh Posté le 25-11-2010 à 11:26:12    

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


Message édité par flo850 le 25-11-2010 à 11:28:42
Reply

Marsh Posté le 25-11-2010 à 11:38:23    

poopidoo a écrit :

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.


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


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Marsh Posté le 25-11-2010 à 11:41:40    

poopidoo a écrit :

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.
 
 


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...


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Marsh Posté le 25-11-2010 à 11:45:12    

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

Citation :

Voici 3 mois, j'ai remarqué que j'étais concerné par mauvaises performances. Je n'étais pas bien dans ma peau et je me sentais très mal à l'aise. J'ai utilisé un seul fichier pour tout mon projet et dès la première semaine, j'ai remarqué une nette amélioration, une énorme différence. Aujourd'hui, je vais très bien grâce à un seul fichier pour tout mon projet, je ne pourrais plus m'en passer. Votre produit est unique ! Merci infiniment.
Martine D. - Paris - France


Citation :

J'ai 36 ans et je souffre de mauvaises performances depuis au moins 6 ou 7 ans. J'ai essayé des tas de produits très chers pour très peu de résultats. Je ne voulais pas davantage perdre mon temps et mon argent, alors j'ai décidé d'essayer un seul fichier pour tout mon projet. Vous proposiez un remboursement intégral en cas d'insatisfaction donc je ne risquais rien. Après une ou deux semaines d'utilisation, ma vie a basculé. Tout mon entourage s'en est rendu compte. Maintenant, j'ai retrouvé une vie normale grâce à vous. J'utilise régulièrement un seul fichier pour tout mon projet et les résultats sont prodigieux ! Mille mercis à vous.
Christian Betrand - Marseille - France


Citation :

Après avoir dépensé des fortunes dans des produits très chers et même à la pharmacie, j'ai enfin trouvé l'ultime procédé incroyable pour faire partir cette fichue mauvaises performances ! un seul fichier pour tout mon projet est vraiment le meilleur ! Je le recommande à tout le monde.
Sylviane Loiret - Paris


Citation :

Je suis d'un naturel très cartésien, et quand on m'a parlé de un seul fichier pour tout mon projet et de ses effets je n'y croyais pas du tout. J'ai réussi à m'en procurer et depuis je ne peux plus m'en passer. Souffrant de mauvaises performances j'ai tout essayé. Depuis, cette période de ma vie n'est plus qu'un vieux souvenir. Je me porte à merveille et la vie me sourit enfin. Je suis un autre homme, je ne sais pas comment vous remercier.
Bernard Paul - Strasbourg


Citation :

Un miracle ? Non, simplement le meilleur produit existant. Dès la première utilisation vous sentez immédiatement son effet extraordinaire ! C'est assez surprenant, on a l'impression de revivre. Enfin je ne suis plus gênée grâce à l'existence de un seul fichier pour tout mon projet C'est vraiment fantastique !
Lucie Noiseau, Enseignante - Nancy


Citation :

Je perds mes cheveux depuis des années, et après avoir tout essayé, ma calvitie était toujours là et empirait. J'en avais assez de prendre des produits chimiques et je ne voulais pas entendre parler de la chirurgie esthétique. C'est alors qu'on m'a parlé de un seul fichier pour tout mon projet qui coûte moins cher et n'est pas agressif. J'ai essayé et ses effets se sont révélés incroyables, j'ai enfin retrouvé ma chevelure d'antan. Ma vie a changé, je ne suis plus le même homme, tout ça grâce à un seul fichier pour tout mon projet qui a été scientifiquement prouvé sur 40 personnes. Merci à vous.
Gilbert M., Coiffeur - Loire-Atlantique


Citation :

Enfin, nous avons maintenant accès à un véritable produit professionnel. C'est pour cela que je vous remercie. Je n'ai jamais, jamais rien vu d'aussi efficace ! Et dire que j'allais tout juste me décider à abandonner. C'est stupéfiant, les résultats de un seul fichier pour tout mon projet sont immédiats et durables. Je ne vous dis pas la tête de mon mari qui n'en revient toujours pas et mes enfants qui en sont ravis. Un grand merci pour vos produits.
Valérie V., Kinésithérapeute - Montpellier


Citation :

Je suis médecin et donc bien placé pour vous dire que je connais tous les produits. J'ai des tas de patients atteints de mauvaises performances et aucune solution véritable ne leur permettait d'en sortir. Un jour j'ai découvert un seul fichier pour tout mon projet et ses résultats fantastiques font que je le propose désormais à tous mes patients. Pour un prix modique, vous avez accès à une révolution.
Dr Leroux - Toulouse


Citation :

D'un naturel méfiant, et ne voyant pas le bout du tunnel, je n'y croyais plus. Lorsque mes amis m'ont parlé de un seul fichier pour tout mon projet dont ils étaient tous ravis et m'en vantaient les mérites, je n'ai pas voulu les croire. Jusqu'à ce que l'un d'eux m'en donne et que j'essaye. Depuis ce jour je n'ai pas cessé d'en acheter. Bien moins cher que les produits concurrents et beaucoup plus efficace, un seul fichier pour tout mon projet est un produit révolutionnaire. Bravo et merci à son inventeur.
Manuel Rodrigues - Belgique


Citation :

Je suis scientifique de formation, et j'avais des problèmes de mauvaises performances auquels je ne trouvais aucune solution jusqu'à ce que je découvre un seul fichier pour tout mon projet. C'est un produit formidable, vendu en pharmacie ou non, je suis la preuve vivante de son efficacité. Depuis, je le recommande autour de moi à mes amis, ma famille... un seul fichier pour tout mon projet est un produit révolutionnaire et il fera du bruit.
Martin C - Lille


---------------
TRIPS RIGHT BUNCH F SHUTTLE TOM AND JERRY RIGHT YELLOW
Reply

Marsh Posté le 25-11-2010 à 11:45:27    

poopidoo a écrit :

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 :-)


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... :lol:


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Marsh Posté le 25-11-2010 à 11:58:15    

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 ?  

Reply

Marsh Posté le 25-11-2010 à 12:01:33    

___alt a écrit :

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


 [:vapeur_cochonne]  [:vapeur_cochonne]  [:vapeur_cochonne]


---------------
marilou repose sous la neige
Reply

Marsh Posté le 25-11-2010 à 12:01:34    

poopidoo a écrit :

oui so what ? tu as un problème avec ça mon grand ? :-D  c'est pas ce qu'on t'a appris a ton ecole d'ingé EPita ? ce n'etait pas dans tes cours lundi ? Pour toi des jointures il en faut absolument ? bien bien. tu as tout fait raison. Après tout, si tout marche dans le meilleur des mondes, je ne vois pas pq on se fait chier à dev des nosql.

 

allez.. bye :-) je me barre vraiment pour le coup.

 

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.


Message édité par ___alt le 25-11-2010 à 12:03:08

---------------
TRIPS RIGHT BUNCH F SHUTTLE TOM AND JERRY RIGHT YELLOW
Reply

Marsh Posté le 25-11-2010 à 12:08:13    

___alt a écrit :

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

 
Citation :

Voici 3 mois, j'ai remarqué que j'étais concerné par mauvaises performances. Je n'étais pas bien dans ma peau et je me sentais très mal à l'aise. J'ai utilisé un seul fichier pour tout mon projet et dès la première semaine, j'ai remarqué une nette amélioration, une énorme différence. Aujourd'hui, je vais très bien grâce à un seul fichier pour tout mon projet, je ne pourrais plus m'en passer. Votre produit est unique ! Merci infiniment.
Martine D. - Paris - France

...

Citation :

Je suis scientifique de formation, et j'avais des problèmes de mauvaises performances auquels je ne trouvais aucune solution jusqu'à ce que je découvre un seul fichier pour tout mon projet. C'est un produit formidable, vendu en pharmacie ou non, je suis la preuve vivante de son efficacité. Depuis, je le recommande autour de moi à mes amis, ma famille... un seul fichier pour tout mon projet est un produit révolutionnaire et il fera du bruit.
Martin C - Lille



[:rofl]²²²²


Message édité par WiiDS le 25-11-2010 à 12:08:26

---------------
"I can cry like Roger. It's just a shame I can't play like him" - Andy Murray, 2010
Reply

Marsh Posté le 25-11-2010 à 12:10:31    

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


---------------
"I can cry like Roger. It's just a shame I can't play like him" - Andy Murray, 2010
Reply

Marsh Posté le 25-11-2010 à 12:20:25    

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

Reply

Marsh Posté le 25-11-2010 à 12:57:44    

MEI a écrit :


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


 
Inlining.  :o


Message édité par Anonymouse le 25-11-2010 à 13:01:12
Reply

Marsh Posté le 25-11-2010 à 13:30:21    

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 :o

 

À 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 :heink:

Message cité 1 fois
Message édité par esox_ch le 25-11-2010 à 13:32:00

---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 25-11-2010 à 13:43:09    

esox_ch a écrit :

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 :o
 
À 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 :heink:


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


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Marsh Posté le 25-11-2010 à 14:01:54    

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 !
 
 
 
:o

Reply

Marsh Posté le 25-11-2010 à 14:19:32    

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 :o

Reply

Marsh Posté le 25-11-2010 à 14:24:36    

poopidoo a écrit :

oui so what ? tu as un problème avec ça mon grand ? :-D  c'est pas ce qu'on t'a appris a ton ecole d'ingé EPita ? ce n'etait pas dans tes cours lundi ? Pour toi des jointures il en faut absolument ? bien bien. tu as tout fait raison. Après tout, si tout marche dans le meilleur des mondes, je ne vois pas pq on se fait chier à dev des nosql.
 
allez.. bye :-) je me barre vraiment pour le coup.


Je crois justement que toi, tu ne sais pas.


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 25-11-2010 à 15:09:45    

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


---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 25-11-2010 à 15:13:45    

rufo a écrit :

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

Code :
  1. 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...


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


---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed