I have  just finished to  process the replies  to the LSTSRV-L  survey about
LISTSERV. Here are the general trends:
 
- Everybody is  willing to  accept a few  ascending compatibility  problems if
  there is no other way to blend the LISTSERV and NETSERV command sets (only 1
  negative reply). 30%  of the people who replied said  that they were getting
  confused  with  the two  command  sets  because  they  are similar  and  yet
  different enough to make it easy to send an invalid command -- for instance,
  "AFD ADD password fn ft" versus "AFD ADD fn ft PW=password".
 
- Nobody feels that LISTSERV  eats too much CPU (one reply  was "a lot", three
  replies were "little", the rest was "normal").
 
- Everybody is  willing to spend  some virtual storage  or some DASD  space to
  reduce CPU,  even when they admitted  that CPU was  not a concern at  all at
  their installation. I also got some funny replies like "ok, but I won't give
  it  more than  12M --  that's my  last  word". To  clarify my  point, I  was
  speaking of an  increase in virtual storage of  at most 1M or 2M,  that is a
  recommended storage size  of 3-4M. As for  DASD space I meant  a few hundred
  kbytes to hold "summary" files (see the new PEERS NAMESUM file). Less than 2
  cylinders anyway.
 
- The same holds for DASD I/O, to a lesser extent.
 
- Most sites can give CPU cycles to help the network but not DASD space. A few
  sites can give DASD but not CPU, and some sites can give really nothing.
 
- Everybody thinks DISTRIBUTE is underused and is willing to participate in an
  ARPA backbone,  provided it does  not represent too  much local load  on the
  server. A  few sites added "provided  it is used for  academic distribution,
  not games" and  I treated that as a  "NO" reply as it is out  of question to
  start  red-penning  ARPA  distribution  lists.   If  the  stuff  has  to  be
  distributed, it will be sent anyway and my personal opinion is that the best
  possible method should be used, even if it means my LISTSERV will be used to
  distribute junk  mail about the last  DALLAS episode. I can  understand that
  other sites may have a different opinion, but it is not possible technically
  to "sort out" lists  and say "ok, use my server  for INFO-AMIGA INFO-VAX but
  not for SF-LOVERS ATARI-LOVERS " or suchlike.
 
- What are the slowest commands?
 
   o MAIL processing  when the input file  is 3,000 records and  there are 150
     recipients. Now how do  you want me to solve that? :-)  I'd say you ought
     to use DISTRIBUTE in that case (not just to reduce your CPU load).
 
   o ADD/SUBSCRIBE when the list is large (100+ users).
 
   o  Storing a  list. Actually,  any form  of the  PUT command  is slow,  but
     storing lists is the slowest.
 
   o GET or just  any command that makes reference to a file  when you have 30
     filelists and some of them are 1200 records large...
 
  The rest  was said to  be acceptable -- at  least considering the  work it's
  doing. You can't expect a full NODESGEN to take 15 seconds :-)
 
  I have made an  analysis of the above commands to determine  why they are so
slow. At  present I have  only examined the MAIL/ADD/SUBSCRIBE  commands, I'll
have a look at the file server stuff next week. MAIL is slow because EXECIO is
slow and because RFC822 takes time to parse.  There is not much I can do about
it. However,  the other  commands are  slow because  they manipulate  the huge
SIGNUP FILE (1500 records  on my server but probably much  more at hub nodes).
Besides, this file eats up a large amount  of DASD space because it is recfm F
(so that  it can be  updated). I have therefore  decided, based on  the survey
input, to spend  some virtual storage and a little  CPU time at initialization
to save DASD space and a lot of CPU when processing commands.
 
- The SIGNUP file is now stripped and kept in RECFM V format -- 50% savings.
 
- New entries  are consequently  always appended  at the  bottom, even  if the
  entry already exists.
 
- Its contents are  read into GLOBALV storage at initialization,  and the file
  is compressed if required. This takes some  time but it's done only when the
  server is rebooted. You might therefore  want to have your LISTSERV rebooted
  once a day at midnight or something like that.
 
  You would be  surprised at how much faster ADD/SUBSCRIBE  and PUT (list) are
on a  large list  with this little  mod. It costs  around 50kbytes  of storage
(with 1500 lines  of SIGNUP FILE --  should be a linear increase)  but I think
it's really worth  it. It saves you  around 40kbytes of DASD  space too (still
for 1500 lines).
 
  I  will be  looking into  using  some GLOBALV  storage for  the file  server
functions, but it's much  more complicated: if you have 30  filelists of up to
1200 entries, you'll need an awful lot of storage so it's not possible to just
keep everything in storage. I could  'cache' the latest 'nnn' entries, though,
but I'm not sure it would be a big help. I'll see.
 
  Eric