In 1.8a, a number of commands (including ADD) were rewritten in PASCAL
and made faster. That is, the time to execute the ADD command and decide
what to do with the request was reduced, but of course it still needs to
actually update the various disk files. Since then a number of
enhancements have been made, most of which were released together with
the FIX18AX2 update, which I can send you if you want. Specifically, your
problem is due to a very large *total* number of subscribers for the
server (as opposed to the list). If you ran the same list on an empty
server, it would be much faster. The code code should remove this problem
completely. Here is an excerpt from a uselessnet message with some
benchmarks using the new code.
-------------------------------------------------------------------------
> MajorDomo uses Perl, which means that startup time for the list
> distribution program and overhead for the program is higher than it is
> for Listproc.
Well, you need different tools for different situations. One situation for
which Majordomo is particularly suitable is a small machine where you don't
want to keep a process permanently active just for your mailing lists. If
you're running with a swap file of 8M or so, Majordomo is probably the best
alternative. And yes, I do know people in that situation :-)
If on the other hand you have plenty of swap space/memory and are mostly
concerned about performance, Majordomo is probably not the right tool,
especially if you have large lists. This has already been mentioned on a
mailing list and a flame war ensued about perl vs C, so I'll try to be smarter
and I won't blame it on perl :-) I'll just note that Majordomo can take quite a
while to process administrative commands on a list of, say, 10,000 subscribers.
Here are timings for a list of 100,000 subscribers under LISTSERV:
time quiet add big [log in to unmask] Eric Thomas
13 Nov 1994 01:40:09 From [log in to unmask]: time quiet add big
[log in to unmask] Eric Thomas
* Eric Thomas <[log in to unmask]> has been added to the BIG list. No
* notification has been sent.
VCPU=0.030 TCPU-VCPU=0.261 Elapsed: 0.451 sec
At this point I imagine you'll wonder what kind of machine this was running on.
Probably a $20M IBM mainframe with solid state disks, gee, who is that going to
fool? Well, let's see:
show hardware
13 Nov 1994 01:41:27 From [log in to unmask]: show hardware
* CPU model: 80486
Meet my PC, a 486/66 with a vanilla SCSI disk, running Windows NT :-) There is
no trick. I did change two configuration variables from their default values,
which aren't really suitable for lists with 100k subscribers. The reason I did
not send the notification message is that the PC isn't connected to the
Internet and doesn't run any mail program.
I did show you an example where the performance algorithms worked at their
best. This isn't always the case. Here are the best and worst cases for DELETE:
time quiet del big jjj@kkk
13 Nov 1994 01:48:04 From [log in to unmask]: time quiet del big jjj@kkk
* JJJ@KKK is not subscribed to the BIG list.
VCPU=0.060 TCPU-VCPU=0.230 Elapsed: 0.310 sec
time quiet del big aaa@bbb
13 Nov 1994 01:49:45 From [log in to unmask]: time quiet del big aaa@bbb
* AAA@BBB has been removed from the BIG list. No notification has been sent.
VCPU=2.203 TCPU-VCPU=0.260 Elapsed: 2.494 sec
Even in the worst case, the DELETE still took less than 2.5 seconds, most of
them attributable to the CPU which is, after all, only a 486. If you want to
reproduce the test, note that the first ADD/DELETE "doesn't count" as it is
used to establish the tuning for all following operations. You also need to set
FIOC_TARGET to 15000 or higher. This test was performed with all 100k users
also registered in the signup database, as they would be after 100k individual
SUBSCRIBE commands. If you only create the list, your figures will be better
and not directly comparable.
Of course, it would be madness to actually try to run a 100k subscribers list
on a 486. You could run the list, but you'd never manage to deliver the mail,
at least not if you want it all delivered within 20-60 minutes. So let's strike
a zero:
time quiet add big [log in to unmask] Eric Thomas
13 Nov 1994 01:51:29 From [log in to unmask]: time quiet add big
[log in to unmask] Eric Thomas
* Eric Thomas <[log in to unmask]> has been added to the BIG list. No
* notification has been sent.
VCPU=0.040 TCPU-VCPU=0.171 Elapsed: 0.221 sec
time quiet del big zzz@zzz /* best case */
13 Nov 1994 01:53:22 From [log in to unmask]: time quiet del big zzz@zzz
* ZZZ@ZZZ is not subscribed to the BIG list.
VCPU=0.010 TCPU-VCPU=0.190 Elapsed: 0.200 sec
time quiet del big aaa@bbb /* worst case */
13 Nov 1994 01:52:31 From [log in to unmask]: time quiet del big aaa@bbb
* AAA@BBB has been removed from the BIG list. No notification has been sent.
VCPU=0.260 TCPU-VCPU=0.170 Elapsed: 0.431 sec
That's a 10k list, something it could make sense to run on a 486. It will take
about half a second for a DELETE in the worst case. Incidentally, the reason I
gave only NT figures is that I don't have access to a dedicated or lightly
loaded PC running BSDi or Linux. I don't want to start a flame war about Linux
vs BSDi vs NT, but in general LISTSERV performance is on the same *order of
magnitude* among these three systems. So, it could be 0.687 or 0.247 rather
than 0.431, but hey, it's the same code.
Eric
|
