SpamAssassin (SA) is a program used for email spam filtering based on content matching rules. The Bayesian classifier that comes with SpamAssassin can be trained to recognize spam (or ham) based on a few sample emails. SA breaks the spam email into tokens or group of tokens for processing. Once SA is fed a large enough sample of spam tokens, it will start marking spam email with a higher score and thus block the spam. The same applies to ham except that the score is lower.

The sa-learn utility that comes with SA is the tool used to train SA on what is spam or what is ham. It is crucial to feed sa-learn with either spam or ham and not both at the same time. While sa-learn has several command line switches for various options, one only needs a couple of flags to have it process emails. The following two command lines are all one needs to get the job done:

To train SA on spam, run the following from the server in question:

sa-learn --showdots --mbox --spam spam-file

To train SA on ham, run the following from the server in question:

sa-learn --showdots --mbox --ham ham-file

spam-file and ham-file are files in Mailbox format. So what if your inbox is of type Maildir? There is an extra step involved in converting the Maildir format to a Mailbox. The utility mb2md can do the job seamlessly. Once the Maildir is converted to Mailbox, simply replace ‘spam-file’ in the command line above with the resulting Mailbox file from the conversion.

That’s all folks! We hope this was useful.

Spamd is one the highest resource consumer on a cPanel server. It allocates a lot of memory from the get-go and holds on to it throughout. There is a way to limit the number of spamd processes that are spawned. On a cPanel server, which is what this guide covers, there is a configuration file called /etc/cpspamd.conf with the following lines:

maxspare=1
maxchildren=3

For a leaner server. we recommend dropping maxchildren to 1 and maxspare to 1. This will save a good hundred of megs of memory. Don’t forget to restart exim for these changes to take effect.

I hope this tip is useful. That’s all folks!

IOPS stands for Input and Output Per Second. It is essentially a value that describes the raw capacity of a data storage system. It sets an expectation for performance. Some storage systems are said to be capable 120 IOPS and others 340 IOPS or much more. The number of IOPS, for most disk systems, represents a count of a mix of data reads (Output) and writes (Input) per second. By that number, one can judge how fast and responsive a disk system can be. The numbers can be obtained by performing sequential or random operations on the disk system. The best representation is random operations since it reflects a real-life usage pattern.

Disk system manufacturers obtain IOPS numbers via benchmarking. There are tools that measure disk throughput and capacity by performing several read and write tests. For example, Iometer is a tool that can measure disk system performance and produce the IOPS value for such system. One needs to be aware of the fact that some manufacturers provide the IOPS based on cached read and write tests. The latter is a best case scenario test and does not reflect real-life usage.

So what happens when a system reaches the IOPS threshold number? I did use the word “reach” because in theory the disk system will almost never exceed the advertised IOPS. Back to the question, when the system reaches the IOPS threshold, it starts queuing requests. A busy queue generally indicates a bottleneck.

How often have you found yourself with a bottlenecked 2TB disk choking after barely putting a few files? Disk size capacity has no bearing on its IOPS capacity. A 2TB disk could have the same IOPS capacity as a 250GB disk! So when does one need to upgrade the disk system or the configuration at least? We shall post a new entry on this blog with the instructions.

That’s all folks!

