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!
Varnish PHP bindings are useful for folks that need to manage Varnish from PHP. A palpable version of the extension code has finally been released. Keep in mind that the release is early beta. Nonetheless, the milestone is significant. So, what can one accomplish with the API?
Here’s a list of the most important function calls:
stop start banUrl - Purge URL ban - Free form purge command isRunning - Boolean setPort - Set the admin port getSnapshot - Retrieve statistics snapshots getLine - Retrieve log entry
We are keeping a close eye on the development of the PHP Varnish extension and will update this page.
UNIXY is a long-time Varnish Cache user and evangelist. They have been offering Varnish acceleration to their VPS, dedicated server, and cluster 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 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):
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!
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!
Here is a post detailing an interesting setup of Web servers made to go against one another in real time. This could prove to be entertaining for benchmarkers or perhaps decisive for those who need an ultimate killer proof that their favorite Web server can kick some behind.
Definition of server Web benchmarking (according to Wikipedia):
It is the process of estimating a web server performance in order to find if the server can serve sufficiently high workload [sic].
In this article, I’m going to butcher this definition and depart from the tradition – a tad bit. Here are a some interesting questions that come to mind: What if the end goal is not to obtain measurements but to take a knock-out approach? What if we were to put three Web servers all against one another is a threesome match? Is the outcome of this death match meaningful? How do we select the winner? Switching gears forward a bit, could this death match approach be maliciously leveraged in a botnet situation?
Let’s dive right into the code! But first, let’s discuss the logic necessary to trigger, enable, and maintain a match until death occurs or an apparent draw ensues. The death match in this post is triggered via a single GET action from a regular browser and can be sent to any Web server (or all) that is participating in the fight. The trigger calls a server-side python script called bench.py, which in turns forks a threaded python program, called benchlet.py, that perpetuates the match. Each Web server participating in the death match receives a GET request and then resonates another similar multi-threaded request against the other Web server. This back and forth exchange escalates the match further and further…until death occurs.
The following video illustrates the trigger action and an excerpt from the match.
The mechanism used to trigger and maintain the match is written in python but it could be just about any server-side processing language like PHP or Ruby.
About UNIXy
UNIXy is a fully managed server and cluster services providers with a focus on high traffic Web sites. Server and cluster management is offered courtesy at not extra costs to their clients. 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:
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.
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.
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…
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.
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!
UNIXY is pleased to announce the release of Fastlayer, the HTTP accelerator for the cloud. For more information, visit fastlayer.com
The Fastlayer concept sprung to life from the need to provide HTTP acceleration and caching to a growing base of clients running disparate platforms. The software is modeled to work as a dedicated appliance platform with multi-tenant capabilities. Fastlayer provides the software and the client allocates the hardware (or virtual machine). But allow me backtrack a bit and start from the beginning.
Several years ago, UNIXy, a fully managed hosting services firm, started offering Varnish Cache to clients as demand for such software grew immensely. A few years later, they built a limited set of tools to automate installation and support. UNIXy supports a large set of control panels. In fact, the firm supports all third party software. Support became even more challenging at that point.
Then comes the cPanel Varnish Plugin, which offered installation, management, and integration with the well known Web hosting control panel cPanel WHM. It was followed a few months later by the DirectAdmin Varnish Plugin; ad nauseam.
Fastlayer to the rescue
Here we are today having built Fastlayer. Third party application support is no longer a concern for clients that need acceleration and caching. Fastlayer acts as an acceleration layer and can host hundreds of host names (virtual hosts). It’s manageable and API-enabled so it’s programmable.
How to obtain Fastlayer
We are currently undergoing beta testing of the product with a diverse set of cloud operators, Web service providers, and individuals. Fastlayer is always looking to reach out to more folks and organizations so be sure to contact us.
