Litespeed users on cPanel WHM servers are realizing the benefits of running Varnish Cache in front of Litespeed to improve performance. While we (UNIXy) don’t officially provide support to subscribers running the cPanel Varnish Plugin with Litespeed, it does work with only a few extra manual steps. Keep in mind that we support this configuration for our fully managed VPS, dedicated server, and cluster clients. If you are a current client and need this configured, please open a ticket request.

In this post, I’m going to list the steps required to pair the cPanel Varnish Plugin with Litespeed on cPanel WHM servers. These few procedures apply to a blank cPanel installation (no Litespeed, no Varnish Plugin). The order below is important so don’t skip!

• 1. Configure your Apache / PHP with the desired options and extentions. Let EasyApache finish the build.
• 2. Install Litespeed using the command line installer with the port offset at 2000 (default).
• 3. From WHM -> Litespeed -> Build Matching PHP binaries. Let the Litespeed builder complete before proceeding.
• 4. Proceed with installing the cPanel Varnish Plugin. Let it complete.
• 5. Set the Litespeed Port offset to zero in Admin Console.
• 6. In Admin Console, Configuration -> Server -> General Settings -> Use Client IP in header -> Yes. Restart Litespeed.

About UNIXY

UNIXY is a long-time Varnish Cache user and evangelist. They have been offering Varnish acceleration to their clients for more than three years. They have released the first cPanel Varnish plugin as well as spun a new startup, Fastlayer, the on-demand HTTP accelerator for the cloud.

That’s all folks! I hope you find this useful.

A default installation of FastCGI on cPanel server is dangerously simple. It’s dangerous because one cPanel account (or one vhost) is capable of crashing down a whole server if, say, traffic were to spike up. It’s also simple because it won’t allow complex scripts to run cleanly. In brief, it’s absolutely not ready for production as-is. In this post, I’ll go over what it takes to configure FastCGI on a cPanel node properly.

Did you know?

UNIXy is a fully managed server and cluster provider. What this means is we don’t expect you to know anything about servers or server management. The good news is it doesn’t cost you extra to have us manage your UNIXy server! Get in touch with us here to get the ball rolling!

Before you continue reading, be sure to have FastCGI up and running as the PHP handler on your cPanel server. The installation of FastCGI is covered in the online cPanel documentation. From here on now, I’ll assume you’re ready to add the settings for FastCGI.

The following is a list of settings that you need to add to /etc/httpd/conf/php.conf upon switching to FastCGI:

MaxRequestsPerProcess 1000
FcgidMaxProcesses 200
FcgidProcessLifeTime 7200
MaxProcessCount 500
FcgidIOTimeout 400
FcgidIdleTimeout 600
FcgidIdleScanInterval 90
FcgidBusyTimeout 300
FcgidBusyScanInterval 80
ErrorScanInterval 3
ZombieScanInterval 3
DefaultMinClassProcessCount 0
DefaultMaxClassProcessCount 3
MaxRequestLen 20468982

You’re more likely to adjust the settings in bold above. DefaultMinClassProcessCount 0 instructs FastCGI to keep zero PHP processes running for user when traffic is idle (cPanel account user) . On the other hand, DefaultMaxClassProcessCount 3 tells FastCGI to never allow more than 3 PHP processes running at a time. This settings prevents one users from crashing the server were they to receive a lot of traffic.

So go ahead and copy/paste the above into your httpd.conf and restart Apache (service httpd restart). You’re good to go now! For greater performance, be sure to check out our Varnish plugin. Whether you’re running suPHP, FastCGI, or even DSO (mod_php), Varnish will make your website load much faster.

That’s all folks!

We haven’t seen anyone explain the meaning of following Varnish error message found in the logs of your server in detail. So here it is for the curious:

Dec  5 12:31:31 server varnishd[28446]: Child (28447) not responding to CLI, killing it.
Dec  5 12:31:59 server varnishd[28446]: Child (28447) died signal=3
Dec  5 12:32:03 server varnishd[28446]: child (22431) Started
Dec  5 12:32:04 server varnishd[28446]: Child (22431) said Child starts
Dec  5 12:32:04 server varnishd[28446]: Child (22431) said SMF.s0 mmap'ed 268435456 bytes of 268435456

