Lyris User's Guide
[previous] [next] [contents]
Making Lyris Run Faster
Table of Contents
Introduction
Lyris Email Commands
Web Interface for Users
Server Administrator
Site Administrator
List Administrator
Other Topics
Add-On Packages
Installing and Upgrading
Appendix
Frequently Asked Questions
DocBots
Running Lyris
Email
Lyris Administration
Web Browsers
Usenet Newsgroups
International
Other FAQ issues
Making Lyris Run Faster
How does searching work?
How can I get the MultiView version of Lyris?
Can Lyris work on an Intranet?
Mailing List Features
Perl/Lyris Toolkit
Unix Administration
Up & Coming

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 sales@shelby.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.

Other pages which link to this page:
  • Other FAQ issues
  • Page 535 of 556