Bonjour,

j'ai un questionnaire un peu conséquent (583 questions dont 48 en affichage de texte => 939 réponses attendues max par questionnaires). Pour le moment il est en tests finaux (4 répondants)

Quand je tente de visionner les stats (voir toutes les réponses + visualiser le résumé , sans rien d'autre de cocher) ... j'ai un beau message d'erreur :

" Le site Web a rencontré une erreur lors de l'extraction de ns222842.ovh.net/sondages//admin/admin.p...ion=statistics#start. Cela peut être dû à une opération de maintenance ou à une configuration incorrecte."

Erreur HTTP 500 (Internal Server Error) : Une situation inattendue s'est produite tandis que le serveur tentait de traiter la demande."

Le Apache sur ce serveur arrivant à gérer des affichages dynamiques de plus de 600 000 lignes à la construction de page HTML, je ne pense pas que cela soit lié à sa configuration.

Donc je pense que c'est LS qui est débordé par le nombre de traitements à faire pour afficher les stats sur ce questionnaire.
ps : le questionnaire précédent (cloturé) avec 91 questions lui fonctionne très bien en stats (et même avec les graphiques). je viens de le tester entre deux tests sur le "gros" questionnaire.


Auriez-vous des pistes de paramètres à changer éventuellement dans la configuration pour cela. ou alors cela pourrait-il venir du code ?

Si pas de solution, ce n'est pas trop grave : on exportera les données et on fera en externe pour les stats et graphiques mais bon ... l'outil permettait d'avoir un aperçu rapide indépendamment de l'analyse détaillée et croisée des réponses

Je suis preneur de toute idée sur le sujet.

ps : Version 1.92+ Build 120319

Tu ne demande pas l'affichage des graphiques ?
Moi, j'ai ce pb lorsque le serveur n'est pas assez puissant et que je demande les graphiques.

Si tu affiches moins de résultats, par exemple, juste une ou 2 questions ça donne quoi ?

Si ça fonctionne sur ton gros formulaire sans les graphiques ou avec moins de question, faut soit upgrader ton hébergement, soit augmenter la mémoire disponible si c'est prévu par ton hébergeur.

Je n'ai jms eu a traiter ce cas chez OVH.

En fait, sur le test en moins de résultats :
... il me plante, même si je ne demande la stat (sans graphique) sur uniquement la première question ! OUPS!

Donc soit la chaîne de traitement envoie tout les champs en disant "a faire" ou "ne pas faire" et elle est trop long et plante, soit le questionnaire à un soucis mais tout le reste fonctionne nickel.
n'ayant pas mis les pied dans le code ... je ne sais pas.

ps : notre serveur dédié chez OVH certes gère d'autres choses mais on a 64 Go de RAM et on est sur du SSD. la BDD MySQL gère par ailleurs une BDD de près quelques dizaine de millions d'enregistrements sans aucun soucis ... ce ne sont pas les quelques milliers d'enregistrement de LS qui vont changer le comportement. Et en plus j'ai vérifié, quand je fais cette demande j'ai rien d'autre qui tourne, ce serveur est en ce moment (vacances d'été) presque au repos. Je pense réellement qu'il y a un bug dans l'outils de stats à la vue des plus de 900 champs de réponse liés au questionnaire.

Là il va falloir attendre un spécialiste, en effet, à ce que tu décris, la taille du serveur ne semble pas en cause ou alors c'est qu'il commence à devoir gérer beaucoup de choses, et petit à petit, la charge augmente.

Ce n'est pas tant le nombre d'enregistrements qui est en cause mais les traitements qu'ils engendre. J'ai un serveur mutualité qui gère un forum avec une DB de plusieurs centaines de Mo, mais lancer les graphiques pour 10 questions en même temps dans LS le fait planter.

Mais le pire c'est que sur l'autre questionnaire clôturé ....
(91 questions et je ne sais plus combien de réponses)

.... je demande tout (graphique, sous totaux, show text respons inline, ...) et ça passe : j'ai la réponse (entre le clique sur "afficher les stats" et la page affichée) en moins de 50 secondes (HTML). je viens aussi de le sortir en PDF (404 pages), sans soucis.

Dans le cas du questionnaire qui plante, l'erreur arrive en 1 à 2 secondes. Certes il est activé mais cela n'a jamais fait planté lors des questionnaires précédents.

On va attendre un spécialiste

Dans les logs d'erreurs de ton serveur tu n'as rien de suspect ?
Puisque tu es en dédié, tu dois avoir accès aux logs d'erreurs.

Mes techniciens étant en congés ... après de longue recherche dans les logs :

Dans le user log j'ai trouvé cela :

> Jul 26 08:41:16 ns222842 suhosin[9665]: ALERT - configured POST variable limit exceeded - dropped variable 'D93561X63X1512>' (attacker '81.252.54.251', file '/home/www/sondages/admin/admin.php')

et dans le error log d'apache2 j'ai trouvé :

> [Thu Jul 26 08:41:16 2012] [error] [client 81.252.54.251] LimeSurvey ERROR while checking POST session- Probable CSRF attack Received= / Expected= arusuf6m7h for action=statistics ., referer: ns222842.ovh.net/sondages//admin/admin.p...statistics&sid=93561

> [Thu Jul 26 08:41:17 2012] [error] [client 81.252.54.251] PHP Fatal error: Call to undefined function showadminmenu() in /home/www/sondages/admin/admin.php on line 670, referer: ns222842.ovh.net/sondages//admin/admin.p...statistics&sid=93561

Je vais regardé si on peut augmenter cette variable de limite en POST et voir si cela arrange quelque chose. je vous tiens au courant.

A priori le php installé a été livré avec Suhosin (protection contre les attaques). Le serveur ayant moins d'un an, on n'avait jamais été confronté à cette erreur.

Donc en faite ce "petit" changement faire que les tailles des GET, POST, COOKIES et bien d'autres choses sont limitées.

Si vous rencontrez le problème:
Vérifier si votre PHP est "livré" avec Suhosin :

root@ns222842:~# php -v
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Ensuite en fonction du blocage, changer les variables adéquates.
reportez-vous à www.hardened-php.net/suhosin/configuration.html

et plus précisement sur www.hardened-php.net/suhosin/configurati...ml#filtering_options

Nous allons appliquer chez nous.

Par contre, fallait le savoir car on a installer le Package PHP5 sur notre Debian 6.0 en utilisant aptitude et on n'a pas fait attention que, dans les dernières versions du packet, Suhosin était livré par défaut avec PHP.

en espérant que cela puisse servir car j'ai bien l'impression que cette protection poussé dans la distribution par défaut (via aptitude) va s'étendre en en prendre plus d'un par surprise

Bonne journée à tous.

Me reste une question ... comment je peux déterminer la taille de mon post quand je lance "afficher les statistiques".
Pour fixer les limites de POST au dessus de mon besoins sans faire le "bourrin", il faudrait que je vois quelle est la taille actuelle, et laisser une marge.

Sous chrome j'ai Web Developper d'installé mais je ne trouve pas de fonction permettan de voir cette trame de POST ... je sais que cela sort du domaine de LS mais si l'un de vous à une solution.