The message above comes from the Varnish Manager. The Manager is the Varnish process (there are two Varnish processes) that monitors and manages the Varnish caching process. Here it’s telling us that caching process has stopped responding back with a PONG to its PING. A ping from the Manager to the Cache process with its response look like this and happens every 3 seconds (at least in this configuration):

    0 CLI          - Rd ping
    0 CLI          - Wr 200 19 PONG 1323181633 1.0
    0 CLI          - Rd ping
    0 CLI          - Wr 200 19 PONG 1323181636 1.0

So going back to the error message, the Manager is telling us that it hasn’t received a “PONG” back from the Cache process in a while. A “while” is controlled by the variable cli_timeout which has a default of 10 seconds in Varnish 3.x and 20 seconds in Varnish 2.x. So the Manager waits for about 10 seconds before it fires a UNIX kill using signal SIGQUIT (signal=3). Next the Manager starts the child back up again afresh.

You may be asking yourself: why is the Cache process not responding? There are a few of possible causes. Either the cache process is deadlocked (deep code issue) or the server is under a very heavy disk IO load / memory shortage. So how do you determine which category you fall under? I recommend checking the load average and memory utilization levels on your server using Sysstat tools.

Did you know?

UNIXy is a fully managed server and cluster provider. What this means is we don’t expect you to know anything about servers or server management. The good news is it doesn’t cost you extra to have us manage your UNIXy server! Get in touch with us here to get the ball rolling!

 

That’s all folks.

The Linux kernel is very smart and can leverage CPU features and instruction sets to bring down power consumption especially on a server. So one of the logical things to do when power savings are needed is to turn off CPU cores. To confirm that this is indeed what’s happening on your system, you could hot-plug these cores and bring them online in this fashion:

echo 1 > /sys/devices/system/cpu/cpu4/online
echo 1 > /sys/devices/system/cpu/cpu5/online

You can then verify that additional CPU cores have been brought up. You can also take them offline if needed:

echo 0 > /sys/devices/system/cpu/cpu4/online
echo 0 > /sys/devices/system/cpu/cpu5/online

The above will lead to this message being displayed in /var/log/messages (turned off core # 23):

[1132050.457980] CPU 23 is now offline
[1132065.819054] Booting Node 2 Processor 23 APIC 0x2b

That’s all folks!

In this article, we are going to cover one trick that is used in Web social circles to weather short-lived traffic storms. In most cases, servers collapse due to the server-side processing that needs to occur to produce the HTML that sent to the browser. Whether the server-side script is written in PHP, Ruby, Python, or Perl with a database back-end, this trick is effective and does the job. It gives you much needed breathing room to plan ahead should the spike continue for weeks.

In the case of a WordPress blog, say for example http://blog.unixy.net/2010/03/bargain-bin-fully-managed-dedicated-servers/, upon visiting the Bargain Bin blog link, the server where blog.unixy.net is hosted will need to perform several tasks to render the page and send it the HTML results back. The tasks consist of running PHP scripts, querying the database, and retrieving files from disk amongst other tasks. Under extended peak traffic periods, these tasks when repeated continuously overwhelm the server and cause it to slow down and sometimes to crash.

So, if all the server does is produce the HTML code and send it back to the browser, we might as well just generate the HTML ourselves once and instruct the server to send it instead, bypassing all of that heavy processing. So without further delay, here is how one can generate the HTML:

GET http://blog.unixy.net/2010/03/bargain-bin-fully-managed-dedicated-servers/ &> /tmp/bargain-bin.html

The GET command comes as part of the libwww-perl package, which is available for both Linux and Windows. Now that we obtained the HTML, we are going to add a .htaccess rule to temporarily redirect all requests to the article /2010/03/bargain-bin-fully-managed-dedicated-servers to bargain-bin.html. Be sure to move the file my-page-dugg.html to the HTML root folder. Here is the .htaccess rule:

RewriteEngine on

Redirect 302 /2010/03/bargain-bin-fully-managed-dedicated-servers /bargain-bin.html

Be sure to put the above rules before the WordPress rules. The 302 rule means that it is a temporary redirect. This is so it is SEO friendly and does not break your links as search engines see them.

I hope you enjoyed this short article. The above instructions can work for about any CMS or portal. Keep in mind that should you be one of our customers, we will be very happy to complete this workaround on your server for no extra charge.

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.