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
|
