Hébergeur de mauvaise foi?

WRInaute discret
Bonjour

Je possède un hébergement qui date de 6 ans. Entre temps, l'hébergeur a proposé de nouvelles formules et incite fortement à migrer vers ces nouvelles solutions.

Jusque là , j'ai fait le choix de rester sur l'ancienne formule.

Or depuis deux jours, mes pages affichent régulièrement un message d'erreur, sans que j'y aie effectué de modification particulière, et rendent les pages quasi inutilisables.

Ce message d'erreur est le suivant:

User 'XXXXX' has exceeded the 'max_questions' resource (current value: 80000)

J'ai interrogé l'hébergeur, qui me répond que le site a envoyé trop de requêtes SQL dans une fenêtre de temps de 60mn, et que si je migrais vers ses nouvelles solutions, je n'aurais pas ce problème.

Mes pages étant peu actives, et n'ayant enregistré aucun surcroit d'activité récemment, j'interroge à nouveau l'hébergeur pour savoir quelles tables ont été autant sollicitées.

L'hébergeur me répond qu'il ne peut rien voir à son niveau. Et c'est cela qui m'étonne beaucoup. Ils doivent bien avoir des fichiers logs qui puissent donner des indications.
Qu'en pensez vous?

Je me demande s'il ne laisse pas volontairement pourrir la situation sur ces anciennes formules pour forcer les derniers clients à migrer.

Merci d'avance pour vos avis
 
WRInaute discret
phrq a dit:
L'hébergeur me répond qu'il ne peut rien voir à son niveau. Et c'est cela qui m'étonne beaucoup. Ils doivent bien avoir des fichiers logs qui puissent donner des indications.
Qu'en pensez vous?

C'est surement vrai la personne à qui tu as parlé, n'a pas les outils ou les compétences pour aller visualiser les logs, c'est un commercial.

Quelle est la différence de prix entre les deux formules ?
 
WRInaute impliqué
Salut,

Euh tu nous dis que tes pages sont peu actives, ça représente quand même 22 requêtes par seconde. C'est bizarre cette histoire.
 
WRInaute discret
Ben oui, c'est bien mon avis. C'est bien pour çà que je voudrais bien savoir quelles tables sont ainsi sollicitées, car je soupçonne une attaque.
Mais quand l'hébergeur me dit qu'il ne peut rien voir de son côté, est-ce possible? :roll:
 
WRInaute accro
normal qu'ils incitent à passer sur des versions plus récentes de apache / php, car les anciennes versions sont sujettes a bien plus de failles et donc d'attaque. tu dois maintenir ton code avec les derniers versions.
 
WRInaute discret
Ca oui, je ne dis pas le contraire, et c'est de bonne guerre.
Mais de là à faire ce genre de réponse...
 
WRInaute passionné
Bah le message d'erreur est une configuration "normale" de MySQL en mutu.
En clair on te dit "tu as le droit de faire xx requêtes par heure" (d'où le message d'erreur).
Après
- Est-ce que tu l'as vraiment dépassé ?
C'est une possibilité. Ca peut aussi être dû à une attaque en effet, quelqu'un (un concurrent, ou juste un scan) pourrait avoir volontairement affiché ta page ayant le plus de requête SQL pour faire crasher ton hébergement.
Ca peut aussi venir d'un gros crawl de google qui aurait affiché toutes les pages de ton site (j'ai un regain du nombre de pages crawlé par jour dans GWT ces derniers jours).

Je ne pense pas que ça soit de mauvaise foi, peut-être qu'après avant ils ne t'avaient pas fixé de limites et que là ils t'ont fixé une limite à toi mais ainsi qu'à tout le monde car il y avait trop d'abus.
 
WRInaute discret
En tous cas, je n'ai pas enregistré d'augmentation significative du nombre de visites dans mes stats.
 
WRInaute accro
Tu as quoi comme outil de suivi de stats ? Analytics ? Awstats ? Parce que si le pic d'activité est dû à des robots, Analytics ne te le dira pas...
 
WRInaute discret
Effectivement, j'utilise Analytics.

Ceci dit, est-il possible que le crawl de pages devienne un tel bombardement? Etrange...
 
WRInaute occasionnel
e-kiwi a dit:
normal qu'ils incitent à passer sur des versions plus récentes de apache / php, car les anciennes versions sont sujettes a bien plus de failles et donc d'attaque. tu dois maintenir ton code avec les derniers versions.
+1

Julia41 a dit:
...Je ne pense pas que ça soit de mauvaise foi, peut-être qu'après avant ils ne t'avaient pas fixé de limites et que là ils t'ont fixé une limite à toi mais ainsi qu'à tout le monde car il y avait trop d'abus.
+1
 
