Comment 7 for bug 990215

Ici, les seules requêtes qui sont problématique sont celles pour les statistiques.

Nous pouvons partager notre setup du stack software, parce que c'est vraiment ça qui fait la différence. Notre serveur supporte 400 bornes + les demandes de connexions et ils dors au gaz.

Marc

Sent from my iPhone

On 2012-05-04, at 3:14 PM, jackson <email address hidden> wrote:

> Salut Wahid,
>
> dans ton premier message tu dis "Étant la nature du logiciel, chaque minute
> le serveur
> reçoit des appels de tous les routeurs qui performent des requêtes full-
> scan chacunes ce qui causait une utilisation de ressources trop élevée."
>
> Effectivement, on a eu ce problème aussi qui peut s’apparenter à un genre
> de DoS
>
> Nous avons trouvé une solution de contournement en changeant le fichier
> wifidog.conf de tous nos nouveaux routeurs (et des anciens que l'on met à
> jour quand on peut) :
>
> dans wifidog.conf, il y a une variable "checkinterval" qui par défaut est à
> 120 secondes. Ce qui veut dire que le routeur fait une requette toutes les
> deux minutes au serveur.
> Si tu met cette valeur à 900, la requete ne sera que toutes les 15 minutes,
> ce qui divise la charge serveur par 7,5 pour un nombre de routeurs égal !
>
>
> Cordialement
> Jackson JOSEPH-EUGENE
> Coordinateur technique et des bénévoles Ile Sans Fil
>
> Le 4 mai 2012 14:34, Wadih <email address hidden> a écrit :
>
>> Merci Genevieve
>>
>> Quand mon serveur rushait, je regardais l'onglet Processes sur
>> phpmyadmin (equivalent à la commande SHOW PROCESSLIST dans mysql), et
>> les requêtes s'accumulaient et ne se terminaient pas. Je n'ai
>> malheureusement pas pris à ce moment de capture d'écran des requêtes
>> problèmatiques.
>>
>> Depuis que j'ai transvidé la table, toutes les requêtes se terminent en
>> moins d'une seconde quand je surveille show processlist.
>>
>> Je vais garder un oeil dessus aussi et ajouter de l'info quand j'en
>> aurais.
>>
>> Concernant les 55 mb de grosseur, à ce taux elle va grossir de 220 megs
>> par année. Je pense que je vais simplement garder 1 année de données
>> dans mes backups, sinon les choses vont prendre trop d'espace.
>>
>> --
>> You received this bug notification because you are subscribed to
>> AuthPuppy.
>> https://bugs.launchpad.net/bugs/990215
>>
>> Title:
>> Too many data in table connexions
>>
>> Status in AuthPuppy authentication server for Wifidog networks:
>> Confirmed
>>
>> Bug description:
>> Je voulais rapporter quelques difficultés que nous avons encourus, et
>> dont une solution serait surement utile à tous.
>>
>> En 4 mois d'utilisation, le tableau connexions a augmenté à 100,000
>> entrées, 55 MB. Étant la nature du logiciel, chaque minute le serveur
>> reçoit des appels de tous les routeurs qui performent des requêtes
>> full-scan chacunes ce qui causait une utilisation de ressources trop
>> élevée.
>>
>> Pour comparer, la base de données wifidog n'a jamais dépassé les 200
>> megs au complet incluant le contenu après les 5 années d'utilisation.
>> Je pense que le tableau "connexions" se balonne trop rapidement, et
>> deviens un point de pression du logiciel.
>>
>> Une proposition que j'aurais serait de mettre en place de l'archivage
>> automatique, c'est à dire que les vieilles entrées qui n'ont pas
>> besoin d'être visitées à chaque requêtes soient déplacée dans une
>> table à part pour que la table "live" soit toujours légère et rapide.
>>
>> Ma solution pour le moment est de transvider la table connexions à
>> chaque 2 mois pour que cette dernière reste toujours légère.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/authpuppy/+bug/990215/+subscriptions
>>
>
> --
> You received this bug notification because you are a member of
> AllianceCsfDev, which is the registrant for AuthPuppy.
> https://bugs.launchpad.net/bugs/990215
>
> Title:
> Too many data in table connexions
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/authpuppy/+bug/990215/+subscriptions