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.

Don’t pass on the opportunity to get awarded two owned licenses ($278 value) and a feature on our blog! Submit your artwork for either the cPanel Varnish Plugin or the DirectAdmin Varnish Plugin to isaig@unixy.net.

We’ve just upgraded our cPanel Varnish plugin from Varnish 2.1.4 to 3.0.0. To kick off the new release I’ve performed a before and after benchmark to get a feel of the performance boost. The results are outstanding! I spun up one VPS, loaded it with our plugin version 1.4.5rc1, and performed a benchmark using ab. Then loaded the same VPS with plugin version 1.4.5rc2 to perform the same benchmark. Keep in mind that these results are relative and that’s what I’m focusing on here.

Here are the VPS specs (typical of medium sized virtual machine):

• 4-core Opteron Magny-Cours (vcpu allocation)
• 1gb ddr3
• thread_pools@2 and thread_pool_min@200
• Custom VCL (same across both experiments)

Here are the results from the first run against 2.1.4 (full ab results):

Concurrency Level:      1600
Time taken for tests:   1.514520 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      3764888 bytes
HTML transferred:       60078 bytes
Requests per second:    6602.75 [#/sec] (mean)
Time per request:       242.323 [ms] (mean)
Time per request:       0.151 [ms] (mean, across all concurrent requests)
Transfer rate:          2427.17 [Kbytes/sec] received

Here are the results from the first run against 3.0.0 (full ab results):

Concurrency Level:      1600
Time taken for tests:   1.371934 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4001094 bytes
HTML transferred:       60318 bytes
Requests per second:    7288.98 [#/sec] (mean)
Time per request:       219.509 [ms] (mean)
Time per request:       0.137 [ms] (mean, across all concurrent requests)
Transfer rate:          2847.80 [Kbytes/sec] received

It’s important to note that the resources allocated to both experiments are the same and the goal is to stress test 2.1.4 and 3.0.0. Release 3.0.0 is over 600 requests per second or 10% faster than 2.1.4, which is great! Congratulations to the Varnish Cache dev team for job well done :)

That’s all folks!

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!

Varnish, the state-of-the-art HTTP accelerator, v3.0 (up from v2.1.x) is scheduled to be released in a few hours. The folks at Varnish Cache have worked tirelessly to get the 3.0 release out of the door. Congratulations on work well done!

Here are some of the major changes and additions:

Plugin Support – VMOD

VMOD is to Varnish as loadable module is to a kernel.  The new Varnish provides a programmable interface that enables expanding the VCL (Varnish Configuration Language). This VMOD feature includes relatively advanced concepts like functions, pointers, and data types. I think this is the most complex piece to go in v3.0.

Streaming Support

This is a long awaited feature. Up until today, Varnish broke HTTP streaming slowing down adoption of the software in the multimedia space and content delivery. This feature makes it possible to accelerate HTTP streaming. Streaming is controlled via the boolean beresp.do_stream.

Compression and Decompression Support – ESI Twist

Having Varnish do compression and decompression adds flexibility and performance in one shot. The compression level is controllable via the variable gzip_level. With this feature, you can now compress what is not compressed should there be a legacy issue; Decompress on the fly for ESI and compress; Modify the compression level; Offload compression to a host of machines. And the list goes on…

Improved Documentation

The new Varnish boasts improved documentation that is “in much better shape than before.” This is excellent news because,  in my opinion, this used to be THE pain point.

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!

We’ve compiled a list of six Unix/Linux tools that are cool and useful. From checking the weather via your terminal to having a sysadmin walk you through a difficult task. Interestingly, most of these tools were released decades ago! Read on…

kibitz

kibitz is a terminal tool that can be used by a mentor to assist his or her apprentice. It essentially makes what is normally one private terminal session visible to both parties providing bi-directional interactivity. The mentor can then walk the apprentice through various tasks and howtos. A typical session looks like the following to the mentor:

Whatever commands or text that the mentor or the apprentice types is seen on the other end. It looks like this to the apprentice:

tload

tload is a neat tool that displays the load average on the terminal in a form of character drawings. It gives an interesting visual of the system load (/proc/loadavg) over time – time being an adjustable parameter. Without further ado, here’s a screen shot of tload in action:

catchsegv

catchsegv helps one diagnose programs that segfault. If you’re dealing with an app that segfaults frequently, start it up with catchsegv and watch it produce a snapshot of CPU registers, memory maps, and backtrace at the time of the segfault! Here’s a snapshot of it in action:

dislocate

For those of you who are familiar with the program screen, dislocate is its grandfather.It’s neat tool that allows one to detach programs from the pseudo terminal and reattach to them whenever needed. This is tool for those with slow or unstable terminal sessions that are prone to disconnect.

tac

tac is a command line tool that reads a file in reverse order. It’s ideal for log sifting tasks where one’s interest is in grep’ing the most recent entries.

# cat /var/log/sip

Target 1… DONE
Target 2… DONE
Target 3… DONE
# tac /var/log/sip
Target 3… DONE
Target 2… DONE
Target 1… DONE

weather

weather is an expect-based program that runs from the terminal and grabs weather information from rainmaker.wunderground.com. Wunderground runs a public weather service on port 3000. weather leverages this service to pull weather data by city and displays it on the terminal. Here’s a sample run:

$ weather HOU

<snip>

Enter 3-letter city code: HOU

Weather Conditions at 12:53 PM CST on 24 Dec 2010 for Houston Intercontinental, TX.

Temp(F)    Humidity(%)    Wind(mph)    Pressure(in)    Weather

========================================================================

63          70%         ESE at 10       30.07      Overcast

Forecast for Houston, TX

406 am CST Fri Dec 24 2010

.Today…Mostly cloudy with a 30 percent chance of showers. Highs

in the upper 60s. Southeast winds 10 to 15 mph.

.Tonight…Showers likely and isolated thunderstorms. Lows in the

mid 40s. Northeast winds 5 to 10 mph in the evening becoming

north and increasing to 15 to 20 mph after midnight. Chance of

rain 70 percent in the evening decreasing to 60 percent after

<snip>

That’s all folks! I hope you enjoyed this entry.

Hitting the news today is a concerted DDoS attack effort directed at Amazon as vendetta for its role in ousting Wikileaks.org off its hosting cloud. The attackers are so determined they are asking everybody on the planet to download this program called Low Orbit Ion Canon (LOIC) and launch it against Amazon. In this post, we’rel sharing a flaw in the program that we think can be used to mitigate the attack, to an extent.

The program is written in C# with its source code available for anyone to inspect it and modify it. In fact one has to compile the code in order to use the tool. The flaw in this program is apparent in the source code of the program. In file HTTPFlooder.cs at line 63, the payload of the request is constructed like this:

byte[] buf = System.Text.Encoding.ASCII.GetBytes(String.Format(“GET {0} HTTP/1.0{1}{1}{1}”, Subsite, Environment.NewLine));

This is at the heart of the attack. It consists of a flood of HTTP GET request using protocol 1.0. These kind of attacks are difficult to defend against because the request looks very similar to a legitimate request coming from a typical Web user. The request flows through several layers in the OSI stack and exhausts a lot of computing resources – all the way to the 7th logical layer of the OSI model.

But notice that this request is missing the host header (Example: Host: www.amazon.com). This fact alone can help with filtering the attack. One could ensure that all requests contain this important header either in the Web server configuration (imperfect solution). The optimal solution, however, is to introduce specialized ASIC deep packet inspection devices with proper signatures to filter out the attack.

That’s all folks!