Developers of Sympa

[Adam Bernstein <address@concealed>]

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

Yes, of course.

> Are all your lists in 'include2' mode (the default one now) ?

I checked, and only a few were not, and now they're all changed.

> 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

I'm pretty sure it's not #2, as the mysqld process never shows any CPU
load (but I haven't yet figured out where the log is or how to check
it).  I'll try running in debug mode and looking for clues on #1 or #3
when I get a chance.

But with some debugging turned on, it does look like most of the delay
is spent in calls to get_which().  In fact, it's called four times for
each click, because we're using the dynamic style.css (so that we can
continue to set colors in robot.conf for our 90 virtual robots instead
of having 90 static style.css files).  It seems to me that when the
action is "css", almost nothing else should happen -- especially not
calls to get_which() -- and that would cut the delay in half.  I'm
trying to streamline wwsympa.fcgi in this way with minimal changes, but
no luck yet.

      adam