Question Performance...Résolu

Question

Bonjour,

Je developpe presentement un site en php.
Je me suis toujours poser cette question:
Niveau performance... es-ce plus rapide de storer le texte a afficher (5-15 ko max par page) dans une fichier php separer (et de faire un include) ou dappeler le texte via MySQL ?

En prennant compte qu'il y ai beaucoup de visiteurs...

Merci et bonne journee! 

Laurent

neigedhiver · Accepted Answer

Salut,

La mise en cache est toujours préférable. Même si les moteurs de bases de données sont optimisées pour retourner rapidement un résultat récurrent qui n'a pas été modifié entre 2 requêtes, il est quand même judicieux de stocker en cache (fichier php, texte brut, html, qu'importe) du texte qui ne change pas et qui est rarement modifié.
Pour un forum, par exemple, ce n'est pas vraiment pertinent, à moins qu'il ne s'agisse de vieux vieux messages qui n'ont plus de réponses.
Pour des articles qui ne sont que très peu édités après leur publication, la mise en cache est préférable.
Parce qu'il ne faut pas tenir compte que de la requête en elle-même, mais également du transfert des données qui se fait le plus souvent par TCP (même si les serveurs bdd et http sont sur la même machine, ça surcharge quand même la couche réseau pour rien).
Cependant, pour des raisons pratiques, stocker le texte dans la base de données est tout à fait justifié. Il doit servir pour regénérer les fichiers de cache lors d'une modification, par exemple.

<hr size="2" width="100%" />Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

ELCouz · Answer

Merci [auteur/NEIGEDHIVER/924195.aspx neigedhiver]pour ta reponse,

mais si je me trouve avec 100 petits fichier php contant juste le text html (5-15ko)dont je charge dynamiquement pas toute a la fois car cest inutile...

je texplique jai une page avec un menu et dans la parti texte (au centre) je call le bon include si index.php?page=about ben sa va charger inc/about.php qui a une simple variable <?php $body = "about us
blabla

"; ?> dans ma page index jai alors un echo $body...

la question que je me pose c'est es-ce que les fichiers vont etre garder en cache (ram) sur le serveur , ou sa va etre tres lent a cause qui reli tjrs les petit fichiers php sur le disque dur a chaque changement de page ?

car si c'est le cas vaut mieu utiliser la bdd qui elle est en memoire !

Merci beaucoup
Laurent

neigedhiver · Answer

Ben oui, mais non...
Comme je te le disais, entre la bdd et PHP les données transitent le plus souvent par TCP, pour la simple et bonne raison que généralement le serveur de base de données et le serveur HTTP ne sont pas installés sur la même machine. Il y a donc trafic réseau, qui encombre la bande passante et ralenti la navigation d'une manière générale.
Mais il faut avouer que ça n'a pas de réelle incidence dans les cas suivants :
- peu de fichiers
- peu de trafic
- fichiers de très petite taille

Mais plus ces paramètres augmentent, plus ça ralenti...
L'accès disque est très rapide... Je me permet de signaler qu'en règle générale, les serveur des hébergeurs sont des machines Linux et que le système de fichiers n'est pas du NTFS... Les performances n'ont rien à voir à ce niveau là avec un pc windows (donc ne te fie pas à ta machine). Ce sont des machines optimisées pour ce traitement.

En plus, tout le contenu de la base de données n'est pas stocké en mémoire (arf, imagine si c'était le cas rien que sur phpCS !). Le sont surtout les index, et ce pour les tables les plus sollicitées. Autrement, il y a AUSSI un accès disque sur le serveur de base de données, en plus des requêtes et du transfert de données.

