Skip to Content.
Sympa Menu

devel - Re: [sympa-dev] Sympa 5.1 sloooooooow with many lists

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: Olivier Salaün - CRU <address@concealed>
  • To: Adam Bernstein <address@concealed>
  • Cc: address@concealed
  • Subject: Re: [sympa-dev] Sympa 5.1 sloooooooow with many lists
  • Date: Fri, 19 Aug 2005 09:25:33 +0200

Hi Adam,

I suppose you are running Sympa web interface with FastCGI (silly question) ?

Are all your lists in 'include2' mode (the default one now) ?
If not that is an explanation for these bad performences because :
The get_which() calls to list owners and editors is optimized for mailing lists in 'include2' mode. Along with the new owner_include and editor_include features we have introduced a cache management of all list owners and editors in the admin_table of the database. But this is done for lists in 'include2' mode only.

If this is not the reason for your bad perf, then I can think of 3 general causes :
  1. sympa spends too much time reading (or checking inode info of) config files
  2. sympa does too much SQL queries (easy to check via your MySQL log)
  3. sympa spends too much time evaluating the visibility scenario

Adam Bernstein wrote:
Alright, this may be partly my fault, but I've found that Sympa 5.1 is verrrrrrrry slow when the robot has many lists in it, such as on our primary domain at http://npogroups.org, which has nearly 1000 lists.  It can take 5, 10, even 15 seconds to respond to every click.  It's much faster in virtual robots on the same server that contain only a handful of lists, such as http://lists.accuracy.org.  (So it's not a result of using css.tt2, or anything like that.  It's definitely a result of the large number of lists.)

I would have to guess that it's spending a lot of time doing get_which routines now, possibly in part because of my patch for the Your Lists window, although I never saw this kind of slowdown with the previous version of the code (in which I was running almost the same patch).  I see that in most cases, get_which is called three times, for member, owner, and editor roles, and that each time the get_which routine loads and cycles through every list in the domain, which is a bit insane.

I'm trying to figure out if there's a clean way to rewrite the code so that get_which is only called once, cycling through the list of lists only once, and returning information for all three roles in the same call.  That would cut down the list-loading time by 2/3, although I'm not sure exactly how many of my clicks will actually be affected by that savings.  Any suggestions?
  

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




Archive powered by MHonArc 2.6.19+.

Top of Page