Paul, According to CataList, you are running the 1.8e version from May 2002. Here are the improvements that have been made since then that might help your performance. In particular, TUNE_MANY_LISTS was not added till December 2002 and has seen many improvements over subsequent releases. In other words, the TUNE_MANY_LISTS you have currently in your go.user is a no-op. Version 14.1 (1.8e 2002a, December 2002): http://www.lsoft.com/manuals/1.8e/relnotes/v18e-2002a.html Enhancements for the HPO version: A number of changes were made to the LISTSERV HPO code in the 1.8e-2002a level set to accelerate web and catalog scan operations and alleviate slowing problems seen by some very large LISTSERV sites. HPO sites with "many" lists can implement the changes by installing the 1.8e-2002a level set and adding a new site configuration variable, TUNE_MANY_LISTS, to their site configuration. The new variable is a binary value, and should be set to 1 in order to enable the functionality. Note carefully that there is no fixed threshold for the number of lists at which the implementation of these fixes becomes necessary. This makes LISTSERV work faster at the expense of memory. If you have 100 lists, you definitely will not need it. If you have 1000, you probably do. Anything in between would be up to you. Version 14.2 (1.8e 2003a) http://www.lsoft.com/manuals/1.8e/relnotes/LISTSERV14.3-Release-Notes.html PERFORMANCE: Miscellaneous improvements Where practical, routines have been tightened and performance improved. Specific improvements include: For HPO only, reverse indexing of attachments has been improved by an enhancement that better recognizes Base64, uuencode, and MIME boundaries. This change is not retroactive; reindexing will be required if reverse indexing is already enabled (ie, DBRINDEX=1). To force reindexing, simply delete listname.DBRINDEX wherever found, and the reverse index will be rebuilt at the next search of the list's archives. Also for HPO only, performance issues that arise when changelogs get very large have been addressed. Version 14.3: http://www.lsoft.com/manuals/1.8e/relnotes/LISTSERV14.3-Release-Notes.html Home page background rebuild. When you change a site-wide template, either L-Soft’s or your own, and list home pages depend on this template (even indirectly), LISTSERV automatically senses it and rebuilds all home pages for you. If you have LISTSERV-HPO, it does it in the background, letting other LISTSERV commands and tasks take precedence. Performance enhancement. Version 14.3 includes significant performance enhancements to the web interface, and in particular the Subscriber’s Corner, for sites with thousands of lists, as well as the TUNE_MANY_LISTS configuration option for LISTSERV-HPO, which can dramatically improve performance for sites with tens of thousands of lists. Version 14.4: http://www.lsoft.com/manuals/1.8e/relnotes/LISTSERV14.4-Release-Notes.html Background List Maintenance: Expanding on the background home page rebuild introduced in 14.3, most list maintenance tasks can be configured to take place in the background with LISTSERV HPO, dramatically increasing availability during busy periods for servers with thousands of lists. [HPO] Performance improvements for sites with many lists Available in LISTSERV HPO only The TUNE_MANY_LISTS site configuration parameter was released in LISTSERV 14.1 to provide significant improvements for sites with many lists and large amounts of physical memory. LISTSERV 14.4 adds additional improvements for sites with many lists. Some of these are always active in LISTSERV HPO but are further improved by setting TUNE_MANY_LISTS to 1. Others are only activated when TUNE_MANY_LISTS is set to 1. The main performance improvements for LISTSERV HPO 14.4 are: - LISTSERV startup is faster. - Web page rebuild is performed in the background and now gives precedence to incoming mail messages (in 14.3 only Web interface requests had precedence). This rebuild has been accelerated for sites with many lists. - Daily auto-delete reports and subscription renewals are generated in the background when TUNE_MANY_LISTS is set. General hardware tuning tips for sites with many lists: Your best improvement is to put enough RAM in the server and configure the operating system to cache files aggressively, so that all the list files end up being in the system file cache. For Windows and Linux, this happens automatically if there is enough RAM. Once LISTSERV has accessed all the list files at startup, all the data will be in RAM and immediately available. The faster the drive's access time (not transfer rate), the faster LISTSERV will be able to operate. This is regardless of whether or not you have a RAID. If the cost of putting all LISTSERV files on a faster drive is prohibitive, put LISTSERV's main directory on a fast drive and the archives on a slower, higher-capacity drive. Basically, the TUNE_MANY_LISTS parameter has been getting better and better with each new release, and more and more startup stuff is being done in the background. I would have to dig through my emails to find exactly when the Solaris bug that I mentioned earlier was found and killed, but if my memory serves me, it was part of the 14.4 changes. IIRC, the bug was that the background stuff was not being done in the background on Solaris. Or maybe I'm confused -- I'm going on memory and my memory is not all that good. My point is that maybe you should try all the performance improvements we've already put in LISTSERV over the last 3.5 years before asking for new ones. And I'm not asking you to "simply throw the latest release on top of a running production system and hope it works". Your L-Soft Sales rep can provide you with a test LAK to use on a non-production instance of LISTSERV for a reasonable testing period. Use a test server that is disconnected from the network (so you don't end up sending out emails), restore a backup of your production server, upgrade it to 14.4, add the TUNE_MANY_LISTS parameter to your site config, and see how fast it starts up. Note: don't base it on the first startup after the upgrade, because IIRC, one of those upgrades required some conversions on the first startup after upgrade, causing it to take a little longer; the second startup should go noticeably faster than your current 75 minutes. If it doesn't, add that DEBUG_TIME_ALL parameter to the site config of your test server and report the results to Eric. -- Francoise Becker What are your favorite LISTSERV(R) announcement lists? Submit nominations by December 1, 2005 for the LISTSERV Choice Awards Announcement Award http://www.lsoft.com/news/choiceawards.asp