Hello tout le monde, et désolé pour le réveil :-)

Il se trouve que je suis aujourd'hui confronté à ce même problème de "Too Many connections".
Le pire que ça me le fait sur 2 bases qui sont toutes deux hebergées chez free.fr

Je sais que j'ai AStat d'installé sur les 2 versions de piwigo (une en 2.0 l'autre en 2.1.RC)

J'ai découvert le probleme lorsque de mon PC perso à la maison, j'ai voulu me connecter sur mon site. Avant celà J'avais déjà navigué dessus depuis le boulot, pour notemment regarder un peu les plugins présents sur l'un et sur l'autre, joué un peu avec le menu d'administration d'affichage des images, et ouvert un mur 3D cooliris sur la version 2.0 (qui doit toujours etre ouverte sur mon poste du boulot d'ailleurs).
Mais je ne pense pas que ce soit cooliris le fautif puisque non disponible sur la version RC.

Bref, ne pouvant pas rebooter le sql de free !! :-p existet-il un moyen pour effectuer un reset de toutes les connections en cours ? (Je ne sais pas, je dis n'importe quoi je n'y connais pas grand chose, mais peut-etre en virant le .htaccess temporairement, ou un autre fichier .php de piwigo...?)

Merci beaucoup de votre aide !


[EDIT] Bon désolé pour le dérangement, il s'agissait donc juste d'un problème de maintenance de la part de free. Après quelques heures, tout est redevenu dans l'ordre :-)

ok vdigital c'est fait, je n'est plus de plantage de mysql, mais :

Un problème s'est produit lors du chargement de http://star.the-free-server.org/admin.p … s_by_image :
Pas de réponse du serveur
star.the-free-server.org

ce qui doit provenir d'un temps de "calcul" de  la BDD trop long

suite a la conversation de tosca et grum pourquoi ne pas charger  en plusieurs fois ?

tosca a écrit:

Je ne suis pas si sûre que ça : en général, ce genre d'outils permet de faire des requêtes plus "fines", bien ciblées sur ce que recherche l'utilisateur

C'est exactement ce que fait AStat ;-)

tosca a écrit:

ce qui peut éviter de "tout descendre" avec des accès DB dans tous les sens pour ne restituer que quelques informations vraiment utiles ; et une bonne partie des rapprochements / totalisations / calculs, etc. est assuré en local.
La charge peut être répartie en quelque sorte, partie sur le serveur, partie en local.

c'est exactement ce que ne fait pas AStat :o)


Répartir la charge, on peut faire la même chose en PHP, pas besoin d'une application cliente.
Juste que, le temps que tu gagnes au niveau du serveur MySQL, tu le perds en transfert de données entre le serveur MySQL et le client (que le client soit un poste délocalisé ou un processus Apache, c'est pareil sauf que entre un serveur apache et un serveur mysql tu peux être certaine que la durée de transmission sera largement inférieure à celle que tu auras entre un poste client et un serveur mysql).


Quand tu as 365000 enregistrements à cumuler, soit tu laisse faire le serveur (il est optimisé pour çà) soit tu le fais toi même => celà implique un rapatriement des informations. Hors, ce rapatriement à un coût, que ce soit vers le serveur apache, ou vers une application cliente.

Exemple simple : une table historique avec 365000 enregistrements, comparaison des deux méthodes évoquées :
  Durée de la requête "SELECT id FROM history" et récupération de tous les éléments sur l'application client, boucle pour compter  => 2.190s
  Durée de la requête "SELECT count(id) FROM history" et récupération de tous les éléments sur l'application client  => 0.001s

A moins de réussir à me trouver des contres exemples concrets, je reste ancré sur ma position :-D
(et je suis une vraie tête de noeud... ;-P )



accessoirement, je me demande si on est pas en train de s'éloigner du sujet principal : pourquoi les requêtes AStat mettent à plat le serveur de nounours93....

tosca a écrit:

grum a écrit:

Si tu veux tout délocaliser sur le poste client, celà implique donc d'exporter l'intégralité de ces tables et de les avoir à disposition sur le poste client...

Pas tout ... juste la création / mise en forme des rapports (toute la partie interface utilisateurs en fait), avec appel à des requêtes "ciblées" sur le serveur.
Si l'on peut trouver un équivalent libre de Crystal Reports, on devrait pouvoir fournir un certain nombre d'états de base, l'utilisateur ayant ensuite la possibilité d'adapter ou de développer ses propres rapports.

Je n'ai pas eu le temps de regarder en détail, mais il y a peut-être quelques pistes  : http://www.osalt.com/crystal-reports

donc au final, le problème est le même : sollicitation intense du serveur....

Un outil comme AStat effectue entre autre des jointures entre :
- la table des utilisateurs
- la table des catégories
- la table des liens images/catégories
- la table des images
- la table des évènements

Si tu veux tout délocaliser sur le poste client, celà implique donc d'exporter l'intégralité de ces tables et de les avoir à disposition sur le poste client...


Mon historique fait 25Mo, pour environ 450000évènements.
Je n'ose pas imaginer la taille de la base de nounours93.

tosca a écrit:

a priori plutôt sur le poste client ...

celà implique une extraction de la base de donnée, et de disposer localement d'un logiciel qui permet d'analyser ces informations....

donc à mon avis, pas vraiment envisageable.

VDigital a écrit:

C'est certainement dû à la complexité des requêtes qui font beaucoup de jointure avec les table categories et images.

J'avoue que AStat n'est particulièrement pas optimisé pour les grosses bases.

Son intérêt, c'est d'être mesure de fournir des stats très détaillées. Ceci implique de travailler directement sur chacun des évènements présents dans l'historique à chaque requête.
Les jointures sont nombreuses, les sous requêtes aussi (nécessaires pour le calcul des % par exemples).

Les alternatives sont :
- proposer un mode dégradé : par exemple ne plus exprimer les pourcentages, juste des chiffres
      * avantage : les requêtes sont moins complexes et çà allège le serveur
      * inconvénient : les informations sont moins pertinentes
- proposer un système similaire à celui offert en natif par piwigo : gérer une base de cumuls
      * avantage : rapidité de l'exécution des requêtes
      * inconvénient :
            . il faut gérer une table par type de cumuls (çà fait beaucoup de tables vu le nombre de combinaisons)
            . le volume de la base va grimper très nettement (il faut avoir de l'espace pour sa base)
            . il faut disposer d'un cron afin que les cumuls soient réalisés régulièrement
- modifier le système d'historique de Piwigo : il faut réfléchir à la question...
      * avantage : à étudier
      * inconvénient : à étudier (reprise des données, charge, impacts sur l'existant, ...)


Par contre, je n'explique toujours pas comment on arrive au message 1040.
Dès que j'ai le temps (soit pas avant d'avoir fini la gestion des métadonnées), je fait un plugin pour benchmarker Piwigo (un truc auquel je pense depuis un bout de temps : un plugin qui alimente en automatique et les images, les catégories, les tags, les commentaires, tout çà quoi, dans des volumétries variables....)