Making Lyris Run Faster
This is a list of techniques we have found which can have an effect Lyris performance, and make it run faster.
Pack your mail queue databases
The incoming and outgoing mail queues in Lyris 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 directory) while the Lyris 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 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 directory) while the Lyris 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 mailing uses the members table
extensively, and defragmented & balanced member database will significantly improve Lyris' mailing speed.
Install a DNS Server on the machine running Lyris
Instead of having Lyris use other machines as its DNS server, install a DNS server on the same machine that is running Lyris.
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 server. At the very least, use a DNS server on your local network, and 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 to forward every copy of Error mail on to you. This increases the amount of work Lyris needs to do when it receives error mail.
Do not disable error mail handling
By default, Lyris 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 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 clean up the list of members for you adds to the load.
Purchase the "Plus" version of Lyris.
The non-plus versions of Lyris are limited to 50 concurrent mail sending threads. The plus version has no limit. On a typical machine,
Lyris can achieve 300 simultaneous send sessions. If you are unsure as to whether the "plus" version can help you, contact us at email@example.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 will be identifying many members with email problems and putting them on hold. If you use the hold notify feature, where
Lyris 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.