Wikipédia:Bulletin du filtrage/2011/mars

Problème avec le Filtre n°89 : optimisation des filtres à revoir ?

Salut à tous ! J'attire votre attention sur cette modification, qui m'a été rapportée par Jean-Guy Badiane (d · c), et qui aurait du être détectée par le Filtre n°89. Le problème ne vient pourtant pas du filtre en lui-même : en examinant la modification et en la soumettant au code du filtre, elle est bel et bien détectée ! Je pense que le problème vient donc d'un manque d'optimisation des filtres. En effet, les filtres précédant le filtre 89 semblent, au moment de la modification, avoir atteint à eux seuls la « limite des 1 000 conditions autorisées », ne laissant plus de conditions pour les autres filtres ! Cela semble se confirmer par les statistiques de la page Spécial:Filtre antiabus…

Je laisse donc un message ici pour vous demander votre avis, mais je pense qu'il faut à nouveau repartir pour une nouvelle "campagne d'optimisation des filtres" (cf. la section "Optimisation des filtres" un peu plus haut). Toto Azéro ^{suivez le guide !} 19 mars 2011 à 21:11 (CET)

J'ai fait une liste des filtres qui servent peu :

• Filtre 39 (détections du 07/05/2010 au 21/06/2010)
• Filtre 47 (dernière détection le 12/11/2010, sans compter le faux positif le 20/01/2011)
• Filtre 55 (détections du 02/09/2010 au 09/12/2010, sans compter le faux positif le 22/12/2010)
• Filtre 63 (détections seulement le 09/2010)
• Filtre 65 (détections du 02/09/2010 au 29/10/2010)
• Filtre 76 (détections seulement le 04/11/2010)
• Filtre 77 (aucune détection)
• Filtre 80 (aucune détection)
• Filtre 82 (aucune détection)
• Filtre 87 (détections seulement le 17/12/2010)
• Filtre 92 (détections du 26/02/2011 au 27/02/2011)

Y en a-t-il à garder quand même là-dedans ?

Orlodrim ^[discuter] 19 mars 2011 à 22:35 (CET)

À l'exception du dernier qui est encore utile (il y a eu des faux négatifs après le 27/02), j'approuve et supprime tous les autres filtres. — Arkanosis ^✉ 21 mars 2011 à 12:26 (CET)

J'approuve (un peu tard mais bon ! ) Merci pour tout Orlodrim et Arkanosis : on est retombé à 2 dépassements de la limite sur plus de 7000 actions (~ 0,03 %). Toto Azéro ^{suivez le guide !} 24 mars 2011 à 19:10 (CET)

J'ai par ailleurs enlevé certains tests du filtre 79. Nakor (d) 24 mars 2011 à 19:37 (CET)

Merci également, Nakor ! Toto Azéro ^{suivez le guide !} 25 mars 2011 à 18:21 (CET)

Nombre de conditions

J'ai essayé de regarder directement le code d'Abusefilter. Je ne garantis pas l'exactitude de ce qui suit et j'ai peut-être manqué certains éléments.

D'abord, il semble y avoir un bug dans l'affichage du nombre moyen de conditions utilisées par un filtre. Le code qui calcule les statistiques (fonction getFilterProfile) est :

$countKey = wfMemcKey( 'abusefilter', 'profile', $filter, 'count' );
$totalCondKey = wfMemcKey( 'abusefilter', 'profile-conds', 'total' );
$curCount = $wgMemc->get( $countKey );
$curTotalConds = $wgMemc->get( $totalCondKey );
$condProfile = ( $curTotalConds / $curCount );
$condProfile = round( $condProfile, 0 );

$countKey est le nombre de fois où le filtre a été testé (normalement, la même chose pour tous les filtres sauf ceux qu'on vient d'éditer) et $totalCondKey ne semble pas dépendre du filtre ! Étrange... Je pense qu'on ne peut pas tenir compte de ces statistiques pour le moment.

NB : j'ai testé les dix premiers filtres, vingt fois chacun. J'ai renouvelé l'expérience deux fois. Il est clair que les données sont incohérentes : Utilisateur:Orlodrim/Stats ABF.

Ensuite, le "nombre de conditions" n'a pas grand chose en rapport avec les conditions. Ce qui est compté est le nombre d'appels à la fonction triggerLimiter. Abusefilter lit les filtres avec un parser par descente récursive. Les premiers niveaux de la grammaire des expressions sont :

• Expr -> Cmp | Cmp opérateur_logique Expr
• Cmp -> SumRels | SumRels opérateur_de_comparaison Cmp
• SumRels -> MulRels | MulRels + SumRels | MulRels - SumRels

Une première chose prise en compte est le nombre de token Cmp. Exemples :

• 1 pour ("a" in added_text)
• 3 pour ("a" in added_text) & ("b" in added_text) & ("c" in added_text)
• 1 pour (round("a", added_text) > round("b", added_text))
• 2 pour ("a" in added_text) & (round("a", added_text) > round("b", added_text))

La seconde chose prise en compte (elle s'ajoute à la première) est le nombre de fonctions évaluées (celles qui prennent des arguments entre parenthèses, pas les opérateurs de type in/rlike). Ce n'est pas constant, car certaines fonctions ne sont pas toujours exécutées, pour deux raisons :

• L'évaluation paresseuse des conditions (dans a & b, le b n'est pas évalué si a est faux)
• La mise en cache : pour les fonctions sans effet de bord, une table de hachage stocke les assocations (fonction,arguments)->résultat. Elle est vidée tous les 1000 appels de fonction.

Orlodrim ^[discuter] 20 mars 2011 à 01:26 (CET)

Pour résumer ce qui précède en une phrase : il ne faut pas tenir compte des statistiques affichées. Pour optimiser, il faut juste réduire le nombre de filtre actifs et réduire la longueur de chaque filtre. Orlodrim ^[discuter] 20 mars 2011 à 12:24 (CET)

Whaaa, génial ! Merci Orlodrim .

C'est vrai qu'on était totalement dans le brouillard, ça nous éclaire déjà pas mal. — Arkanosis ^✉ 21 mars 2011 à 12:26 (CET)

Je n'aurais qu'une seule parole : « Waouh ! ». Orlodrim tu es un génie ! Toto Azéro ^{suivez le guide !} 24 mars 2011 à 19:10 (CET)

Ménage de printemps

Salut à tou(te)s, Je viens de terminé mon classement des archives poussiéreuses du filtrage.

Il serait pas mal de voir ce qu'on fait des requêtes qui traînent (requêtes, faux positifs). Bien à vous, Micthev ^(discuter) 28 mars 2011 à 00:52 (CEST)