Hébergeur de mauvaise foi?

[phrq]

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

[eddie62]

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 ?

[MarvinLeRouge]

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.

[phrq]

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?

[e-kiwi]

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.

[phrq]

Ca oui, je ne dis pas le contraire, et c'est de bonne guerre.
Mais de là à faire ce genre de réponse...

[e-kiwi]

ils n'ont peut-être pas de poste chez eux pour faire ce genre de recherches sur les logs clients

[Julia41]

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.

[phrq]

En tous cas, je n'ai pas enregistré d'augmentation significative du nombre de visites dans mes stats.

[UsagiYojimbo]

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...

[phrq]

Effectivement, j'utilise Analytics.

Ceci dit, est-il possible que le crawl de pages devienne un tel bombardement? Etrange...

[techron]

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

...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

[padadam22]

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 ?

[phrq]

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.

Bonne journée

Philippe

[Julia41]

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.