Bonjour,
Les équipes techniques de 1and1.fr qui ont déjà coupé l'accès à une base SPIP hébergée chez eux m'indiquent :
"Après recherches de nos équipes techniques, nous pouvons vous indiquer que vous êtes le plus grand créateur de slow_queries sur le serveur hébergeant votre base de données."
Est-ce que ça inspire quelqu'un ?
Est-ce que c'est paramétrable dans SPIP ?
Pourquoi est-ce considéré par 1and1 comme un abus de consommation de ressources MySQL ?
Jacques PYRAT a écrit :
Est-ce que ça inspire quelqu'un ?
Est-ce que c'est paramétrable dans SPIP ?
non, c'est que de l'optimisation SQL (afaik)
Pourquoi est-ce considéré par 1and1 comme un abus de consommation de ressources MySQL ?
Car la requête met trop de temps à s'éxecuter et donc consommerait trop de ressources je pense... (une requête longue serait une requête complexe/mal fagotée/...)
Donnent-ils la configuration adoptée pour les slow_queries ? Ce serait bien pour pouvoir reproduire leur configuration (toute chose égale par ailleurs)
Mes 2 cents (et encore c'est cher payer),
Nicolas
Bonjour,
Les équipes techniques de 1and1.fr qui ont déjà coupé l'accès à une base
SPIP hébergée chez eux m'indiquent :
"Après recherches de nos équipes techniques, nous pouvons vous indiquer
que vous êtes le plus grand créateur de slow_queries sur le serveur
hébergeant votre base de données."Est-ce que ça inspire quelqu'un ?
Demande-leur quelles sont ces slow_queries (requêtes lentes).
Est-ce que c'est paramétrable dans SPIP ?
Non pas directement.
Un paramètre qui joue, c'est la complexité de tes modèles. Mais sans
connaître les requêtes en question, impossible de te guider plus.
Pourquoi est-ce considéré par 1and1 comme un abus de consommation de
ressources MySQL ?
Parce que le temps CPU consacré à ton site est pris aux dépens des
autres sites mutualisés.
Olivier.
Olivier Mengué a écrit :
Bonjour,
Les équipes techniques de 1and1.fr qui ont déjà coupé l'accès à une base
SPIP hébergée chez eux m'indiquent :
"Après recherches de nos équipes techniques, nous pouvons vous indiquer
que vous êtes le plus grand créateur de slow_queries sur le serveur
hébergeant votre base de données."
Ah ? Et moi je constate que mon site de test sur un hébergement gratuit (pris juste avant le 31 décembre !), avec une svn (10 jours) et des plugins rame comme c'est pas possible. D'ailleurs le plugin phpmyvisites était complètement out samedi soir (enfin ce week-end... depuis ça marche)
Le site d'un club d'échecs de la région Toulousaine, en sarkaspip, assez léger et sur un hébergement payant fonctionne du feu de dieu !
Est-ce que ça inspire quelqu'un ?
Demande-leur quelles sont ces slow_queries (requêtes lentes).
Oui j'aimerais bien savoir... Gratuit=slow, payant=fast ???
Bonne soirée,
Jacques
* jack tapotait, le 16/10/2006 20:49:
Oui j'aimerais bien savoir... Gratuit=slow, payant=fast ???
Même pas malheureusement.
Le site qui rame a justement pris l'hébergement à 10€HT/mois 
* Olivier Mengué tapotait, le 16/10/2006 19:02:
Bonjour,
Les équipes techniques de 1and1.fr qui ont déjà coupé l'accès à une base
SPIP hébergée chez eux m'indiquent :
"Après recherches de nos équipes techniques, nous pouvons vous indiquer
que vous êtes le plus grand créateur de slow_queries sur le serveur
hébergeant votre base de données."Est-ce que ça inspire quelqu'un ?
Demande-leur quelles sont ces slow_queries (requêtes lentes).
Il m'ont donné ceci :
db 713 5913[32](8.29) 1611[19](2.26) 323936[280187](454.33)
362654[280187](508.63)
db 157 SET timestamp=%%; SELECT articles.id_rubrique, articles.lang FROM `db151837338`.spip_articles AS `articles` WHERE (articles.id_rubrique = %%) AND (articles.statut = %%) AND (articles.date <
NOW()) LIMIT %%;
db 66 SET timestamp=%%; SELECT articles.id_article, articles.id_rubrique, articles.lang FROM `db151837338`.spip_articles AS `articles` WHERE (articles.id_rubrique = %%) AND (articles.statut = %%) AND (articles.date < NOW()) LIMIT %%;
db 65 SELECT rubriques.id_rubrique, rubriques.descriptif, rubriques.titre, %%+rubriques.titre AS num, rubriques.lang FROM `db151837338`.spip_rubriques AS `rubriques` WHERE (rubriques.id_parent =
%%) AND ((rubriques.id_rubrique NOT IN %%)) AND (rubriques.statut = %%) ORDER BY num;
db 59 SELECT url_propre, statut, titre FROM `db151837338`.spip_articles WHERE id_article=%%;
db 59 SELECT id_parent FROM `db151837338`.spip_rubriques WHERE id_rubrique=%%;
db 38 SELECT url_propre, statut, titre FROM `db151837338`.spip_rubriques WHERE id_rubrique=%%;
db 34 DELETE FROM `db151837338`.spip_caches WHERE fichier=%% OR fichier=%%;
db 32 INSERT IGNORE INTO `db151837338`.spip_caches
(fichier,id,type,taille) VALUES %%;
db 17 SET timestamp=%%; SELECT %%+articles.titre AS num, articles.id_article, articles.descriptif, articles.titre, a rticles.lang FROM `db151837338`.spip_mots_articles AS `L1`, `db151837338`.spip_mots AS `L2`, `db151837338`.spip_articles AS `articles` WHERE (L2.titre = %%) AND (articles.statut = %%) AND (articles.date < NOW()) AND L1.id_mot=%% AND articles.id_a rticle=%% GROUP BY articles.id_article ORDER BY num;
db 9 SELECT * FROM `db151837338`.spip_documents WHERE id_document=%%;
db 9 SELECT fichier FROM `db151837338`.spip_documents WHERE id_document = %%;
db 7 SELECT evenements.id_evenement FROM `db151837338`.spip_evenements AS `evenements` WHERE (evenements.id_article = %%) AND (evenements.date_debut >= %%) ORDER BY evenements.date_debut;
db 4 SELECT id_rubrique FROM `db151837338`.spip_rubriques AS rubriques WHERE ((id_parent IN %%));
db 4 SET timestamp=%%; SELECT articles.id_article, %%+articles.titre AS num, articles.descriptif, articles.titre, ar ticles.lang FROM `db151837338`.spip_mots_articles AS `L1`, `db151837338`.spip_mots AS `L2`, `db151837338`.spip_articles AS `articles` WHERE (L2.titre REGEXP %%) AND (articles.statut = %%) AND (articles.date < NOW()) AND L1.id_mot=%% AND articles.
id_article=%% GROUP BY articles.id_article ORDER BY num;
db 4 SET timestamp=%%; SELECT articles.id_rubrique, articles.id_article, articles.lang FROM `db151837338`.spip_art icles AS `articles` WHERE (articles.id_article = %%) AND (articles.statut = %%) AND (articles.date < NOW());
db 4 SELECT %% FROM `db151837338`.spip_signatures AS `signatures` WHERE (signatures.id_article = %%) AND (signatures.statut = %%);
Les %% ne pouvant pas être de vraies requêtes, ils ont donc sans doute remplacé les vraies valeurs par des %%.
Curieux ça ne me parait pas être des requetes très lourdes pourtant.
Pour les optimiser, il faudrait savoir comment MySQL calcule ses
résultats avc un EXPLAIN + requete. Il faut détecter quelles requetes
parcourent la totalité d'une ou plusieurs tables et donc prennent de
la ressource.. Peut-être que 1and1 utilise aussi une version buggué de
MySQL 
Sinon, est-ce que le fait d'utiliser des clés étrangères
n'améliorerait pas les perfs ? C'est possible avec les tables de type
innoDB.. A mon avis ça ne peut qu'améliorer la gestion des index et
les jointures sur les tables..
mon centime de franc
(et encore, bien ancien 
.Gilles