rc7 is out! We’ve upgraded to Varnish 3.0.2, fixed bugs, and made improvements to make your cPanel WHM server run even more faster than litespeed! Head out to the varnish download page: http://www.unixy.net/varnish

In brief:

• Upgrade Varnish to 3.0.2
• Increase httpd hdr len for req/resp
• Increase session WS
• Add Varnish monitoring crontab job

rc8 will see two neat features. The first will is a Slashdot Survive URL opt-in list where if you were to receive enormous traffic, Varnish can shield your server by responding directly to those requests (completely bypassing Apache or any server-side processing). So serving a slashdot-like audience will require a small fixed amount of memory as opposed to an unpredictable amount of resources (and most likely a server crash). The second feature will deal with aggressive bots. This addition creates a shared memory store for bots so they sources pages from the same store and prevent server crashes due to aggressive bots.

There’s more in 1.4.5rc8 so stay tuned!

Enjoy!

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

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.