On a tendance à mettre un peu tout et n'importe quoi dans une base de données... C'est un tort. Quand un CMS stocke l'intégralité des articles dans la base de données, pour certains images inclues (sic), c'est une abération.
Typiquement, on devrait stocker dans une base de données des informations qui sont amenées à changer régulièrement, qui nécessitent un traitement particulier (c'est quand même l'intérêt des jointures, des requêtes imbriquées, etc).
On devrait stocker dans des fichiers ce qui n'a pas besoin d'être traité par le moteur de base de données : du texte, des paramètres de configuration, etc.

Pose-t-oi simplement la question suivante : en quoi le moteur de base de données peut apporter quelque chose au traitement de pages HTML ?
Si ce n'est que tu vas le mobiliser pour faire ce qu'un système de fichiers fait très bien (mieux !), rien.
Stocke des commandes, des clients, des articles, qui nécessitent des rapprochements, de filtrer des recherches selon des critères, de compter, etc... Mais pas du texte que tu vas juste stocker...

<hr size="2" width="100%" />Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

coucou747 · Answer

le tout en bdd ou pas, c'est un gros debat... sur codes-sources, c'est pas un seul serveur http non plus... ca explique qu'actuellement, j'ai deux avatars :) (c'est pas le meme sur chaque serveur)
tout mettre en sql, t'as raison, pour les perfs, c'est pas bon, mais c'est pas pour autant une aberation, cote proprete, fiabilite, et portabilite, ca peut se justifier
/**
* @author coucou747 <coucou747@hotmail.com>
* @see irc://cominweb.uni-irc.net/#programmation
*/

yoman64 · Answer

Salut,

La base de données n'est pas en mémoire comme tu semble le penser. Sur mon serveur j'ai environ 5Go de base de données, tu imagines la quantitée de ram que ça prenderait ? Et sur codes-souces c'est énorme comme quantitée d'informations.

C'est "beaucoup" plus lent de passer par une base de données. Parce qu'en plus de devoir établir une connexion tcp vers le serveur de base de données (parfois via un socket local donc moin d'incidence mais bon..) ensuite la base de donnée doit lire sur le disque dur et faire une "recherche" pour trouver l'enregistrement que tu veux (il y a un cache pour les requêtes fréquentes, mais ça n'eneleve pas que le serveur doit recevoir,parser,résoudre et répondre à la requete ;) ).

Si tu prends en compte tout cela la base de données est bien plus lente.
C'est donc beaucoup plus rapide par des fichiers textes, mais c'est évidement "moin pratique".

Pour en revenir à codes-sources, la quasi totalité des informations (sources, liste de sources,zip de source ,etc) est dans la base de données. Et la plupart de ces informations la sont mise en cache sur le serveur, pour des questions de performance évidente, le serveur de base de donnée serait mort depuis longtemps aux nombres de hits reçu chaque heure ici.

Comme dit neigedhiver, la plupart des CMS sont des abérations (je ne sais pas si tu généralisait neige, mais moi je le fais :)) Ils stockent tout en base de données, on se ramasse avec 150 tables et des pages qui font 20-30 requêtes SQL par affichage c'est ridicule...

Et pour ce que tu comptes faire , la plupart du temps c'est via des fichiers texte que ça se passe (avec un minimum de sécurité évidement).

Donc les fichiers textes sont préférables, SURTOUT si tu as beaucoup de visiteurs ;)

-------------------
Vous cherchez un hebergement Php/MySQL Gratuit et sans publicités ?? 
Et bien c'est la : www.e3b.org

yoman64 · Answer

J'oubliais de dire que si tu tiens à mettre ça en base de données, pour des questions pratiques, tu peux toujours faire cohabiter les deux. Tu fais un cache, comme ça si 1000 hits arrivent rapidement sur une page, ben il a juste a relire un fichier texte qui est rafraichie à chaque X minutes, donc une seule requete de temps en temps.

@coucou747: Je me demandais aussi pourquoi ton avatar changeait sans arrêt 

-------------------
Vous cherchez un hebergement Php/MySQL Gratuit et sans publicités ?? 
Et bien c'est la : www.e3b.org

ELCouz · Answer

Wow merci de vos explications!

Très instructif 

Je vais me tenir aux fichiers, au fait je parlais dune bdd qui fait moins de 100 mb ;) evidamment que c'est storer dans un fichier car sinon il faudrais 32 go de ram juste pour Code-Source 

