rien à voir avec spip.

sans javascript activé, ton site ne s’affiche pas.

regarde plutôt du côté des scripts js...

Merci de ta réponse. Quid de l’interface privée ? (qui ne comporte à mon avis aucun javascript) Il me faut actuellement près de 30 secondes pour valider un articles, ou 20 pour lui attacher un mot clef par exemple

On hébergeur ne m’ayant toujours pas donné de réponse, je m’en remets à la communautée SPIP. QQun a t’il déjà rencontré ce genre de pb ?

quand tu es loggué en admin, sur tes pages publiques, ajoute à l’url &var_profile.

ça te retourne toutes les requêtes sql lancées par ta page avec le timer de chacune.

dans phpmyadmin, exécute quelques-unes des requêtes recopiées depuis ta page et regarde si elles sont plus rapides ou moins.

ce qui est lent dans l’espace privé, c’est le traitement du formulaire ou le réaffichage de l’article une fois créé/modifié ?

si réponse 2 (affichage) qu’y a t-il dans le corps de ton article ? images...

ta base est elle lourde ?

ne faut-il pas passer un petit coup de OPTIMIZE TABLE `spip_truc` à tes tables ?

Je vais tester tout ça dès ce soir, je te remercie.

Sinon concernant la taille de base, on doit approcher les 60Mo pour Spip. Suportable (j’espère!)

Yep,

J’ai essayé d’optimiser la table, et de scruter les commandes SQL, mais rien ne me saute aux yeux.

Aurais tu le temps de jetter un oeil aux executions SQL sur le site ?

Je sèche vraiment là ...

Je te remercie encore une fois

Concernant les lenteurs dans l’espace privée, tout y passe. Création de brèves, d’articles, liaison de mot clef etc etc. N’importe quel clic demande un temps de chargement supérieur à 10 secondes.

on aurait du commencer par là : tu dis "depuis quelques semaines". quelles modifications aurais-tu apportées (configuration, nouveau squelette...) juste avant que "ça rame" ?