In this post, we shall go through the steps required to optimize a WordPress blog. If you are a current customer of UNIXy (http://www.unixy.net), do know that we are happy to implement these changes for your blog free of charge. We are a fully managed provider so do take advantage of it. Contact us today!

There are times when hardware upgrades are not feasible due to either budgetary limits or time constraints. We understand that a WordPress blog could be hosted on a shared platform or dedicated server (VPS included) so we have written this post with that in mind. The first 5 steps can be completed in a shared environment where access to global configuration files is not permitted by the provider. All 10 steps can be completed on a dedicated server or Virtual Private Server (VPS).

1. WP Supercache

WP Supercache is a WordPress plugin that once installed alleviates some of the burdens on the server. Essentially, it takes every visited PHP page, generates the HTML content, and stores it on disk for subsequent visits. This is called PHP caching. The performance gain is noticeable. Not only does it speed up requests and improves responsiveness but it also leads to less resource utilization on the server. To install WP Supercache, follow this link:

http://ocaoimh.ie/wp-super-cache/

2. Turn Autosave Off

The WP global variable AUTOSAVE_INTERVAL controls the how often WordPress auto saves posts as they are edited. For example, while editing or writing a new posts, WP could be automatically saving tens of copies of your posts to the main WordPress table. Each time such automatic save process kicks off the main posts table is locked in order to be updated, which prevents visitors from briefly accessing your blog. It also causes the load average to spike up. One could either increase the autosave interval or completely disable the functionality. To increase the interval to X number of seconds (the higher the better), do it as such inside the wp-config.php file:

define('AUTOSAVE_INTERVAL', 2200); // 2200 second autosave interval

To disable the autosave feature completely, create a simple plugin file and enable via wp-admin:

3. Disable Revisioning

This feature saves several revisions of the same post into the database. It clutters the posts table and ends up bloating indexes unecessarily. It’s best to disable this feature altogether if you don’t need it. Add this line to your wp-config.php to disable this feature:

define('WP_POST_REVISIONS', false);

No further action is needed.

4. Disable Non-Cacheable SQL Plugins

While it is a good idea to disable as many unneeded plugins as possible, it’s not always practical to do. But this step requires that you go through the code of each plugin and locate SQL queries that use the MySQL RAND() function. Because MySQL does not cache queries that use the random number generator function RAND(), there is a performance penalty associated with such plugins. For example, Random Post plugin uses RAND() in its select SQL, which forces the SQL to run against the database time and time again. You can locate the PHP scripts that use the RAND() function inside your plugin folder using this command:

grep -i "rand()" -r wp-content/plugins

Once located, one could either disable such plugin or replace MySQL RAND() with a PHP rand function. This way the PHP random function will be cached. The randomization will, however, not work as intended. The good news is that perceived functionality will not be much impacted.

5. Convert MyISAM Tables to InnoDB

The InnoDB engine is superior. There is no reason to run MyISAM anymore. Here is a Bash script that will convert all tables, that can be converted, to InnoDB. If you do not have access to a script shell, you can accomplish the same using phpMyAdmin or other MySQL management tools. Be sure to take a backup of the WordPress database before running this script. Also, be sure to define a maintenance window for this change as the alter locks up tables temporarily making the blog inaccessible:

#!/bin/bash
DBNAME="database";
DBUSER="user";
DBPASS="pass";

for t in $(mysql -u$DBUSER -p$DBPASS --batch --column-names=false -e "show tables" $DBNAME);
do
echo "Converting table $t";
mysql -u$DBUSER -p$DBPASS -e "alter table ${t} type=InnoDB" $DBNAME;
echo "Repair table $t";
mysql -u$DBUSER -p$DBPASS -e "repair table ${t}" $DBNAME;
done

Remember that those who are hosting their WordPress blog on a shared provider's server will not be able to proceed with the rest of the instructions. The following instructions require root-level access to the server and a technical understanding of systems.

Varnish is an excellent Web accelerator that can be made to proxy requests in and out of a cluster of somewhat more fully fledged Web servers like Apache or Litespeed. It has some great features like its compiled language, called VCL, and C-like programming API.

Large vBulletin deployments tend to be heavy on CPU and memory due to PHP script processing. For a large vBulletin forum, we recommend a cluster of 5 physical servers with three of those running Xen virtualization. One of those servers will be dedicated to the MySQL master database. Three to be setup as “headless” PHP nodes and Varnish load balancing and failover. And finally one as the NFS file store. The three headless servers need to run Varnish in their own VM and Litespeed or Apache in their own VM similarly.

The varnish backend director functionality makes it ideal to balance incoming traffic across all PHP headless nodes. It makes the configuration scalable and plug and play especially when needing to scale out within hours. The challenge in this setup is in making Varnish work correctly with vBulletin. Otherwise, session problems will occur.

We have a lot to share on this implementation so keep checking this blog as we will post it all. In the next installment, we’ll go through our deployment of a large vBulletin forum for a customer. In the mean time, feel free to get in touch should you have a question or comment. If you are interested in us helping you accelerate your server, we have a page explaining the different technologies we deploy on our clients’ dedicated servers. Read up here: http://www.unixy.net/accelerate-your-server

Update: we are offering a Varnish configuration for vBulletin (3 & 4) for a one-time fee. We can also configure it free of charge should you decide to rent your fully managed dedicated server from UNIXY (http://www.unixy.net). Please contact us today to get your forum running with a blazing fast speed!

That’s all folks!