Saturation du serveur suite à un défaut du module calendrier

jeudi 30 décembre 2010 à 12h04
par Jacques83300

Logo de Jacques83300

Bonjour,

Mon hébergeur, Infomaniak, vient de me signaler que mon site, www.varapiloisir.com, plantait le serveur d’hébergement et qu’il avait donc dû l’installer temporairement sur un serveur privé.
Voici les informations données par mon hébergeur :

Le problème est permanent et semble lié à un défaut de la partie "Calendrier" de SPIP que vous utilisez. Les moteurs de recherche viennent indexer les pages de votre site et font des requêtes avec des années très anciennes (1850 par exemple) et cela "plante" le module calendrier, et donc sature le serveur.

Nous avons déjà eu un autre client avec un problème similaire. Il ne l’a pas corrigé en contactant SPIP pour obtenir un correctif ou faire une mise à jour mais à retiré le module calendrier, pour votre information.

Merci de nous tenir au courant dès que vous aurez trouvé une solution qui permette de mutualiser à nouveau votre site.

Quelqu’un a-t-il déjà rencontré et résolu ce problème ?

La solution de désactiver le calendrier ne me convient pas car un des buts de ce site est de communiquer de dates de réunions ou de conférences.

J’ai entamé une discussion sur le forum Spip http://forum.spip.org/fr_231209.html. Suite aux conseils donnés j’ai installé l’écran de sécurité de Spip ainsi qu’un filtre pour les robots.

Malheureusement cette solution ne satisfait pas mon hébergeur :
La question n’est pas de savoir si les robots peuvent ou non accéder à la page, il faut que le problème généré par cette page soit corrigé, une fois pour toute, sans quoi le retour en situation mutualisée ne sera pas possible et nous devrons, en fin de compte, vous demander de trouver un autre hébergeur ; ce serait vraiment dommage.

Voici un exemple d’URL posant problème : http://www.varapiloisir.com/v2.0/Bu...
L’utilisation de ce lien provoque l’apparition du message diquée et, après 10-15 secondes, j’obtiens l’affichage de la page avec le message suivant à la place du calendrier "Fatal error : Maximum execution time of 10 seconds exceeded in /home/www/37ed00d3b7b4d8da7c19d082a00db6f8/web/v2.0/plugins/auto/sarkaspip_3/inc/sarkaspip_filtres_agenda.php on line 556" à la place du mini-agenda mais selon mon hébergeur la requête SQL se poursuit en parallèle pendant plusieurs minutes et finit par saturer le serveur.

Mon site est actuellement sous Spip 2.1.2 avec Sarka-Spip 3.0.4

Ce problème est vraiment critique car mon hébergeur me demande une vraie solution sous 2 semaines. Un changement d’hébergeur ne fera que déplacer le problème et, de plus, je suis très satisfait de celui-ci.

Quelle solution pourrais-je appliquer ?

Merci d’avance pour votre réponse.


Ce sujet est verrouillé : vous pouvez consulter son fil de discussion mais vous ne pouvez plus y répondre.

Réponses

30 décembre 2010 à 12h26
_Christophe_

Logo de _Christophe_

Jacques,

Réponse en coup de vent... passe en revue les échanges des mois précédents, ton souci correspond fortement à ce à quoi nous avions dû faire face, mais cela concernait plutôt le comportement des robots liés au "bug" de l’année 2038 (l’autre extrème des dates calendrier semble-t-il).

Si les explications ne t’aident pas (j’avais donné une solution certes radicale mais au moins qui fonctionnait et doit aisément pouvoir être adaptée).

Christophe
30 décembre 2010 à 12h39
_Christophe_

Logo de _Christophe_

Jacques,

re,

pour ne pas rester sur une réponse trop abrupte, j’ai personnellement résolu le problème (apparemment identique sauf que je suis sur OVH et que cela concernait des requêtes sur l’année 2038) en personnalisant, après son installation, l’écran de sécurité SPIP (tu trouveras des infos facilement avec une recherche Google).

Ma perso est la suivante (à insérer quelque part dans la suite de blocs "if (isset..." :

/* - bloque les requetes calendrier_annee=2038 AJOUT PERSONNEL POUR EVITER LES ERREURS CPU
*
*/
if (isset($_REQUEST[’calendrier_annee’])
AND preg_match(’,^2038,i’, $_REQUEST[’calendrier_annee’]))
$ecran_securite_raison = "calendrier_annee=2038" ;

Voilà, c’est un peu loin maintenant, j’avais passé un temps fou à la résolution de ce souci, mais ce fut radical. A adapter avec ton année favorite :-)

Espérant t’avoir aidé (et espérant ne pas être concerné moi aussi par ce nouveau souci !).

Christophe
30 décembre 2010 à 14h22
Jacques83300

Logo de Jacques83300

Error 403

Illegal page call (invalid year)
30 décembre 2010 à 14h24
Jacques83300

Logo de Jacques83300

Désolé, je remets le code

/* Bloque les requetes calendrier_annee<2000 et > 2029
*  AJOUT PERSONNEL POUR EVITER LES ERREURS CPU (saturation serveur)
 *
 */
if (_request('calendrier_annee') AND !preg_match(',^([2][0][0-2][0-9]),i', _request('calendrier_annee'))){
	       header("HTTP/1.0 403 Forbidden");
        	die("<html><title>Error 403: Forbidden</title><body><h1>Error 403</h1><p>Illegal page call (invalid year)</p></body></html>");
}

Jacques