Tu as raison, ma bdd est a distance mais comme je me suis dit j'aime mieu balancé les ressources disponible car j'utilise un «shared hosting» et dependament des hebergeur certains vont meme couper temporairement ton compte payant pour trop de ressource utiliser (voir effet slashdot).

Bonne journee !

Laurent

malalam · Answer

Hello,

ce thread est terminé je sais :-) Mais je voulais ajouter mon avis (inutile en réalité puisqu'il va dans le sens de ce que qui a été dit), fort de mon expérience :-)
Utiliser à tout prix ou non la base de données n'est pas qu'un problème de performances pures. La base de données reste le centre de la plupart des applicatifs web. Mais justement, elle est très sollicitée...donc quand on peut la soulager, autant le faire. 
Le principe d'un site comme CS, pour les codes, par exemple, est le suivant (j'imagine hein, je n'ai jamais vu le code ou même la structure de CS) : les codes sont stockés en base, et mis en cache dans le système de fichiers. Quand l'auteur d'un code fait une modif, on modifie la base, puis (là vraiment j'extrapole, parce que le reste j'en suis à peu près sûr...disons que c'est ce que je ferais) flague, dans la base, la date de modif. Régulièrement, une requête vérifie ce flag de modification, et actualise le système de fichiers de cache pour tout code ayant bougé depuis la dernière fois. 

Un DBA (même un excellent), aura tendance à tout faire avec  la bdd. A raison généralement : on PEUT tout faire. Voire même des choses que nous autres, simples développeurs, ne soupçonnons même pas (mise en cache par exemple...). Le problème ne vient pas des performances : je suis à peu près persuadé qu'un bon DBA se démerdera pour avoir d'aussi bonnes perfs que moi avec mon code. Voire meilleures. Sauf que plus y a d'accès à la base, plus sa solution se déteriorera. Faire du load-balancing, c'est aussi ça : on équilibre entre le serveur web, et le serveur DB (si tant est qu'ils soient différents, évidemment...mais là, je parle en tant que professionnel qui utilise différent serveurs...ceci dit, c'est aussi généralement le cas dans le cadre d'un hébergement mutualisé).

C esystème de doublons (même infos, décalées, entre la bdd et un système de fichiers) a aussi un avantage dans le cas de validation des données. Curieusement, on en vient à ce que les fichiers fassent foi : je place une configuration à la fois en bdd et sur un fichier xml. Une modification est faite : je mets à jour ma base. Pas mon fichier...la modification est soumise à validation : je mets à jour mon fichier. Et mon applicatif web va chercher la conf toujours dans le fichier, jamais en base. Bon là, question perf, on y perd (l'accès  un fichier xml + son "parsing" sera plus lent que l'accès à une bdd), mais on y gagne en facilité d'utilisation, et la base est soulagée. 

Enfin, je rejoins les remarques suivantes : mettre en cache  du texte qui est amené à peu changer est très bien. C'est le même principe que mon exeple sur un fichier de conf , le parsing XML en moins. Et moi, quand je "cache", je "cache" la page html. Ainsi, je n'ai plus qu'à l'afficher bêtement. Plutôt que d'aller chercher le texte en bdd, puis l'incorporer à mon template HTML (parsing), et enfin afficher le résultat.

ELCouz · Answer

>>ce thread est terminé je sais

Un thread n'est jamais terminé car il y a toujours place a l'amelioration peu importe le sujet ...

Merci [auteur/MALALAM/58031.aspx malalam] pour ton point de vue 

Bonne journee !

Laurent

Question Performance...

9 réponses

Votre réponse

Discussions similaires