Cyberbougnat Posté 7 Septembre 2003 Posté 7 Septembre 2003 Bonjour à tous, comme il y a du spipeur dans le coin, et que certains ont déjà été confronté au problème je vous expose mon problème ici sans avoir trouvé de réponse ailleurs. Mon site Cyberbougnat.net est maintenant sous spip, soit dans sa version actuelle : 800 articles, 30 rubriques, une centaine de brèves. mon problème est que le script me génère actuellement plus de 120 Mo de cache. une page dans le cache faisant en moyenne 20 ko je vous dit pas le nombre de fichiers générés, et c'est bien ça qui métonne. avez vous été confronté à un tel problème ? merci d'avance pour votre aide
Cariboo Posté 7 Septembre 2003 Posté 7 Septembre 2003 En tout état de cause, SPIP ne doit générer qu'une page en cache pour chaque article. Pour 800 articles, cela doit faire 800 x 20 = 16000 ko. Donc il y'a bien un problème. Deux explications possibles : 1°) lorsque spip cherche la page en cache existante, il ne la trouve pas, et la recrée systématiquement. Comme il change le nom et l'emplacement du fichier en cache à chaque fois, cela créée potentiellement une page de plus à chaque visite (ouïe) Il faudrait que tu vérifies si tu as plusieurs occurrences de la même page dans ton cache. Si c'est le cas, cherche de ce côté là 2°) tu as créé un script qui combiné avec spip est capable de générer beaucoup plus de pages différentes que tu ne crois. Dans ce cas, c'est normal, il faut que tu modifies le script en cause pour éviter la multiplication des petits pains... Cela n'arrive que si ton script entre en conflit avec le code SPIP : une page annuaire dans un script réalisé avec SPIP, même si elle change à chaque fois, ne produit qu'une seule page en cache...
Cyberbougnat Posté 7 Septembre 2003 Auteur Posté 7 Septembre 2003 j'avais déjà modifié la fonction qui génère le nom du cache car j'avais un soupçon sur l'id de session qui perturberait le choses. je pensais que cela avait amélioré les choses, mais hier, plus de place sur l'hébergement donc toujours un truc qui ne va pas. j'ai moins de doublons qu'avant, mais j'ai toujours des pages en 3-4 exemplaires, mais ce qui m'intrigue le plus ce sont certains fichiers qui s'appelle comme ça : -NAV-NAV-bandeau_accueil.e0c078, -goo-NAV-bandeau_accueil.031310, -saison-7-105.618d75, -saison-26-333.f7e9b7, ind-ann-ann-ind-sit-195.f6bae5... j'en ai téléchargé quelques un, et je constate que ce sont tous des caches de la page d'accueil. S'il y a conflit je ne sais trop comment le trouver. j'ai ouvert plusieurs des pages dans un éditeur, il y a 3 inclusions de script php via des include, et ils apparaissent dans les fichiers sous cette forme : <? include "cache/guide/accueil.cache"; ?> A moins bien sûr que ce soit encore un problème avec l'id de session... Ce qui me manque là c'est la manière de le découvrir sans perturber le fonctionnement du site pfff
Dan Posté 8 Septembre 2003 Posté 8 Septembre 2003 Salut Bertrand, As-tu lancé une analyse de ton site avec un outil comme Xenu Link Sleuth ? Cela te permettrait de voir quels sont les liens qui ont un identifiant de session sur l'ensemble du site et d'avoir au moins une piste pour démarrer. Je ne vois pas du tout à quoi peut te servir une session dans ta partie "Spip" Dan
Cyberbougnat Posté 8 Septembre 2003 Auteur Posté 8 Septembre 2003 Je ne vois pas du tout à quoi peut te servir une session dans ta partie "Spip" demande aux concepteurs !! c'est pas moi qui l'ai ajoutée. Lionel m'a donné une piste tout à l'heure qui serait un problème avec les includes en php qui seraient mal gérés par le cache. je vais essayer un truc en espérant que ça améliore les choses. en l'état des choses et après analyse de pas mal de fichiers c'est la pag d'acceuil qui est en cause principalement, car elle est en cache des dizaines (centaines) de fois. elle comporte 3 includes en php, donc voilà peut être la source du problème.
Dan Posté 9 Septembre 2003 Posté 9 Septembre 2003 demande aux concepteurs !! c'est pas moi qui l'ai ajoutée. Salut Bertrand, Pour avoir installé Spip de nombreuses fois, je suis certain qu'il n'y a pas de session pour le site public. L'interface d'admin gère bien un cookie mais même si tu écrits énormément, il ne va pas créer 120Mb de fichiers identiques en cache. Les forums publics sont-ils activés ? Par contre, tu ne nous dit pas qelle version de Spip ru as installée... Dan
Cyberbougnat Posté 9 Septembre 2003 Auteur Posté 9 Septembre 2003 j'ai installé la version 1.6 et les forums sont activés, mais assez peux actifs. si il n'y a pas de session dans la partie public ça voudrait alors dire que j'en récupère une d'une partie du site non géré par SPIP, mais d'où, voilà ma question ! Car le truc c'est que je n'utilise pas de session dans le site mis à part dans l'espace membre. Or sans aller dans l'espace membre j'ai des url (les brèves en particulier) qui prennent une session.
Cyberbougnat Posté 9 Septembre 2003 Auteur Posté 9 Septembre 2003 Car le truc c'est que je n'utilise pas de session dans le site mis à part dans l'espace membre. une idée m'est venue au même moment : ma session pourrait-elle venir de ma régie pub (phpAdsNew) ? C'est une supposition seulement, je chercherais la réponse ce soir.... si j'ai 5 minutes à m'accorder à moi même
Dan Posté 9 Septembre 2003 Posté 9 Septembre 2003 Car le truc c'est que je n'utilise pas de session dans le site mis à part dans l'espace membre. Quand tu parles de l'espace membre, tu veux dire la partie "rédacteurs" ou bien tu as implémenté un espace réservé aux membres inscrits ? Si c'est le cas, lorsqu'un membre revient dans l'espace public, tu a vraisemblablement toujours la session active. Le plus simple est de lancer Link Sleuth... tu verras tout de suite si tu as des identifiants de session dans les URLs Dan
Dan Posté 9 Septembre 2003 Posté 9 Septembre 2003 Salut Bertrand, Je viens de trouver un article sur les listes Spip qui référencie ton problème sous la version 1.6... http://listes.rezo.net/archives/spip-dev/2...7/msg00053.html Ils y mentionnent que la version CVS remédie aux problèmes dûs aux identifiants de session Dan
Dan Posté 9 Septembre 2003 Posté 9 Septembre 2003 Et tant qu'on y est, si tu installes une version CVS, modifie le fichier inc-cache.php3 en transformant les chmod 777 en chmod 755. OVH n'aime pas les chmod 777, ce qui peut générer une erreur 500 lors de la création du cache de la page. Je viens de trouver cela à l'instant Dan
Cariboo Posté 9 Septembre 2003 Posté 9 Septembre 2003 une idée m'est venue au même moment : ma session pourrait-elle venir de ma régie pub (phpAdsNew) ? C'est une supposition seulement, je chercherais la réponse ce soir.... si j'ai 5 minutes à m'accorder à moi même J'utilise aussi phpadsnew, et il faut faire très attention, car phpadsnew ne fait pas bon ménage avec SPIP. J'ai eu pas mal de problèmes avec au début pour faire fonctionner les deux en même temps. Je pense que tu as mis le doigt sur le truc...
Cyberbougnat Posté 9 Septembre 2003 Auteur Posté 9 Septembre 2003 J'utilise aussi phpadsnew, et il faut faire très attention, car phpadsnew ne fait pas bon ménage avec SPIP. J'ai eu pas mal de problèmes avec au début pour faire fonctionner les deux en même temps. Je pense que tu as mis le doigt sur le truc... si tu as des astuces je suis preneur. pour ma part je fais un appel par javascript, c'est ce qui me semblait le mieux pour faire cohabiter, mais c'est peut être une erreur.
Cariboo Posté 9 Septembre 2003 Posté 9 Septembre 2003 Non, pas d'astuce géniale, on utilise la syntaxe d'appel par lien externe, comme s'il s'agissait de bannières sur une régie indépendante. Cela fonctionne très bien ainsi. Sinon, il faut changer la syntaxe de tous les appels à la base, pour éviter les téléscopages entre mysql_db_connect et mysql_connect, ou des problèmes avec les handles de connexion... Cette autre solution fonctionne, mais on ne l'a pas choisie, car elle empêche de faire fonctionner l'appli "as it is".
Cyberbougnat Posté 9 Septembre 2003 Auteur Posté 9 Septembre 2003 Non, pas d'astuce géniale, on utilise la syntaxe d'appel par lien externe, comme s'il s'agissait de bannières sur une régie indépendante. Cela fonctionne très bien ainsi. Sinon, il faut changer la syntaxe de tous les appels à la base, pour éviter les téléscopages entre mysql_db_connect et mysql_connect, ou des problèmes avec les handles de connexion... Cette autre solution fonctionne, mais on ne l'a pas choisie, car elle empêche de faire fonctionner l'appli "as it is". oui je ne veux surtout pas toucher à l'appli. moins j'y touche et mieux je me porte... je vais juste vérifier que j'utilise bien un appel externe partout car après coup je n'en suis plus sûr à 100%
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant