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