WRInaute accro
e-kiwi a dit:
normal qu'ils incitent à passer sur des versions plus récentes de apache / php, car les anciennes versions sont sujettes a bien plus de failles et donc d'attaque. tu dois maintenir ton code avec les derniers versions.
Je suis du même avis, mais de là à faire passer à une nouvelle formule, avec tarifs différents, ça me parait gros.
Ton site vient d'un script tout prêt ou c'est du fait maison ? Tu as peut être une requête excessive ?
 
WRInaute discret
Bonjour

Je crois avoir trouvé la clé du mystère:

Le site lui même, ainsi que sa base de données, c'est du code maison. Et ce n'est pas lui qui est en cause.

A côté de cela, sur le même hébergement, se trouvait un ancien site que je n'utilisais plus, réalisé avec le CMS Mambo (L'ancêtre de Joomla), et sa base de données afférente. Je sais, çà ne nous rajeunit pas.
Et aussi un site fait avec Joomla, peu visité, également avec sa base de données. Ce sont eux qui ont été attaqués. Et donc les bases de données. Et comme les bases de données étaient toutes stockées au même endroit, toutes ont été paralysées.

J'ai donc fait une sauvegarde de ces deux bases de données, et les ai virées de mon hébergement. Depuis, plus de problème.

L'inconvénient de ce type de CMS, et, plus généralement des scripts tous faits, est, je crois, de proposer des scripts et bases de données standardisées, et donc facilement détectables et attaquables. C'est ce qui m'est arrivé. Il est vrai que je n'avais fait aucune mise à jour depuis des lustres. Heureusement que ces deux sites avaient peu d'importance.

Je retiens deux choses:
1) Vive le code maison, s'il est bien écrit :)
2) Mon hébergeur, s'il avait voulu d'en donner la peine, aurait pu consulter ses logs et éviter de me faire perdre tout ce temps. :(

Merci à vous tous pour vos réponses et suggestions. 8)

Bonne journée

Philippe
 
WRInaute passionné
Je retiens deux choses:
1) Vive le code maison, s'il est bien écrit
2) Mon hébergeur, s'il avait voulu d'en donner la peine, aurait pu consulter ses logs et éviter de me faire perdre tout ce temps.
Pour le 1: on est d'accord, mais ça prends du temps ;)
Pour le 2: je ne suis pas d'accord: ton hébergeur NE PEUT PAS SAVOIR que tu n'utilises plus ton site.
A noter aussi que normalement tu as toi aussi accès aux logs et que tu aurais pu le voir toi même.
J'ignore combien tu payes ton hébergement, mais ton hébergeur aurait dû demander à l'un de ses techniciens d'aller voir dans les logs, fouiner, chercher à comprendre le fonctionnement de ton site, cela aurait prit entre 30 et 60 minutes je pense (car lui ne connait rien de ton site), même au SMIC (le technicien), ça lui aurait couté plus cher de résoudre un problème pour lequel il n'est aucunement responsable.
Si jamais tu n'as pas accès au log, il aurait pu/dû te les mettre à disposition.

Désolé pour ce petit coup de gueule, mais c'est trop facile de toujours dire que c'est la faute de l'hébergeur qui t'offres, dans ton cas, un truc qui fonctionne parfaitement.
 
WRInaute discret
OK sur le principe: on ne peut tout demander à l'hébergeur, ni lui coller sur le dos des responsabilités qui ne sont pas les siennes. Mais ce que j'attendais de lui était juste de me dire s'ils avaient enregistré un surcroit d'activité sur une BD, si oui, laquelle. A partir de là, je me serais débrouillé.
 
WRInaute passionné
phrq a dit:
OK sur le principe: on ne peut tout demander à l'hébergeur, ni lui coller sur le dos des responsabilités qui ne sont pas les siennes. Mais ce que j'attendais de lui était juste de me dire s'ils avaient enregistré un surcroit d'activité sur une BD, si oui, laquelle. A partir de là, je me serais débrouillé.

Oui mais MySQL l'a fait pour lui et n'était pas du tout en erreur :
Code:
User 'XXXXX' has exceeded the 'max_questions' resource (current value: 80000)

Lui sait (ou non mais MySQL l'affiche à sa place) que tu as fait beaucoup de requêtes SQL, tu as peut-être fait un buzz sur Internet, un passage télé, ou simplement installé un CMS énorme, fais des tests etc...

Après, à noter qu'il n'a pas forcément activé les stats *par base* de MySQL (ça bouffe énormément de performance et le rapport intérêt/cout est plutôt mauvais) et du coup ne peut pas te donner cette information.
 
Discussions similaires
Haut