Developers of Sympa

[Olivier Salaün - CRU <address@concealed>]

We were recently reported some performences issues with sympa's web interface while running 1000+ mailing lists.
Eventually we have built a test platform with up to 6000 lists and we managed to identify the following bottlenecks :

1. wwsympa.fcgi startup may be very slow (> 60 sec with 2000 lists) and obliges to extend the default fastcgi idle timeout parameter
2. global requests (the ones not dealing with one list) take too long  (up to 10sec with 2000 lists)
3. list-related requests also take too long (up to 8sec to access the list info page)
4. the wwsympa.fcgi process is somehow fat (around 200 Mb for 2000 lists)

We've been able to understand some of these problems and fix some :

(1) was mainly related to the config file parsing ; we're now using an additional binary version of the config file that is used unless the config file itself changed ondisk. This saves us 44sec out of the 49sec that get_lists (cumulative time) used to consume (with 2000 lists).

(2) is clearly related to the get_which() calls and might be related to too many SQL requests in the admin table. Anyhow we hope to optimize this when we'll be working on user session management : a user session attribute might be his memberships. We could save many get_which() calls this way.

(3) was related to the get_which()  calls. It has been fixed : get_which() calls are not desired when a web action deals with a single list.

(4) we didn't find out why wwsympa.fcgi processes might be that big. But maybe it's acceptable if wwsympa.fcgi has good performences because a few of them would be enough then.

The changes we made were done on the current development version of Sympa, that should not be used yet.
It will become the 5.2 release with intermediate beta stages.

Any comments, informations from the list ?
 

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