Hey there folks,
Not sure if anyone else has run across this issue, but it's slowly driving me batty. I currently have mailman 2.0.9-1 running on a Xeon 800 with 500 megs of ram. It has a single mailing list with roughly 450,000 subscribers.
I've found that accessing the web interface for administration is incredibly slow. Is there any way to speed that up, or to handle pending admin tasks from the command line? When watching system processes, I notice that python takes up virtually all available CPU when it's loading the web interface.
Thanks in advance for any and all assistance.
Tremaine
On Sun, May 26, 2002 at 08:15:37PM -0600, Tremaine Lea wrote:
Hey there folks,
Not sure if anyone else has run across this issue, but it's slowly driving me batty. I currently have mailman 2.0.9-1 running on a Xeon 800 with 500 megs of ram. It has a single mailing list with roughly 450,000 subscribers.
I've found that accessing the web interface for administration is incredibly slow. Is there any way to speed that up, or to handle
There are lots of linear scans, and yes it will be slow.
The only way to speed that up is to revisit the code. Porting users to a DB however shouldn't be too hard, Barry did use a base object that has methods you can override.
Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
On Sunday 02 June 2002 06:03 pm, Marc MERLIN wrote:
On Sun, May 26, 2002 at 08:15:37PM -0600, Tremaine Lea wrote:
Hey there folks,
Not sure if anyone else has run across this issue, but it's slowly driving me batty. I currently have mailman 2.0.9-1 running on a Xeon 800 with 500 megs of ram. It has a single mailing list with roughly 450,000 subscribers.
I've found that accessing the web interface for administration is incredibly slow. Is there any way to speed that up, or to handle
There are lots of linear scans, and yes it will be slow.
The only way to speed that up is to revisit the code. Porting users to a DB however shouldn't be too hard, Barry did use a base object that has methods you can override.
Marc
Actually this came up once before, and we had the user build a RAM drive and load his config directory in there then mount that in place of the real config directory. It worked like a charm.
All the database accesses, rebuilds, etc took place in RAM rather than on disk. You can imagine that this was much faster.
BTW: just to be safe, he backs up the RAM drive hourly (I think...)
Jon Carnes
participants (3)
-
Jon Carnes -
Marc MERLIN -
Tremaine Lea