Skip to Content.
Sympa Menu

devel - RE: [sympa-dev] Optimizing Sympa's web interface

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: "Dean Ericksen" <address@concealed>
  • To: <address@concealed>
  • Subject: RE: [sympa-dev] Optimizing Sympa's web interface
  • Date: Thu, 6 Oct 2005 07:54:39 -0700

 

This is great news. We have grown to live with the performance delays …but if they can be addressed in 5.2, we would be very happy.

 

A related note that could boost speed/flexibility of returning global list info: is it possible to pour the contents of the /expl/*/config files into a mysql table? I recognize that there is a lot of baggage in the /expl/*/ directory that might not fit neatly into a database (page customizations, etc), but the config file itself seems easily portable to this format.

 

-Dean

 


From: Olivier Salaün - CRU [mailto:address@concealed]
Sent: Thursday, October 06, 2005 3:50 AM
To: address@concealed
Subject: [sympa-dev] Optimizing Sympa's web interface

 

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 :

wwsympa.fcgi startup may be very slow (> 60 sec with 2000 lists) and obliges to extend the default fastcgi idle timeout parameter global requests (the ones not dealing with one list) take too long  (up to 10sec with 2000 lists) list-related requests also take too long (up to 8sec to access the list info page) 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 ?
 




Archive powered by MHonArc 2.6.19+.

Top of Page