sinon, pour tes squelettes... rapidement, je n’ai rien vu de vraiment terrifiant : ton menu qui pourrait être appelé sans php (et donc mis en cache), un if(document.location.hostname.indexOf(... que perso je n’aurais pas fait, de petits trucs ci et là...

mais tout ça n’influe pas sur la (non) rapidité de réaction dans l’espace privé.

sur ce point précis (hors bidouilles perso machiavéliques du code de ecrire/action/ ou ecrire/exec/) je penche vraiment pour un problème base de données. et là...

Il y a quelques semaines j’ai bien ajouté deux trois petits outils via des plugins, mais je n’ai rien ressenti sur le coup (de toute façon, par acquis de conciense, je les ai retirirés pour me tests).

J’ai fais une maj vers 1.9.2c (manuelle, envoi par ftp) aussi, j’avais une version légèrement inférieure. Là aussi sur le coup, ce n’était pas flagrant.

J’ai fais un optimize de la base hier soir, sans succès.

 :( comme on dit

Merci de ton aide en tout cas

j’ai un probleme du meme genre, mais en pire :)

dans l’admin, ca part en vrille "un peu au hasard", et spip 1.9.2c demande 1 go de ram d’un coup !

base de 500 mo, 45 000 articles 150 000 commentaires (20 000 ip/jour mais ca fonctionne parfaitemement dans le site public, donc rien à voir avec le nombre de visites)

on sèche :)

je n’ai "que" 1500 articles. Pas grand chose quoi...

C’est quand même très très très rageant. Si qqun à des pistes...

 commenter la fonction spip_log() dans ecrire/inc/utils.php :

ça supprimera les accès disque (toujours facteur de ralentissement) innombrables des logs. et puis les logs s’auto-écrasent toutes les 5 minutes sur un site moyennement consulté...
de toute façon, ça laisse la possibilité de les réactiver au cas où.

 dans mes_options.php, ajouter :

ça évite que tous les fichiers caches soient invalidés à chaque modification.

Encore une fois, merci pour tes pistes, je vais tester rapidement. Deux questions me taraudent l’esprit :

Spip peut il vraiment partir "en saucisse" du jour au lendemanin ? Est ce un problème connu ?

Ce qui métonne c’est que j’heberge mon site chez un professionnel (Sivit), relativement sérieux jusqu’à maintenant, mais qui ne trouve aucune piste à mon soucis.

 du jour au lendemain : oui. mais la question c’est plutôt quelle est la variable qui en changeant le fait partir en saucisse. et là...

il n’y a pas 2 spip installés à l’identique : configuration du serveur, version de php, de mysql, configuration de spip lui-même (langue, choix des éléments affichés, gestion du moteur de recherche, dictionnaire...), configuration des squelettes (nombre de boucle, complexité...), utilisation et configuration des plugins... et ajouté à tout ça, fréquentation du site, volume des données...

bref : va-t-en retrouver une cohérence là-dedans. c’est du débroussaillage permanent.

 problème connu : oui. régulièrement, la lenteur de spip ressort des discussions, comme sa propension à gonfler du cache...

mais, là encore, pour certains et pas toujours...

il faudrait inventer l’outil d’analyse qui permettrait de faire ressortir toutes les interactions des différents modèles, mais c’est une autre paire de manches.

déjà, utilisons les outils disponibles :

 &var_profile dans l’url (quand on est loggué admin) remonte les requêtes mysql ;
 &var_mode=debug dans l’url (quand on est loggué admin) affiche le décodage des boucles et des squelettes ;
 exec=info (quand on est loggué ) affiche le php-info
 plus la lecture des log (spip.log et mysql.log) dans tmp/

J’ai $derniere_modif_invalide dans inc_version.php (et pas mes options) . Cela change quelque chose ?

Faut il que je crée du coup un fichier mes_options.php3 dans le dossier ecrire ?

ben il est déclaré à true dans inc_version.php, et tu le surcharges à false dans mes_options.php.

ça t’évite de toucher à la valeur par défaut du fichier de la dist.

chaque fois que possible, toujours surcharger une fonction, une variable par défaut, plutôt que d’y intervenir directement dessus. comme précisé dans inc_version.php :

le fichier de personnalisation dont il est question, c’est mes_options.php.

Oki, j’avais saisi la subtilité, merci.

J’ai donc crée un fichier mes_options.php que j’ai placé dans /ecrire/ et contenant :

< ?php $auto_compress = false ; $derniere_modif_invalide = false ;  ? >

J’ai également commencé la fonction en question dans le fichier utils.php.

A première vue, cela n’a rien changé.

Il me reste à utilser tes outils en fin d’adresse. J’ai fais quelques tests, mais j’ai pas assez de reculs pour comprendre si les résultats sont logiques ou si un grain de sable est venu se glisser dans les rouages de spip.

(édit) Je n’avais *pas* saisi la subtilité

Hello

Toujours pas de progression dans mon soucis. J’ai envie de supprimer entièrement mon dossier SPIP et de le réupper de 0 en garder une sauvegarde la base.

 > Suppression du dossier
 > Back up de la base
 > Suppression de la base
 > UP d’un spip tout neuf
 > UP de mon squelette
 > UP de mon backup.

Ca sert à quelque-chose de se coltiner toutes ces étapes ?

Merci à vous !

Humm ! Le problème ne vient peut être pas de spip, mais peut-être de l’environnement d’hébergement de ton spip : ordinateur, serveur apache, serveur mysql, etc. As tu suffisamment d’espace disque dur disponible ? As tu beaucoup de fichiers qui saturent inutilement ton disque dur (fichiers temporaires notamment : sur certains pc, la taille totale des fichies temporaires atteint plusieurs Go!) ? Ton pc/serveur est peut être fortement virusé (il y’a des virus qui multiplient les fichiers sur les ordi) ? Etc.

Bonjour,

Ayant le même problème as-tu trouvé une solution ?

Une vrai catastrophe, je suis chez un et un et c’est de pire en pire, espace public ou privé... une idée ?

http://www.superpratix.com