Merci à tous pour vos réponses.
Je vais clarifier certaines choses.
Tout d'abord, le traffic du site n'est pas énorme, entre 500 et 1000 visites par
jour. Le vitesse de chargement des pages est très bonne, aucun ralentissement.
D'où notre étonnement...
Voici un extrait des logs d'après le mail reçu de 1and1 :
34616 Queries: 34148 Selects, 257 Ins, 21 Upd, 190 Del, 127 Connects
SELECT url_propre, statut, titre, DATE_FORMAT(date,'%Y%m%d') as date_objet
SELECT rubriques.id_rubrique, rubriques.titre, rubriques.lang
Déjà, nous n'arrivons pas à savoir quelle est la fréquence de ces 34148 Selects
(quotidienne ou autre ???)
Le code "SELECT url_propre, statut, titre, DATE_FORMAT(date,'%Y%m%d') as
date_objet" n'existe que dans inc-urls-propre.php3 à la racine, mais comme je
disais la surcharge est tj présente d'après 1and1 même quand ce fichier n'existe
plus sur le serveur (allez comprendre...) !!!
Par contre, je ne trouve nul part le code "SELECT rubriques.id_rubrique,
rubriques.titre, rubriques.lang" sur le site...
Enfin je précise que suite au 1er mail-avertissement de 1and1, nous avons tout
réinstallé : base neuve, site neuf.
Il s'agit donc d'une install parfaitement clean et la plus récente de Spip.
Hélas le problème perdure d'après 1and1...
Réponses :
"D'après ce que je vois, tu fais un traitement côté MySQL de transformation
d'une date. Essaye de le reporter dans php."
-> Effectivement, le code de la 1ere requête correspond à une modif dans
l'URL-rewriting faite au niveau du fichier inc-urls-propre.php3.
Que veux-tu dire par "Essaye de le reporter dans php" ?
"D'après mon expérience (qui m'a fait quitter 1and1 en courant), 1and1 a
dimensionné son offre de manière abérante :
- trop d'espace disque
- trop de bande passante
- pas du tout assez de mysql
En pratique, une site SPIP de plus de 600 visiteurs par jour se fait éjecté de
1and1."
-> Tout à fait d'accord, sans compter un support nul à chier.
Si notre site est trop gros pour du mutualisé 1and1, qu'ils nous le disent
clairement... soit on prendra un serveur privé virtuel (pour le même prix...),
soit on ira voir ailleurs.
"nombre trop élevé ou surcharge du serveur à cause de quelques requetes trop
longues ?
-> nombre trop élevé, comme indiqué plus haut.
"Tes rédacteurs utilises-ils depuis l'espace privé les pages brouteur ou
article_tous ?"
(...)
-> Le problème est ailleurs.
"maintenant, si c'est trop de requêtes, tu peux essayer d'augmenter un peu les
caches, mais si tu as des forums actifs, ca ne servira pas à
grand chose. Il faut mettre une valeur de cache en haut avant le <head> et
eviter les caches 0!"
-> Bonne idée, d'autant plus que nous n'avons pas de forums actifs.
Il faut mettre des valeurs de caches dans chaque squelette désormais... ? Et
comment on fait çà sVP ?
"tu as des plugins actifs ?"
-> Non, aucun.
"As tu des requetes en php bien entendu dans certaines pages? Ou des InClude
et/ou Inclure?
-> Non, pas de requêtes en Php. Oui, il y a des Include mais sans Select aussi,
pourquoi ?
"Mais l'hebergeur broutille un peu tout de même! Qu'est-ce que cela peut bien
faire, sinon te faire tomber ta bande passante?
A moins que ton site soit un grand centre de telechargements ?"
-> Selon 1and1, d'autres utilisateurs se plaindraient de lenteurs et notre base
se trouverait parmi les bases responsables de ces lenteurs !
Nous, en tout cas, on ne constate aucune lenteur...
