J'ai recréé mon site perso comme je me l'étais promis, je me suis pris au
jeu de l'accessibilité "sur mesure", bref j'ai besoin d'un système de
sessionning,
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
Evidemment c'est incontournable, et seulement optimisable, quand on utilise
vraiment les possiiblités d'un SGBDR en faisant des inner join et consorts.
De même, les requêtes sont prédéfinies, et donc on pourrait rêver de les
compiler au lieu de les passer en SQL avec ré-analyse syntaxique à chaque
fois.
Et de même il y a le relogin systématique du même utilisateur (en fait celui
qui est gravé dans le script concerné),
* Ce qui me conduit à me demander si pour ce genre d'application, il ne vaut
pas mieux remplacer la base mySQL par une base locale construite sur mesure
avec un script bien câblé et des fichiers de données locaux.
Le but est de trouver des retours sur l'amélioration constatée des
performances et les éventuels problèmes de fiabilité/sécurité ;
notamment c'est la concurrence (version Web de la programmation
thread-safe) qui me préoccupe.
J'ai recréé mon site perso comme je me l'étais promis, je me suis pris au
jeu de l'accessibilité "sur mesure", bref j'ai besoin d'un système de
sessionning,
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
Evidemment c'est incontournable, et seulement optimisable, quand on utilise
vraiment les possiiblités d'un SGBDR en faisant des inner join et consorts.
De même, les requêtes sont prédéfinies, et donc on pourrait rêver de les
compiler au lieu de les passer en SQL avec ré-analyse syntaxique à chaque
fois.
Et de même il y a le relogin systématique du même utilisateur (en fait celui
qui est gravé dans le script concerné),
* Ce qui me conduit à me demander si pour ce genre d'application, il ne vaut
pas mieux remplacer la base mySQL par une base locale construite sur mesure
avec un script bien câblé et des fichiers de données locaux.
Le but est de trouver des retours sur l'amélioration constatée des
performances et les éventuels problèmes de fiabilité/sécurité ;
notamment c'est la concurrence (version Web de la programmation
thread-safe) qui me préoccupe.
J'ai recréé mon site perso comme je me l'étais promis, je me suis pris au
jeu de l'accessibilité "sur mesure", bref j'ai besoin d'un système de
sessionning,
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
Evidemment c'est incontournable, et seulement optimisable, quand on utilise
vraiment les possiiblités d'un SGBDR en faisant des inner join et consorts.
De même, les requêtes sont prédéfinies, et donc on pourrait rêver de les
compiler au lieu de les passer en SQL avec ré-analyse syntaxique à chaque
fois.
Et de même il y a le relogin systématique du même utilisateur (en fait celui
qui est gravé dans le script concerné),
* Ce qui me conduit à me demander si pour ce genre d'application, il ne vaut
pas mieux remplacer la base mySQL par une base locale construite sur mesure
avec un script bien câblé et des fichiers de données locaux.
Le but est de trouver des retours sur l'amélioration constatée des
performances et les éventuels problèmes de fiabilité/sécurité ;
notamment c'est la concurrence (version Web de la programmation
thread-safe) qui me préoccupe.
Le Mon, 13 Mar 2006 18:03:15 +0100, Patrick 'Zener' Brunet a écrit :J'ai recréé mon site perso comme je me l'étais promis, je me suis
pris au jeu de l'accessibilité "sur mesure", bref j'ai besoin d'un
système de sessionning,
Si vous parlez des sessions (sinon je ne sais pas ce que le
«sessionning»)
il n'est pas nécessaire d'utiliser un SGBDR pour gérer
les sessions. Cela peut-être avec des fichiers texte, ou avec des
démons comme memcached.
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
C'est mesuré ou prédit comme valeur ?
Si c'est mesuré, comment ?
Evidemment c'est incontournable, et seulement optimisable, quand on
utilise vraiment les possiiblités d'un SGBDR en faisant des inner
join et consorts.
On peut faire que ce ne soit pas la base de données l'élément
limitant.
De même, les requêtes sont prédéfinies, et donc on pourrait rêver de
les compiler au lieu de les passer en SQL avec ré-analyse syntaxique
à chaque fois.
C'est à cela que servent les «prepared statements». Les bons SGBDRs
gardent les résultats de leur «compilation».
Et de même il y a le relogin systématique du même utilisateur (en
fait celui qui est gravé dans le script concerné),
Si vous parlez de connection à la base, cela peut se conserver, même
si MySQL n'est pas couteux à ce niveau là. Regardez du côté des
connexions persistantes, ou sinon de solution plus mousse costo, dans
la catégorie «DB pooling»
* Ce qui me conduit à me demander si pour ce genre d'application, il
ne vaut pas mieux remplacer la base mySQL par une base locale
construite sur mesure avec un script bien câblé et des fichiers de
données locaux.
Personnellement, j'ai très peu compris dans ce qui précède, vos causes
qui entraineraient une telle conséquence, assez radicale.
Le but est de trouver des retours sur l'amélioration constatée des
performances et les éventuels problèmes de fiabilité/sécurité ;
notamment c'est la concurrence (version Web de la programmation
thread-safe) qui me préoccupe.
Il n'y a pas 50000 façons différentes de gérer la concurrence : cela
l'impose d'avoir un SGBDR avec des transactions, voire un «two phase
commit»
Sinon, c'est du bricolage qui ne tient pas la route.
Le Mon, 13 Mar 2006 18:03:15 +0100, Patrick 'Zener' Brunet a écrit :
J'ai recréé mon site perso comme je me l'étais promis, je me suis
pris au jeu de l'accessibilité "sur mesure", bref j'ai besoin d'un
système de sessionning,
Si vous parlez des sessions (sinon je ne sais pas ce que le
«sessionning»)
il n'est pas nécessaire d'utiliser un SGBDR pour gérer
les sessions. Cela peut-être avec des fichiers texte, ou avec des
démons comme memcached.
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
C'est mesuré ou prédit comme valeur ?
Si c'est mesuré, comment ?
Evidemment c'est incontournable, et seulement optimisable, quand on
utilise vraiment les possiiblités d'un SGBDR en faisant des inner
join et consorts.
On peut faire que ce ne soit pas la base de données l'élément
limitant.
De même, les requêtes sont prédéfinies, et donc on pourrait rêver de
les compiler au lieu de les passer en SQL avec ré-analyse syntaxique
à chaque fois.
C'est à cela que servent les «prepared statements». Les bons SGBDRs
gardent les résultats de leur «compilation».
Et de même il y a le relogin systématique du même utilisateur (en
fait celui qui est gravé dans le script concerné),
Si vous parlez de connection à la base, cela peut se conserver, même
si MySQL n'est pas couteux à ce niveau là. Regardez du côté des
connexions persistantes, ou sinon de solution plus mousse costo, dans
la catégorie «DB pooling»
* Ce qui me conduit à me demander si pour ce genre d'application, il
ne vaut pas mieux remplacer la base mySQL par une base locale
construite sur mesure avec un script bien câblé et des fichiers de
données locaux.
Personnellement, j'ai très peu compris dans ce qui précède, vos causes
qui entraineraient une telle conséquence, assez radicale.
Le but est de trouver des retours sur l'amélioration constatée des
performances et les éventuels problèmes de fiabilité/sécurité ;
notamment c'est la concurrence (version Web de la programmation
thread-safe) qui me préoccupe.
Il n'y a pas 50000 façons différentes de gérer la concurrence : cela
l'impose d'avoir un SGBDR avec des transactions, voire un «two phase
commit»
Sinon, c'est du bricolage qui ne tient pas la route.
Le Mon, 13 Mar 2006 18:03:15 +0100, Patrick 'Zener' Brunet a écrit :J'ai recréé mon site perso comme je me l'étais promis, je me suis
pris au jeu de l'accessibilité "sur mesure", bref j'ai besoin d'un
système de sessionning,
Si vous parlez des sessions (sinon je ne sais pas ce que le
«sessionning»)
il n'est pas nécessaire d'utiliser un SGBDR pour gérer
les sessions. Cela peut-être avec des fichiers texte, ou avec des
démons comme memcached.
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
C'est mesuré ou prédit comme valeur ?
Si c'est mesuré, comment ?
Evidemment c'est incontournable, et seulement optimisable, quand on
utilise vraiment les possiiblités d'un SGBDR en faisant des inner
join et consorts.
On peut faire que ce ne soit pas la base de données l'élément
limitant.
De même, les requêtes sont prédéfinies, et donc on pourrait rêver de
les compiler au lieu de les passer en SQL avec ré-analyse syntaxique
à chaque fois.
C'est à cela que servent les «prepared statements». Les bons SGBDRs
gardent les résultats de leur «compilation».
Et de même il y a le relogin systématique du même utilisateur (en
fait celui qui est gravé dans le script concerné),
Si vous parlez de connection à la base, cela peut se conserver, même
si MySQL n'est pas couteux à ce niveau là. Regardez du côté des
connexions persistantes, ou sinon de solution plus mousse costo, dans
la catégorie «DB pooling»
* Ce qui me conduit à me demander si pour ce genre d'application, il
ne vaut pas mieux remplacer la base mySQL par une base locale
construite sur mesure avec un script bien câblé et des fichiers de
données locaux.
Personnellement, j'ai très peu compris dans ce qui précède, vos causes
qui entraineraient une telle conséquence, assez radicale.
Le but est de trouver des retours sur l'amélioration constatée des
performances et les éventuels problèmes de fiabilité/sécurité ;
notamment c'est la concurrence (version Web de la programmation
thread-safe) qui me préoccupe.
Il n'y a pas 50000 façons différentes de gérer la concurrence : cela
l'impose d'avoir un SGBDR avec des transactions, voire un «two phase
commit»
Sinon, c'est du bricolage qui ne tient pas la route.
* Ce qui me conduit à me demander si pour ce genre d'application, il ne vaut
pas mieux remplacer la base mySQL par une base locale construite sur mesure
avec un script bien câblé et des fichiers de données locaux.
Personnellement, j'ai très peu compris dans ce qui précède, vos causes
qui entraineraient une telle conséquence, assez radicale.
* Ce qui me conduit à me demander si pour ce genre d'application, il ne vaut
pas mieux remplacer la base mySQL par une base locale construite sur mesure
avec un script bien câblé et des fichiers de données locaux.
Personnellement, j'ai très peu compris dans ce qui précède, vos causes
qui entraineraient une telle conséquence, assez radicale.
* Ce qui me conduit à me demander si pour ce genre d'application, il ne vaut
pas mieux remplacer la base mySQL par une base locale construite sur mesure
avec un script bien câblé et des fichiers de données locaux.
Personnellement, j'ai très peu compris dans ce qui précède, vos causes
qui entraineraient une telle conséquence, assez radicale.
il n'est pas nécessaire d'utiliser un SGBDR pour gérer
les sessions. Cela peut-être avec des fichiers texte, ou avec des
démons comme memcached.
C'est donc peut-être vers ce genre de solutions que je veux aller.
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
C'est mesuré ou prédit comme valeur ?
Si c'est mesuré, comment ?
C'est une estimation grossière, qui de plus a valeur de moyenne d'un moment
à une autre.
J'aimerais bien affiner, mais je n'ai pas la maîtrise du serveur
d'hébergement, et chez moi sur EasyPHP le chargement est bien sûr
instantané. Ce qui confirmerait d'ailleurs le diagnostic...
Je veux bien, mais donc mon propos est de dire que pour cette
application, le choix standard est finalement surdimensionné. Au fait
j'en profite pour préciser qu'il y a de bonnes raisons pour lesquelles
ce site a besoin de sessions, et ne doit pas reposer sur les cookies ni
Le code est donc complètement stateless, à part l'identifiant de
session renvoyé avec les requêtes HTTP.
Or celui-là pour l'utiliser, il faut accéder à la base, et donc faire
un mysql_connect(), lequel inclut donc un login avec les identifants
imposés par mon ISP.
A vrai dire j'ai pas mal progressé en PHP depuis 6 mois, mais je ne
vois pas comment contourner ce problème et retrouver mes ressources
systèmes d'une requête à l'autre.
Je suis en mesure d'écrire un système séquentiel indexé pour faire
ce que fait actuellement pour mon site la base de données, je maîtrise
plutôt bien les mutex, et je n'ai pas une réputation de bricoleur dans
le codage :-)
Mais donc ça m'intéresserait assez de savoir si d'autres ont déjà
envisagé ce problème.
il n'est pas nécessaire d'utiliser un SGBDR pour gérer
les sessions. Cela peut-être avec des fichiers texte, ou avec des
démons comme memcached.
C'est donc peut-être vers ce genre de solutions que je veux aller.
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
C'est mesuré ou prédit comme valeur ?
Si c'est mesuré, comment ?
C'est une estimation grossière, qui de plus a valeur de moyenne d'un moment
à une autre.
J'aimerais bien affiner, mais je n'ai pas la maîtrise du serveur
d'hébergement, et chez moi sur EasyPHP le chargement est bien sûr
instantané. Ce qui confirmerait d'ailleurs le diagnostic...
Je veux bien, mais donc mon propos est de dire que pour cette
application, le choix standard est finalement surdimensionné. Au fait
j'en profite pour préciser qu'il y a de bonnes raisons pour lesquelles
ce site a besoin de sessions, et ne doit pas reposer sur les cookies ni
Le code est donc complètement stateless, à part l'identifiant de
session renvoyé avec les requêtes HTTP.
Or celui-là pour l'utiliser, il faut accéder à la base, et donc faire
un mysql_connect(), lequel inclut donc un login avec les identifants
imposés par mon ISP.
A vrai dire j'ai pas mal progressé en PHP depuis 6 mois, mais je ne
vois pas comment contourner ce problème et retrouver mes ressources
systèmes d'une requête à l'autre.
Je suis en mesure d'écrire un système séquentiel indexé pour faire
ce que fait actuellement pour mon site la base de données, je maîtrise
plutôt bien les mutex, et je n'ai pas une réputation de bricoleur dans
le codage :-)
Mais donc ça m'intéresserait assez de savoir si d'autres ont déjà
envisagé ce problème.
il n'est pas nécessaire d'utiliser un SGBDR pour gérer
les sessions. Cela peut-être avec des fichiers texte, ou avec des
démons comme memcached.
C'est donc peut-être vers ce genre de solutions que je veux aller.
* C'est la base de données qui rame et qui représente 60% du délai
d'affichage d'une page.
C'est mesuré ou prédit comme valeur ?
Si c'est mesuré, comment ?
C'est une estimation grossière, qui de plus a valeur de moyenne d'un moment
à une autre.
J'aimerais bien affiner, mais je n'ai pas la maîtrise du serveur
d'hébergement, et chez moi sur EasyPHP le chargement est bien sûr
instantané. Ce qui confirmerait d'ailleurs le diagnostic...
Je veux bien, mais donc mon propos est de dire que pour cette
application, le choix standard est finalement surdimensionné. Au fait
j'en profite pour préciser qu'il y a de bonnes raisons pour lesquelles
ce site a besoin de sessions, et ne doit pas reposer sur les cookies ni
Le code est donc complètement stateless, à part l'identifiant de
session renvoyé avec les requêtes HTTP.
Or celui-là pour l'utiliser, il faut accéder à la base, et donc faire
un mysql_connect(), lequel inclut donc un login avec les identifants
imposés par mon ISP.
A vrai dire j'ai pas mal progressé en PHP depuis 6 mois, mais je ne
vois pas comment contourner ce problème et retrouver mes ressources
systèmes d'une requête à l'autre.
Je suis en mesure d'écrire un système séquentiel indexé pour faire
ce que fait actuellement pour mon site la base de données, je maîtrise
plutôt bien les mutex, et je n'ai pas une réputation de bricoleur dans
le codage :-)
Mais donc ça m'intéresserait assez de savoir si d'autres ont déjà
envisagé ce problème.