Before I delve into the meat of this post, Internet access is critical to what we (UNIXy) do. We are a fully managed server and cluster provider. The quality of service we offer is critical to our success. So it’s only natural we concert a continuous effort to improve the service on all fronts. Being fully staffed and accessible to our clients 24/7 is imperative. We must be available within short notice (e.g. < 10 minutes) at all times around the clock.
So Internet at 10000 feet means we don’t have to deal with temporary staffing shortages due to unplanned trips. But most importantly it means service quality remains consistent. Internet at 10k is even more important as we expand to different parts of the country and Europe. But in such a rough, high altitude environment there are so many things that can go wrong with the Wifi service. And it has. Southwest Airlines’ Wifi service is too unreliable to consider.
I’ll ask the pilot to reboot the system to see if it helps
On the other hand, Virgin America’s Wifi system powered by Gogo LLC is very reliable. So this is the airline we’ve been booking with lately. While domestic flights have us covered, transatlantic connectivity has yet to materialize. 30000 feet is the new frontier. I’m confident that some day we’ll be back here reporting about how good it is to support our clients at 30k feet.
Cheers
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!
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.
Here are some great Black Friday deals on software and servers!
—————————————————–
Deal # 1
cPanel Varnish Plugin Owned – 50% OFF
Coupon: BF50%OFF
Order Now
—————————————————–
Deal # 2
DirectAdmin Varnish Plugin Owned – 50% OFF
Coupon: BF50%OFF
Order Now
—————————————————–
Deal # 3
$1 First Month Dedicated Server
Quad Core Xeon W3520 8-vcore Xeon 2.67GHz
12GB DDR3 RAM
2x1TB SATA (RAID-1)
2TB Bandwidth
UNIXy Truly Fully Managed
First Month: $1
Subsequent Months: $249/Mo
Order Now: Email sales@unixy.net
—————————————————–
Deal # 4
$1 First Month VPS Server
This special applies to all VPS servers
UNIXy Truly Fully Managed
First Month: $1
Subsequent Months: See price page: http://www.unixy.net/vps-hosting
Order Now: Email sales@unixy.net
—————————————————–
That’s all folks!
We have big news about Black Friday! SO BIG, in fact that we’re not waiting until Friday to tell everyone. We have decided to make all dedicated and VPS servers available for $1 for the first month on Black Friday only! Get ready to contact sales@unixy.net to get full details on this deal.
**This deal is available for new orders only. This special cannot be applied to upgrades or used for current service.
