J'ai un site en PHP et une certaine page nécessite pas mal de requêtes
SQL. Dès qu'on affiche la page, les requêtes sont donc lancées afin de
créer la page.
J'aimerais savoir s'il existait un mécanisme du genre: la page PHP est
générée toutes les X mins (ou un système de cache ?). Puis entre temps,
elle est static afin d'éviter des accès à MySQL dès que la page est
demandée.
Au pire, je passe par un script Perl + Cron mais côté maintenance, ca ne
va pas être la joix...
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la page HTML.
Le systeme de cache est une bonne solution aussi mais elle peut etre assez gourmande aussi en ressources systeme puisque pour savoir si la page doit etre modifiée ou non il va quand meme falloir faire une requete..
Pas besoin de champs version pour detecter un mouvement dans la base puisqu'on la manipule nous meme ou alors il nous manque des informations au sujet de la base..
Kawai ^_^
Les données changent quand ce ne sont plus les mêmes qu'avant ;-)
Tu as certainement moyen de détecter les delete, update, insert lancés par tes scripts et susceptibles d'entrainer une modification des donnees. Dans ce cas là, à chaque fois, tu regénères ta page statique. Pour être plus clair, à chaque fois qu'une requête de modification est lancé, tu inclus juste après un script chargé de la regénération de la page html
Comment ne peux tu pas savoir quand les données changent ? c'est
impossible de ne pas le savoir. Marc à raison, les données changent
quand elles sont modifiées, ajoutées et supprimées et c'est donc apres
chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la
page HTML.
Le systeme de cache est une bonne solution aussi mais elle peut etre
assez gourmande aussi en ressources systeme puisque pour savoir si la
page doit etre modifiée ou non il va quand meme falloir faire une requete..
Pas besoin de champs version pour detecter un mouvement dans la base
puisqu'on la manipule nous meme ou alors il nous manque des informations
au sujet de la base..
Kawai ^_^
Les données changent quand ce ne sont plus les mêmes qu'avant ;-)
Tu as certainement moyen de détecter les delete, update, insert lancés
par tes scripts et susceptibles d'entrainer une modification des
donnees. Dans ce cas là, à chaque fois, tu regénères ta page statique.
Pour être plus clair, à chaque fois qu'une requête de modification est
lancé, tu inclus juste après un script chargé de la regénération de la
page html
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la page HTML.
Le systeme de cache est une bonne solution aussi mais elle peut etre assez gourmande aussi en ressources systeme puisque pour savoir si la page doit etre modifiée ou non il va quand meme falloir faire une requete..
Pas besoin de champs version pour detecter un mouvement dans la base puisqu'on la manipule nous meme ou alors il nous manque des informations au sujet de la base..
Kawai ^_^
Les données changent quand ce ne sont plus les mêmes qu'avant ;-)
Tu as certainement moyen de détecter les delete, update, insert lancés par tes scripts et susceptibles d'entrainer une modification des donnees. Dans ce cas là, à chaque fois, tu regénères ta page statique. Pour être plus clair, à chaque fois qu'une requête de modification est lancé, tu inclus juste après un script chargé de la regénération de la page html
marc.quinton-PAS-DE-
Ralph Nader 2008 wrote:
Un truc simple pour ça, c'est d'ajouter une colonne version qui sera incrémentée à chaque modification d'une table et permet ainsi facilement de déterminer si les données ont bougé depuis la dernière génération de la page.
c'est un peu trop simpliste !
voici le contexte sous forme de specifications informatiques. cela ne veut pas dire que j'ai la solution.
le contenu d'une page dynamique c'est :
- le resultat de l'affichage de données au format HTML, - ces données étant puisées dans des tables résidant en BD. - ces données sont issues d'une ou plusieurs tables - et portent eventuellement sur des critères de sélection. - parfois les tables peuvent être croisées (jointure sql).
il y a donc une dépendence entre la validité du cache et les données présente en base.
a chaque fois que les données présentes en base correspondant aux critères de sélections sont modifiées, il convient de notifier le mécanisme de cache d'une demande de rafraichissement.
les dépendances visibiles :
- la page cachée dépend de la page modèle (template ou code php), - la page modèle dépend du contenu des tables via les critères de sélection.
les extraction de données - portent sur une ou plusieurs tables ; s'il y a modification sur cette table, cela peut déclancher l'évenement d'obsolescence - avec spécification éventuelle de critères de sélection sur ces colonnes des tables.
pour finir : * est-ce exhaustif ? * est-ce qu'il est possible de realiser une modélisation objet de tout ceci ?
si oui, il devient possible de realiser un cache dont la mise a jour est optimisée.
sauf erreur de ma part: - des développeurs de SPIP ont travaillé sur cette problématique. - certains moteurs de templates disposent deja de mécanismes de ce genre.
Ralph Nader 2008 wrote:
Un truc simple pour ça, c'est d'ajouter une colonne version qui sera
incrémentée à chaque modification d'une table et permet ainsi
facilement de déterminer si les données ont bougé depuis la dernière
génération de la page.
c'est un peu trop simpliste !
voici le contexte sous forme de specifications informatiques.
cela ne veut pas dire que j'ai la solution.
le contenu d'une page dynamique c'est :
- le resultat de l'affichage de données au format HTML,
- ces données étant puisées dans des tables résidant en BD.
- ces données sont issues d'une ou plusieurs tables
- et portent eventuellement sur des critères de sélection.
- parfois les tables peuvent être croisées (jointure sql).
il y a donc une dépendence entre la validité du cache et
les données présente en base.
a chaque fois que les données présentes en base correspondant
aux critères de sélections sont modifiées, il convient
de notifier le mécanisme de cache d'une demande de rafraichissement.
les dépendances visibiles :
- la page cachée dépend de la page modèle (template ou code php),
- la page modèle dépend du contenu des tables via les critères
de sélection.
les extraction de données
- portent sur une ou plusieurs tables ; s'il y a modification sur
cette table, cela peut déclancher l'évenement d'obsolescence
- avec spécification éventuelle de critères de sélection sur
ces colonnes des tables.
pour finir :
* est-ce exhaustif ?
* est-ce qu'il est possible de realiser une modélisation objet de
tout ceci ?
si oui, il devient possible de realiser un cache dont la mise a jour
est optimisée.
sauf erreur de ma part:
- des développeurs de SPIP ont travaillé sur cette problématique.
- certains moteurs de templates disposent deja de mécanismes de ce genre.
Un truc simple pour ça, c'est d'ajouter une colonne version qui sera incrémentée à chaque modification d'une table et permet ainsi facilement de déterminer si les données ont bougé depuis la dernière génération de la page.
c'est un peu trop simpliste !
voici le contexte sous forme de specifications informatiques. cela ne veut pas dire que j'ai la solution.
le contenu d'une page dynamique c'est :
- le resultat de l'affichage de données au format HTML, - ces données étant puisées dans des tables résidant en BD. - ces données sont issues d'une ou plusieurs tables - et portent eventuellement sur des critères de sélection. - parfois les tables peuvent être croisées (jointure sql).
il y a donc une dépendence entre la validité du cache et les données présente en base.
a chaque fois que les données présentes en base correspondant aux critères de sélections sont modifiées, il convient de notifier le mécanisme de cache d'une demande de rafraichissement.
les dépendances visibiles :
- la page cachée dépend de la page modèle (template ou code php), - la page modèle dépend du contenu des tables via les critères de sélection.
les extraction de données - portent sur une ou plusieurs tables ; s'il y a modification sur cette table, cela peut déclancher l'évenement d'obsolescence - avec spécification éventuelle de critères de sélection sur ces colonnes des tables.
pour finir : * est-ce exhaustif ? * est-ce qu'il est possible de realiser une modélisation objet de tout ceci ?
si oui, il devient possible de realiser un cache dont la mise a jour est optimisée.
sauf erreur de ma part: - des développeurs de SPIP ont travaillé sur cette problématique. - certains moteurs de templates disposent deja de mécanismes de ce genre.
marc.quinton-PAS-DE-
Kawai wrote:
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer ''LA'' page HTML.
tu dis la page. Je crois que le probleme est relativement complexe. une solution toute faite et 100% optimisée ne saute pas a mes yeux. mais peut-etre as-tu beaucoup plus de talent que moi.
Kawai wrote:
Comment ne peux tu pas savoir quand les données changent ? c'est
impossible de ne pas le savoir. Marc à raison, les données changent
quand elles sont modifiées, ajoutées et supprimées et c'est donc apres
chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer ''LA''
page HTML.
tu dis la page. Je crois que le probleme est relativement complexe.
une solution toute faite et 100% optimisée ne saute pas a mes yeux.
mais peut-etre as-tu beaucoup plus de talent que moi.
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer ''LA'' page HTML.
tu dis la page. Je crois que le probleme est relativement complexe. une solution toute faite et 100% optimisée ne saute pas a mes yeux. mais peut-etre as-tu beaucoup plus de talent que moi.
Kawai
oui je dis la page puisque Delf lui meme n'a parlé que d'une seule et unique page posant un problème :
J'ai un site en PHP et une certaine page nécessite pas mal de requêtes > SQL. Dès qu'on affiche la page, les requêtes sont donc
lancées afin de > créer la page.
Mais p-e la solution est elle beaucoup plus simple, pourquoi ne pas optimiser les requetes SQL ?
Je pense que nous manquons de détails sur l'existant pour trouver un solution miracle.
Kawai ^_^
Kawai wrote:
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer ''LA'' page HTML.
tu dis la page. Je crois que le probleme est relativement complexe. une solution toute faite et 100% optimisée ne saute pas a mes yeux. mais peut-etre as-tu beaucoup plus de talent que moi.
oui je dis la page puisque Delf lui meme n'a parlé que d'une seule et
unique page posant un problème :
J'ai un site en PHP et une certaine page nécessite pas mal de
requêtes > SQL. Dès qu'on affiche la page, les requêtes sont donc
lancées afin de > créer la page.
Mais p-e la solution est elle beaucoup plus simple, pourquoi ne pas
optimiser les requetes SQL ?
Je pense que nous manquons de détails sur l'existant pour trouver un
solution miracle.
Kawai ^_^
Kawai wrote:
Comment ne peux tu pas savoir quand les données changent ? c'est
impossible de ne pas le savoir. Marc à raison, les données changent
quand elles sont modifiées, ajoutées et supprimées et c'est donc apres
chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer
''LA'' page HTML.
tu dis la page. Je crois que le probleme est relativement complexe.
une solution toute faite et 100% optimisée ne saute pas a mes yeux.
mais peut-etre as-tu beaucoup plus de talent que moi.
oui je dis la page puisque Delf lui meme n'a parlé que d'une seule et unique page posant un problème :
J'ai un site en PHP et une certaine page nécessite pas mal de requêtes > SQL. Dès qu'on affiche la page, les requêtes sont donc
lancées afin de > créer la page.
Mais p-e la solution est elle beaucoup plus simple, pourquoi ne pas optimiser les requetes SQL ?
Je pense que nous manquons de détails sur l'existant pour trouver un solution miracle.
Kawai ^_^
Kawai wrote:
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer ''LA'' page HTML.
tu dis la page. Je crois que le probleme est relativement complexe. une solution toute faite et 100% optimisée ne saute pas a mes yeux. mais peut-etre as-tu beaucoup plus de talent que moi.
Delf
Kawai wrote:
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la page HTML.
Je me suis p'tre mal exprimé. Si je génère la page à chaque requete SQL qui modifie les données, je vais faire que ca...
Ce que je voulais faire à la base, c'est générer la page toutes les X mins. Si les données sont modifiées entre temps (entre X1 et X2), ca ne gène en rien que la page ne soit plus à jour.
Le systeme de cache est une bonne solution aussi mais elle peut etre assez gourmande aussi en ressources systeme puisque pour savoir si la page doit etre modifiée ou non il va quand meme falloir faire une requete..
Pour le cache, j'ai trouvé un module mod_proxy qui peut servir pour faire un cache apparemment. Je me suis pas encore penché dessus.
-- Delf
Kawai wrote:
Comment ne peux tu pas savoir quand les données changent ? c'est
impossible de ne pas le savoir. Marc à raison, les données changent
quand elles sont modifiées, ajoutées et supprimées et c'est donc apres
chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la
page HTML.
Je me suis p'tre mal exprimé. Si je génère la page à chaque requete SQL
qui modifie les données, je vais faire que ca...
Ce que je voulais faire à la base, c'est générer la page toutes les X
mins. Si les données sont modifiées entre temps (entre X1 et X2), ca ne
gène en rien que la page ne soit plus à jour.
Le systeme de cache est une bonne solution aussi mais elle peut etre
assez gourmande aussi en ressources systeme puisque pour savoir si la
page doit etre modifiée ou non il va quand meme falloir faire une requete..
Pour le cache, j'ai trouvé un module mod_proxy qui peut servir pour
faire un cache apparemment. Je me suis pas encore penché dessus.
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la page HTML.
Je me suis p'tre mal exprimé. Si je génère la page à chaque requete SQL qui modifie les données, je vais faire que ca...
Ce que je voulais faire à la base, c'est générer la page toutes les X mins. Si les données sont modifiées entre temps (entre X1 et X2), ca ne gène en rien que la page ne soit plus à jour.
Le systeme de cache est une bonne solution aussi mais elle peut etre assez gourmande aussi en ressources systeme puisque pour savoir si la page doit etre modifiée ou non il va quand meme falloir faire une requete..
Pour le cache, j'ai trouvé un module mod_proxy qui peut servir pour faire un cache apparemment. Je me suis pas encore penché dessus.
-- Delf
Delf
Kawai wrote:
oui je dis la page puisque Delf lui meme n'a parlé que d'une seule et unique page posant un problème :
Oui, enfin, y en a trois de memoire mais ca ne change en rien le problème.
-- Delf
Kawai wrote:
oui je dis la page puisque Delf lui meme n'a parlé que d'une seule et
unique page posant un problème :
Oui, enfin, y en a trois de memoire mais ca ne change en rien le problème.
oui je dis la page puisque Delf lui meme n'a parlé que d'une seule et unique page posant un problème :
Oui, enfin, y en a trois de memoire mais ca ne change en rien le problème.
-- Delf
Olivier Miakinen
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la page HTML.
Je me suis p'tre mal exprimé. Si je génère la page à chaque requete SQL qui modifie les données, je vais faire que ca...
Ce que je voulais faire à la base, c'est générer la page toutes les X mins. Si les données sont modifiées entre temps (entre X1 et X2), ca ne gène en rien que la page ne soit plus à jour.
Je n'ai pas suivi toute la discussion, aussi je vais peut-être répondre à côté de la plaque. Pardonne moi si c'est le cas.
D'après l'article de Kawai et ta réponse, je soupçonne que l'idée suivante pourrait fonctionner : à chaque requête SQL qui modifie les données, tu regardes la date de dernière modification de la page. Si cette date est vieille de plus de X minutes, tu regénères la page, sinon tu ne fais rien.
Ça ne répondrait pas à ce que tu veux faire ?
Comment ne peux tu pas savoir quand les données changent ? c'est
impossible de ne pas le savoir. Marc à raison, les données changent
quand elles sont modifiées, ajoutées et supprimées et c'est donc apres
chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la
page HTML.
Je me suis p'tre mal exprimé. Si je génère la page à chaque requete SQL
qui modifie les données, je vais faire que ca...
Ce que je voulais faire à la base, c'est générer la page toutes les X
mins. Si les données sont modifiées entre temps (entre X1 et X2), ca ne
gène en rien que la page ne soit plus à jour.
Je n'ai pas suivi toute la discussion, aussi je vais peut-être répondre
à côté de la plaque. Pardonne moi si c'est le cas.
D'après l'article de Kawai et ta réponse, je soupçonne que l'idée
suivante pourrait fonctionner : à chaque requête SQL qui modifie les
données, tu regardes la date de dernière modification de la page.
Si cette date est vieille de plus de X minutes, tu regénères la page,
sinon tu ne fais rien.
Comment ne peux tu pas savoir quand les données changent ? c'est impossible de ne pas le savoir. Marc à raison, les données changent quand elles sont modifiées, ajoutées et supprimées et c'est donc apres chaque requete INSERT, REPLACE, UPDATE ou DELETE qu'il faut générer la page HTML.
Je me suis p'tre mal exprimé. Si je génère la page à chaque requete SQL qui modifie les données, je vais faire que ca...
Ce que je voulais faire à la base, c'est générer la page toutes les X mins. Si les données sont modifiées entre temps (entre X1 et X2), ca ne gène en rien que la page ne soit plus à jour.
Je n'ai pas suivi toute la discussion, aussi je vais peut-être répondre à côté de la plaque. Pardonne moi si c'est le cas.
D'après l'article de Kawai et ta réponse, je soupçonne que l'idée suivante pourrait fonctionner : à chaque requête SQL qui modifie les données, tu regardes la date de dernière modification de la page. Si cette date est vieille de plus de X minutes, tu regénères la page, sinon tu ne fais rien.
Ça ne répondrait pas à ce que tu veux faire ?
Laurent Seguin
Delf , le 25 nov. 2004 23:03:48, écrivait ceci:
Pour le cache, j'ai trouvé un module mod_proxy qui peut servir pour faire un cache apparemment. Je me suis pas encore penché dessus.
Attention avec ça, c'est potentionellement dangereux si ce n'est pas parfaitement configuré (détournement de flux http, relais à spam, etc).
Delf <abuse@wanadoo.fr>, le 25 nov. 2004 23:03:48, écrivait ceci:
Pour le cache, j'ai trouvé un module mod_proxy qui peut servir pour
faire un cache apparemment. Je me suis pas encore penché dessus.
Attention avec ça, c'est potentionellement dangereux si ce n'est pas
parfaitement configuré (détournement de flux http, relais à spam, etc).
