Re: [sympa-fr] Type de données pour bounce_score_subscriber

[Olivier Salaün - CRU <adresse@cachée>]

Bonjour,

Sylvain Amrani wrote:

Les limitations sont sur les champs de type email, et les champs de type nom de liste.

Ok, nous allons passer ces champs en varchar(255) et adapter les index sur ces champs.

Par contre nous pouvons ajouter un paramètre global permettant de désactiver cette fonctionnalité, afin de respecter des personnalisations éventuelles.

On pourrait mettre le %db_struct dans un db_schema.pl et rechercher le fichier source dans les répertoires habituels --ETCBINDIR-- comme pour les templates ?

La fonction de vérification de la structure de la base me semble présenter peu d'intéret si vous personnaliser la base. Dans ce cas on peut juste désactiver la vérification.
Peut-être ai-je mal interprété votre suggestion...

Mes craintes provenaient d'expressions comme REVERSE(SUBSTRING(user_subscriber FROM position('\@' IN user_subscriber) FOR 50));

Ce type de requête correspond à un tri des abonnés par domaine qui est effectivement le tri par défaut dans List::get_first_user(). Nous ne constatons pas ces problèmes de performence ; avez-vous optimisé votre serveur MySQL pour gérer de grosse tables (Cf chapitre 14.3 de http://www.sympa.org/documentation/tutorial/tutorial-fr.pdf)

et du temps d'environ 5 secondes entre 2 sync_include() en mise à jour de listes basées sur un filtre ldap (1 seconde environ pour le filtre lancé seul) alors que je n'ai pour l'instant "que" 5000 listes et 400.000 entrées dans la subscriber_table ; mais j'aimerais pouvoir aller vers du 10.000/1.000.000. Comme vous le voyez, j'ai plus de listes qu'elles ne sont grosses.

La fonction sync_include() est principalement appelée par le processus task_manager.pl qui peut supporter des délais de mise à jour un peu longs.

A regarder les logs, j'ai l'impression que sympa se débrouille mieux avec énormément d'utilisateurs plutôt qu'énormément de listes.

Probablement car pour chaque liste il est amené à consulter la configuration de celle-ci sur disque, notamment pour déterminer les privilèges associés à chaque action.

Wwsympa peut répondre bizarrement. Par exemple, si je demande la liste des listes ou bien mes abonnements et qu'il y a beaucoup de réponses (quelques milliers), j'obtiens quelques fois un fil RSS vide (alors que je navigue) ou une erreur 500. Il semblerait que les FOREACH de tt2 font des foreach et non des while (list() = ) ce qui fait qu'on charge toujours tout en mémoire.

Nous ne constatons pas ce problème, mais si vous avez des améliorations à suggérer...

En revanche, quand je travaille sur les utilisateurs d'une grosse liste, j'obtiens des tableaux bien paginés et tout est fluide. En fait cela peut rester secondaire, car il suffit de refaire les interfaces utilisateurs grâce aux interfaces SOAP.

C'est l'intéret de l'interface SOAP. Par contre :

1. seul un sous-ensemble des fonctionnalités sont actuellement accessible en SOAP
2. le serveur SOAP sera amené à effectuer les mêmes opérations que wwsympa, sauf si vous simplifiez la logique du produit
   

Par ailleurs, chaque clic sur l'interface CGI valide le schéma base de données !

On a effectivement récemment ajouté un probe_db() dans le corps de la boucle de Wwsympa pour détecter les problèmes d'accès à la base. Il faut qu'on le remplace par un appel à une fonction qui ne vérifie que la connection, pas la structure de la base.

Merci pour vos remarques.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature