Making Lyris List Manager Run Faster
This is a list of techniques we have found which can have an effect Lyris List Manager performance, and make it run faster.
Pack your mail queue databases
The incoming and outgoing mail queues in Lyris List Manager are saved in databases. Over time, these become large, and their performance slows
down. If you run the command "lyris dbfastpack" from the command line (from the Lyris List Manager directory) while the server is shut down, the incoming and outgoing mail queues will be rebuilt,
and all deleted space will be reclaimed.
Upgrade your databases
As Lyris List Manager creates and deletes items in its database, the data slowly becomes fragmented, and its tree-based indices become less "balanced",
meaning they become less efficient. This is the same problem that occurs with hard drives, called "hard disk fragmentation", that disk defragmenting tools fix. By running the command "lyris
dbupgrade" (from the Lyris List Manager directory) while the server is shut down, you will build all new tables, with all their data defragmented, and with perfectly balanced database indices. On
very large sites, (100,000+ members) we find that this case significantly improve performance. You will especially want to do this after importing a large number of members, because Lyris List
Manager mailing uses the members' table extensively. Defragmented and balanced member database will significantly improve Lyris List Manager' mailing speed.
Install a DNS Server on the machine running Lyris List Manager
Instead of having Lyris List Manager use other machines as its DNS server, install a DNS server on the same
machine that is running Lyris List Manager. If possible, make it a full DNS server, that can look up its own records, instead of just caching the records from another DNS server. Once you install a
DNS server, specify the address "127.0.0.1" as the TCP/IP address of the Lyris List Manager server. At the very least, use a DNS server on your local network, not one at your ISP's, over your main
Internet connection.
Do not receive Error Mail Notifications
If you are set as a list administrator, have a large mailing list (10,000+) and set yourself to receive error mail notifications, you
will be asking Lyris List Manager to forward every copy of Error mail on to you. This increases the amount of work Lyris List Manager needs to do when it receives error mail.
Do not disable error mail handling
By default, Lyris List Manager will keep track of error mail, and a point each day that a user bounces mail. After 5 points, a user is put on
hold. Do not turn this mechanism off for large lists, as you will be telling Lyris List Manager to send mail to all your email addresses, even those that are invalid. We find that about 10% of a
mailing list's addresses go bad every month. Not letting Lyris List Manager clean up the list of members for you adds to the load.
Purchase the "Plus" version of Lyris List Manager.
The non-plus versions of Lyris List Manager are limited to 50 concurrent mail sending threads. The plus version has no limit.
On a typical machine, Lyris List Manager can achieve 300 simultaneous send sessions. If you are unsure as to whether the "plus" version can help you, contact us at sales@yourcompany.com for a free
time-dated "plus" serial number, which will allow you to see the "plus" version in action.
Make sure you have enough memory
Many sites are out of memory, and running on virtual memory (hard disk swapfile). If you are running Unix, and use the Apache web server, make
sure that you do not have more Apache processes than you have memory. The most important measurement on Windows and Unix systems is the total memory that your processes are using. If your processes
are using more memory than you have physical memory, then you are low on memory, and likely using your swapfile heavily.
Notify Held Members Infrequently
On large lists, Lyris List Manager will be identifying many members with email problems and putting them on hold. If you use the hold notify
feature, where Lyris List Manager sends a notification message to held members, do so infrequently, such as on a 4 or 5 day interval. Sending held notifications every night tends to use a lot of CPU
power just to try to send mail to people who probably are not receiving it anyway.
|