Optimisation d'un site

Bonjour,

Je me posais une petite questions concernant l'optimisation d'un site.

Déjà, je pense qu'il faut favoriser les traitements PHP aux requêtes SQL, mais jusqu'à combien de requête peut-on juger que c'est acceptable pour le chargement d'une page ?
Ensuite, favoriser les traitements PHP par rapports aux requêtes, mais jusqu'à quel point ? Si je récupère un gros tableau et que je dois le parcourir 2 ou 3 fois avant d'afficher la page, n'est-il pas préférable de faire 2 requêtes en plus ?

Ensuite, que stocker en session, peut-on en abuser ? Doit-on se limiter à stocker le strict nécessaire kit à faire des requêtes en plus sur certaines pages pour récupérer des données ? Doit-on se promener avec sur les pages du site ? (pour certaines données, comme un id ou pseudo ?)

Pour finir, la visibilité d'un id dans l'url ou dans le code source est-il vraiment unsecure ? N'est-ce pas tout simplement une question de droit et d'accès aux pages ? (pour un profil utilisateur ou pour un mp par exemple)

Merci d'avance.

Citation:

---

Déjà, je pense qu'il faut favoriser les traitements PHP aux requêtes SQL (...)

---

En fait... non. Ou pas exactement.
Bon, ok, je m'explique.

La base de donnée est faite pour gerer les données le plus vite possible, des outils d'optimisations interne à la base existent justement pour gerer ces choses là. Ce que tu fait en php sera généralement plus lent.
Alors oui, faire une requete, necessite une communication avec la base et c'est ca qui peut être un peu long (toute proportion gardée hein). Ce qu'il faut limiter n'est donc pas le traitement fait par la base, mais le nombre de requete que tu envoies.
Après, pour le cas que tu proposes, deux requêtes de plus pour deux parcours de tableau de moins... à moins d'avoir des tableaux de taille gigantesque, sincèrement, je ne pense pas que ca fasse une différence visible dans un sens ou dans l'autre.

Pour le stockage en session, généralement, je stocke seulement l'idSession et j'ai le reste en base. La session est un fichier sur le serveur, les actes de lecture/écriture de fichiers sont ce qu'il y a de plus lent. Donc plutot lire juste un id et faire une requete, en plus, je trouve ca plus propre. Maintenant, pour être honnete, je n'ai jamais comparé les perfs des deux. Mais encore une fois, à moins d'avoir des quantités énormes de données, ce gain là sera franchement négligeable.

Ce qui peut par contre améliorer grandement les perfs, c'est la mise en place d'index sur tes tables.
Si les index ont été bien pensé, d'experience, les quelques problèmes de perfs restant que j'ai eu sur mes sites étaient surtout dû a des traitements php mal codé (dans ce cas la ben... faut refaire en mieux :aie:) ou très complexe (dans ce cas la... tu changes de machine pour en prendre une plus puissante :aie:)

Et puis sinon, après il reste les palliatifs, genre une gestion intelligence des caches par exemple.

Merci pour toutes tes réponses.

Je me demande quand même quel nombre de requête, pour le chargement d'une page, reste acceptable ?

Merci d'avance.

pour ma part pas de limite seul le traitement aval est lourd (sauf si tu as une requête merdique) cependant il faut garder une connexion permanente et non pas établir une connexion / déconnexion à chaque requêtes.

Ca ne veut rien dire "nombre minimum de requete acceptable". Un select count(*) from maTable avec maTable qui possède 10 lignes sera infiniment plus rapide qu'une requete avec cinq jointures sur des tables ayant des milliers d'enregistrement chacune.

Dans le domaine de l'optimisation, à moins d'être un expert capable de déterminer par avance quels points précis de quels traitements peuvent poser problème, le plus simple reste la méthode empirique.
Tu fais ta page, et si elle mets trop de temps à s'afficher, tu cherches à quel endroit est le goulot d'étranglement.

Ma toute premiere véritable optimisation de page m'a pris deux semaine. C'était une page super complexe qui devait calculer et remplir un tableau avec la liste des employés d'une boite en fonction de leur affectation habituelle, leur compétence, leur disponibilité et je ne sais plus quoi d'autre. Elle mettait 30 seconde a se calculer. J'ai tout optimisé un par un (ne plus utiliser le framework pour faire les requêtes mais les passer en direct, eviter les reconnexion inutiles, etc...), mais ca foirait toujours. Finalement, en analysant vraiment ce qui prenait du temps, j'ai fini par tomber sur un bout de code, avec trois boucles for imbriquées et du coup, un ou deux millions d'itérations.
Au final, en réduisant le nombre de boucle et en optimisant le tout petit bout de code au milieu, c'est la que j'ai enfin eu des temps acceptables.

Bref, tout ca pour dire que si t'es a peu près propre quand tu codes, normalement, tu ne devrais pas te heurter à de vrai problème d'optim jusqu'a ce que tu fasses des traitements de brute, et a ce moment là, il sera temps d'analyser ou pèche et faire une optim ciblée et efficace.

En fait j'ai mal posé ma question par rapport à ton premier post... Pour un site "grand public" en combien de temps doit s'afficher une page ? Vous me direz que ça dépend aussi de la puissance du serveur mais bon... Je ne sais pas vraiment comment posez ma question, si elle a lieu d'être...

Ah, ca c'est une question differente. Eventuellement à confirmer, mais il me semble avoir lu qu'on estime qu'au dela de deux secondes, il y a risque que le visiteur ferme la page.
Par contre, c'est deux secondes "réelle". Ca n'est pas seulement le temps de traitement de la page, le chargement des images est compris avec.
D'expérience, je dirais que le tout premier affichage tolère assez facilement trois ou quatre secondes, mais qu'une fois les images mise en cache, pour la navigation interne dans le site, plus d'une ou deux secondes par changement de page devient génant pour la navigation.

D'accord, merci de vos réponses ! :)

Ah, j'avais oublié, par rapport au fait d'avoir l'id des utilisateurs, messages, etc... visible par les autres utilisateurs, est il réellement un problème ?

Pas nécessairement si derriere c'est bien fait.
Mettons que tu as une url : du genre : page?id=monid qui affiche tes infos personnelle.
Si l'url des gens est visible et qu'en remplacant "monid" par l'id du voisin du coup, tu vois les infos personnelles du voisin, c'est mal.
Si il y a détection que tu n'a pas le droit d'afficher cette page même si l'id du voisin est la bonne, alors ca ne pose pas de soucis.

Avoir un id visible donne une info sur le site, et moins un hacker potentiel a d'infos, plus difficile est la mise en oeuvre d'une action de piratage. C'est surtout pour ca qu'il faut éviter de trop montrer les id.

D'accord, merci de cette précision !