J’ai le problème suivant :
Je construis un site en php/mysql et j’ai une page “article”. Par défaut, j’affiche la liste des 10 articles les plus récents avec pour chaque : le titre, la date, les 3 premières lignes de l’article.
Si le visiteur clique sur un article ça affiche l’article en question avec des liens vers l’article suivant et précédent et vers la liste des articles (page par défaut).
Je me suis dit que si je refaisais une requête SQL à chaque fois qu’on clique sur suivant/précédent, ça allait être lourd. J’ai donc pensé à la méthode suivante.
1 - je fait une requête globale
2 - je charge la requête dans un tableau.
3 - je met le tableau dans une variable $_session.
Ainsi, un seul accès à la base, après tout est en mémoire.
J’ai scripté ça, mais ça ne fonctionne pas :
if (!isset($_SESSION['tableau'])){$tableau = recup_articles();}
else {$tableau = $_SESSION['tableau'];}
for ($idxk = 0; $idxk=1;$idxk++){
for ($idxl = 0; $idxl=6;$idxl++){echo $tableau[$idxk][$idxl];}
}
Function recup_articles(){
$sql = "SELECT num,titre,dateheure,categorie,photo,texte FROM articles ORDER BY num DESC LIMIT 10";
$req = mysql_query($sql) or die('Erreur SQL !<br />'.$sql.'<br />'.mysql_error());
$idxj=0;
while ($row = mysql_fetch_array($req, MYSQL_NUM)) {
$tab[$idxj] = $row;
$idxj++;
}
$_SESSION['tableau'] = $tab;
return $tab;
}
J’ai deux questions :
1 - Ma démarche est-elle optimale ?
2 - Quelqu’un comprend-il pourquoi mon code ne marche pas ?
Merci grandement pour votre aide,
Edité le 14/05/2009 à 11:42
A mon avis non
Je n’ai jamais vu procéder de la sorte, pour moi on va toujours chercher ce que l’on veut dans la base en temps et en heure.
Ton système de fonctionnement va consommer énormément de mémoire si il y a beaucoup de visiteur sur ton site (1 session par visiteur), et en plus, dans chaque session seront stockées les mêmes informations !
Pour le serveur, aller chercher les 10 premiers enregistrements d’une table est une opération très banale et légère, même si la table contient beaucoup d’enregistrements. En plus le serveur de base de données contient lui-même ses propres buffers et se débrouille avec.
Avec ton système, non seulement tu envoies des requêtes au serveur, mais en plus tu remplis ta mémoire. Alors même si au final il y a moins de requêtes, ton système est une usine à gaz dans l’âme On pourrait l’utiliser à la rigueur dans certains cas où les requêtes SQL sont extrêmement lourdes, mais ça reste des cas isolés.
Et pis tiens… un chtite question : une fois que tes 100 visiteurs à l’instant T ont les articles en session, un boulet change le contenu d’un des articles. Comment tu fais pour que tes visiteurs obtiennent le nouveau contenu de l’article en question ?
C’est quoi les erreurs que php t’affiche ?
Edité le 14/05/2009 à 07:49
Je vais prendre tes questions dans le désordre :
2 - En imaginant que j’ai une erreur de syntaxe (genre un “;”) PHP m’affiche l’erreur sur ma page.
Mais là, il ne m’affiche rien (du tout) : page vierge, même pas ce qui précède, que dalle.
1- optimisation :
Quelques précisions : c’est le site d’une association d’escalade, et c’est hébergé chez “free”
[spoiler]là c’est le site de “simu”, c’est la page news que je trouve lente et que je souhaite optimiser par le code ci-dessus : quand on clique sur “lire la suite” sur un article, je trouve que ça met beaucoup trop de temps à l’afficher. http://cmarchand74.free.fr/[/url] en fait si on compare avec le site actuel, [url=http://asaescalade.free.fr]http://asaescalade.free.fr, je trouve que c’est beaucoup plus lent (peut-être que ça ne vient pas des requêtes remarques)[/spoiler].
Niveau visiteurs : si y’en a 5 en même temps, c’est qu’on a battu un record (j’imagine car j’ai pas encore mis de stat).
Donc niveau espace mémoire, je pense que ça ne devrait pas être un problème.
Niveau articles : probablement une trentaine d’enregistrement par an. Donc, pour le rafraichissement Real Time, je m’en moque.
Voilà, par ailleurs, n’hésites pas à me dire si tu trouves qu’il y’a d’autre améliorations que je peux apporter… ou des trucs qui te paraissent “bof”:).
Au départ je craignais que ça vienne de free, mais on remarque que le site “prod” actuel est quand même plus rapide que le site simu, donc je pense vraiment à un problème dans mon code, d’où ma démarche d’optimisation.
PS : Il ne sont sans doute pas hébergé sur la même machine chez free, ça joue peut-être aussi
PS2 : je ne cherche pas un debugger à l’oeil, si j’en viens à poster sur le forum, c’est que j’ai cherché pendant, longtemps
Etant donné ta volumétrie, la démarche optimale consisterait à oublier la table des articles.
Edit : Ceci dit, je pense que ce que j’aurais à te proposer n’est pas adapté à la situation.
Sinon, tu devrais suivre maverick911 et taper tout le temps en base. Je ne soutient pas le reste de ses propos, mais c’est quand meme une solution simple.
Edité le 14/05/2009 à 10:52
-> Vitamin1981 :
Ok, je comprend, mais le problème, c’est qu’en fait, une fois le site terminé je souhaiterais ne pas trop toucher au contenu, j’entends par là que les membres du bureau de l’association devront être en mesure de poster du contenu (des articles) sans mon aide … et sans connaissance en informatique (c’est un mini CMS quoi.). D’où la nécessité de passer par une base de donnée, plutôt que d’avoir une page statique.
Accessoirement, je voudrais laisser aux visiteurs, la possibilité de consulter les articles plus anciens… Au bout d’un moment, ça va être ingérable si c’est pas dynamique…
Edité le 14/05/2009 à 11:14
Avoir une base de données (même petite) est la solution la plus simple et la plus évolutive, car si un jour tes besoins changent et que les articles et les visiteurs affluent, tu n’auras rien à changer.
Par contre si tu veux avoir un système vraiment dynamique, le faire toi-même peut devenir compliqué, il peut alors être judicieux d’utiliser un CMS.
Si ce n’est pas la solution que tu choisis, je regarde ton code dès que j’ai un moment
Sauf que cette page statique aurait tres bien pu être gérée d’une facon ou d’une autre. Mais passons, une base fait aussi l’affaire.
maverick911 :
le principe de recourir systématiquement à une base de données relationnelle.
les 10 premiers enregistrements d’une table est une opération très banale et légère, même si la table contient beaucoup d’enregistrements.
Edité le 14/05/2009 à 11:09
Pour la base, oui, c’est ce que je me dis aussi, certes, je pourrais proposer aux “posteurs” un bouton “publier” qui mettrait à jour une page statique, mais ça me parait moins propre et moins évolutif qu’une base…
Pour la légèreté des requêtes, je suis d’accord avec vous deux, mais alors, pourquoi est-ce si long à l’affichage ? (environ 4 secondes quand on clique sur “lire la suite” dans un article). En fait, ce que je me pose comme question, c’est : est-ce que la lenteur vient de mon code (par erreur ou manque d’optimisation) ou de la lenteur des traitements sur le serveur de free (j’ai cru comprendre que c’était loin d’être “top” en PHP). Mon avis perso va vers un pb de programmation, puisque même si free est lent, il héberge des sites beaucoup plus lourds et compliqués que le mien…
En gros, je souhaites rester sur ce type de config (avec BDD) mais en améliorant les perfs si possible.
PyrO_70 : J’ai déjà fait tout ça, de plus, cette page ne fait appel qu’à une seule table (pas de relation). Y’a bien un index sur “num”.
Bon, faut dire qu’il n’y a pas que ça qui s’affiche sur cette page, y’a environ 80ko d’image + je parse du xml reçu de l’agenda google.
Disons, que je pense que l’affichage des articles me fait perdre environ 1 à 2 secondes, ce que je trouve déjà énorme…
Bah il doit y avoir une couille quelque part alors, je vois pas comment un requete de 10 articles peut prendre 2sec. Peut etre nous faut-il plus d’info sur la page complet pour trouvé un solution correct. L’utilisation de la session pour géré ca, c’est nul :heink:
J’ai fait pas mal d’optimisation sur le site :
j’ai refait les menus en utilisant un rollover css avec une seule grande image, plutôt que 14 petites.
J’ai ainsi économisé 25% du poids de la page.
J’ai ensuite désactivé le parsing XML du RSS de l’agenda google, et j’ai retesté… Et là c’est presque instantané… donc on fait, ce qui ralentit le plus ma page c’est le parsing de l’agenda gmail…, mais là je pense que je vais avoir du mal à améliorer le résultat, c’est la récupération du flux RSS qui doit prendre du temps… L’impression que j’ai eu de la lenteur du sql vient du fait que c’est ce qui s’affiche en dernier sur ma page…
Donc désolé pour le dérangement, cela dit, je suis content de savoir que la solution que j’ai utilisé dès le début était la bonne ! C’est déjà ça…
On pourrait l’utiliser à la rigueur dans certains cas où les requêtes SQL sont extrêmement lourdes, mais ça reste des cas isolés.