Does Compression Increase Speeds When Using a CDN?

CloudFlare automatically compresses content before serving it over their network, regardless of the origin server’s compression compatibility. When internet pipes were small, gzipping content reduced the overhead for html, css, and javascript often between 60 and 90 percent of the original size, at a sacrifice of CPU time.

With CloudFlare and similar CDN services, it is possible to offload the gzipping of content onto the middleman servers saving you CPU time before requests are served. In theory, if the pipes between your server and CloudFlare are large enough, the extra packets between your server can be sent in less time than it would take to compress the content. To test this, I setup two m4.large EC2 instances and made a couple hundred http requests between the two. Although not a perfectly representative test page for the internet, I used the hmtl of the wordpress.com site for the test object.

Machine Details:
Amazon Linux AMI 2015.09.0 x86_64 HVM GP2
Size: m4.large, 2 vCPU, 8 GB Memory
Disk: Provisioned IOPs SSD
Network Speed: “Medium”
Requests Served via Apache 2.4 with mod_deflate

CloudFlare “Pro” Account

First, to check if there was any possible gain room for improvement, 200 requests at each test level were made from one m4.large AMI box to another m4.large AMI box. The pages were not decompressed after they were received.

AMI -> AMI

No Compression % Change
13.784 KB 100% Original Size
0.001252285 seconds
Level 1 Deflate Compression % Change
5.747 KB 41.7% Original Size
0.0016389 seconds   31% Longer Load Time
Level 6 Deflate Compression (Default) % Change
5.203 KB 37.7% Original Size
0.00178892 seconds   43% Longer Load Time
Level 9 Deflate Compression % Change
5.202 KB  37.7% Original Size
0.0017924 seconds  43% Longer Load Time

Downloading files between these two boxes (vai Apache) clocked in at 69.5MB/s – bandwidth in this instance has very little effect on the download time of a page, thereby reducing mod_deflate’s usefulness. We can see because of the CPU usage, mod_deflate actually adds at least 31 percent MORE loading time for each request. Level 1 compression manages to reduce the document 41.7% of the original size, but our fat pipes don’t care about the reduction in size.

With the “No Compression” model showing promise for delivering documents faster as long as the pipe is big enough, the next step was to determine how long these requests took when they were routed through CloudFlare’s network. This test involved the traffic flowing from one m4.large instance to CloudFlare and back to another m4.large instance. Despite routing this traffic through CloudFlare, the throughput between the two m4 instances is still 69.5MB/s.

AMI -> CloudFlare -> AMI

No Compression % Change
5.173 KB 37.5% Original Size
0.00639284 seconds
Level 1 Deflate Compression % Change
5.166 KB  37.5% Original Size
0.00673343 seconds  5.3% Longer Load Time
Level 6 Deflate Compression (Default) % Change
5.159 KB  37.4% Original Size
0.007528945 seconds  17.7% Longer Load Time
Level 9 Deflate Compression

5.174 KB  37.5% Original Size
0.013901415 seconds  117% Longer Load Time

Level 1 Deflate Compression comes out as the clear winner if you’re trying to keep your bandwidth bill low. Origin server bandwidth requirements are reduced almost 60% while only adding 5% to the load time. If you have unmetered bandwidth and a fat pipe, you would be best avoiding origin server compression at all.

Theory: CloudFlare needs to decompress and parse all content going through its servers for the optimization processes it provides. When content is compressed, it takes additional CPU time on the origin server and on CloudFlare’s network before the content can be decompressed,  parsed, and compressed again with CloudFlare’s algorithms.

Suggestion: Add “DeflateCompressionLevel 1” to your httpd.conf file.

0_README_BEFORE_DELETING_VIRTFS

VIRTFS or VirtFS is a linux system process used to help manage the files on your system.

From linux-kvm.org:

VirtFS is a new paravirtualized filesystem interface designed for improving passthrough technologies in the KVM environment. It is based on the VirtIO framework and uses the 9P protocol.
Why use it?

  • virtualization aware filesystem
  • offers paravirtualized system services
  • simple passthrough for directories from host to guest
  • Backward/forward compatibility issues

Virtual Machine Manager integration since version 0.9.1

The /home/virtfs directory contains critical operating system files. If you
remove /home/virtfs, or any directories under /home/virtfs, you will cause
irreparable damage to your operating system. Do not remove /home/virtfs, or any
directories under /home/virtfs, unless you have tested, up-to-date backups.

You should ignore any disk usage warnings you receive that are associated with
the /home/virtfs directory!

For more information about the /home/virtfs directory, visit the documentation
at http://go.cpanel.net/virtfsdoc

iPhone Lightning to 3.5 mm Headphone Jack

As iPhones become smaller and smaller, we will eventually loose the auxiliary port to the Lightning and MFi standard. This change will enable Apple to require headphone vendors to comply to their MFi standard and pay licensing fees on the lightning adapters.

Hopefully, Apple will also produce lightning to 3.5 mm headphone converters to allow people to use their old headphones. In the worst case, people can use bluetooth to aux converters to avoid being bound to apple licensed products.

Facebook introduces Privacy Basics

In light of recent events, such as the Kramer et al study, Facebook is rolling out “Privacy Basics”. These are going to be the TL;DR of the ToS and Privacy Policy of facebook, putting in layman’s terms what facebook really intends to do with your information. As facebook states, these policies will “Help you understand how Facebook Works and How to Control Your Information”. It is not yet known if Facebook will allow users to enhance their privacy or decrease Facebook’s own data access with these new policies, but it is certainly a step in the right direction.

Facebook’s “Feeling Shqiptar”

albenian

Facebook recently added “feeling shqiptar” [Shqip(ë)tar (plural: Shqip(ë)tarët, feminine: Shqip(ë)tare)] to the list of how you might be feeling while updating your facebook status.
This is an interesting addition as it means to be feeling Albanian (from the South-Central European country of Albania, bordering Greece).

Facebook seems to feel like feeling albenian is a good thing, as the icon is a smiling face 🙂

Feeling Shqiptar

Are you feeling Shqiptar today?

Apple iPower

Apple has recently filed for certification with the IECEE for a new device called “Apple iPower”
From the certification request, it appears the device has an input of 20 volts (the equivalent of Mac Laptop charger output), and an output of 5 and 12 volts.
5 Volts is USB standard voltage, but it isn’t yet known as to what the 12 volts 2 amps could be used for.
apple-ipower

Apple Watch Pulse Oximeter

According to recent documents filed with the IECEE, the apple watch’s heartbeat measuring technology is going to be based off of the Pulse Oximeter technology commonly used in medical equipment. It also appears from this filing that the watch may be compatible with android devices, however the wording is quite ambiguous.

Snapshot of the IECEE Filing below:
apple-watch-pulse-oximeter