The post 3 Tips for Cloudfront Configuration appeared first on LoadStorm.

Add Behaviors

Modern websites aren’t uniform; every section of a website has different needs. Behaviors are a way to make the CDN distribution act specifically for different parts of your website. An example is adding a new behavior for the path “/login*” to use HTTPS Only.



The distribution will know that anywhere in your site that has that login path will serve only HTTPS (i.e. https://example.com/login/customer). The Default(*) behavior is then used last and applies to all other folders and files in your site. As a second example, you might want the “/products*” portion of your site to be quick and refresh consistently. This leads to the next tip we can employ in our distribution.

Use Custom TTL

Not only are websites not uniform, they are not created equal. In this case it is beneficial to use a Custom Time-to-Live (TTL) cache header for your distribution. TTL determines how long your distribution edge servers will wait before refreshing content from the origin servers. The TTL is measured in seconds not minutes. Some of the TTL values we used for testing Delivergood’s distribution were 600 (10 minutes) and 3600 (1 hour, below).



For your distribution though, it depends on how frequently you want your site to update. Does your site frequently push new content? Lower the Custom TTL. Is the site mostly the same content and used as a repository or mirror? Raise the Custom TTL. This setting coupled with behaviors lets you balance the distribution to match your site’s needs.

Change The Price Class

You might have already noticed this setting and it speaks for itself. Say you want your site to perform faster, but you don’t need it to be optimized globally. Perhaps your website is for a local business and you don’t need it to perform optimally for geographically distant visitors. If you want to save money, change your Price Class in the set up of your distribution to use the regions that are closest to the location of your web server rather than Best Performance (All Locations). Below is a snapshot of Amazon’s price class pricing:



Clearly some regions are more costly than others. Serving content from Japan is 67% more costly than the US, while South America is 108% more! An example might be if you have origin servers in North America. Your best choice would be the “Use Only US and Europe” price class to still serve content fast to those regions (but not as fast globally) for a cheaper price.

Employing these three tips are only a few ways to customize your CDN distribution. There are ways you can further tweak the CDN. You could add additional origin servers with different rules and locations, or set up an RTMP distribution for streaming media. If you work with CDNs yourself and know any additional tips, feel free to leave a comment!

The post 3 Tips for Cloudfront Configuration appeared first on LoadStorm.

The post Web Performance News for the Week of December 2, 2013 appeared first on LoadStorm.

Akamai Technologies Inc acquires DDOS company Prolexic

Akamai will acquire all of the outstanding equity of Prolexic in exchange for a net cash payment of about $370 million.  The transaction is expected to occur in the first half of 2014. Although Akamai already has a service to protect online companies from DDoS (distributed denial of service )attacks, CEO Tom Leighton informed everyone that Prolexic focused on protecting all manner of enterprise computing systems, such as corporate data centers.

“By joining forces with Prolexic, we intend to combine Akamai’s leading security and performance platform with Prolexic’s highly-regarded DDoS mitigation solutions for data center and enterprise applications protection. We believe that Prolexic’s solutions and team will help us achieve our goal of making the Internet fast, reliable, and secure.” said Leighton.

The deal will continue to grow Akamai’s Internet security business and extending their reach to customers’ data centers and non-web applications, such as e-mail and tools for staff to share digital files.

Federal Communication Commission Releases Its Own Mobile Performance Testing App

FCC has recently unveiled an app called FCC Speed Test App for Android smartphones which is available for free through Google Play. The app is a stepping stone towards evaluating the efficiency of mobile broadband network performance. Speed Test App is aimed at equipping consumers with information to allow them to make fact-based, informed decisions when choosing and evaluating their mobile providers.

Aggregated data collected from the app will continue to help the FCC in its future policy decision making.  The program is based on involving consumer volunteers, the Federal Trade Commission, wireless service providers, and others to produce accurate information on mobile broadband services.By extending to mobile services this will provide valuable information to the public, industry and policy makers on broadband networks across the nation.

Regarding concerns for the app, the FCC stated that consumer privacy is the top priority. The FCC Speed Test page stated,  “We used open, public meetings and worked with a diverse team of privacy experts, including federal partners, academia, and industry stakeholders, to develop our privacy policy and procedures.  Simply put, NO personal information or unique identifiers are collected, data is collected anonymously, and it may be further processed to ensure that consumer privacy is protected.”

New Survey Finds Website Performance a Top Business Priority

Conducted by TechValidate, Limelight Networks announced the results of a recent survey on how businesses are seeing web performance as a top business priority. Businesses are continuing to become more aware of the financial influence of high performance. With the awareness, online businesses are beginning to integrate performance testing into their development cycle. Below are some statistics announced from Limelight Networks.

Based on responses from over 230 Limelight Platform customers, the survey shows that 62% of companies view high performance delivery of content as one of their highest priorities for businesses today.

In terms of top challenges companies face:

• 39% of respondents cited the inability to deliver a consistent user experience across the globe as a top operational challenge.
• 37% cited slow application load times.
• 34% cited buffering of video content.

Unintended traffic spikes is also one of the challenges companies face. According to the survey about 46% of respondents said they experience unplanned traffic spikes at more than two times a year. Half of those companies expect this to happen many times a year.

By Identifying and monitoring the key drivers of their business. Companies perceive web performance as an necessary component for boosting profitability. 48% of customers surveyed stated that their primary reason for addressing the web performance challenge is to retain and grow the customer base, while 25% cited increasing visitor engagement with content as the primary driver.

The post Web Performance News for the Week of December 2, 2013 appeared first on LoadStorm.

The post How Busy is the CDN? appeared first on LoadStorm.

Do you want the CDN distribution to take almost all the work off of your main server or only some of it? How busy do you want to keep the CDN distribution? All of these questions determine how much time you will put in obtaining the most out of your Cloudfront distribution. For example, the more work you want the CDN to do, the more work you will end up doing configuring both the host and the distribution properly.

In order to test scalability both with and without a distribution, we will do a series of load tests.
We’ll first start with our control, this is what we get without a CDN distribution:

Load Test of Magento store with no CDN

For a medium-sized server, this isn’t a whole lot of users. As a developer, you must take a deep look at your requirements. This might be enough for a few, but for performance sake there are greater heights. The next two tests involve a CDN distribution.

In the CDN-to-Magento linking process, the team discovered two central methods in how we want our distribution implemented. The first is static content delivery. With static delivery, your distribution is just responsible for serving images, layout, CSS and even JavaScript. All other elements though, are sent from your origin server. In this case you can think of your distribution as being more “laid back”. It’s only responsible for sending simple content. This method is easiest to implement, even in Magento. All you have to do is link your distribution in the Magento settings and you’re good to go. Keep in mind though, the scalability isn’t as great…

Load test of Magento store using static content delivery

You could get scalability between 130% and 300% from what we have seen. This might be good enough in your case for that extra handful of users. Static content delivery can almost be thought of as a “set it and forget it” method; not much manual maintenance is involved.

The second method is dynamic content delivery. Technically it should be thought of as static & dynamic content delivery, because with this method, static delivery is also occurring. Your distribution is responsible for static content (i.e. images, CSS, JS) and it is responsible for PHP and HTML pages. If your site requires users to login, you will need to set up cookie forwarding for Cloudfront. If users are submitting content to the server, you must remember to use PUT, POST, and PATCH protocols. Not to mention, you will likely want to do some domain changing so your website still has an acceptable URL. You can already tell that dynamic content delivery is much more challenging, but the rewards…

Load test of Magento store using dynamic content delivery

…might be more than worth it. By having your userbase hit the distribution for almost everything, you can see scalability reaching anywhere from 1000% – 1500%! This is where you can truly get your money’s worth from the distribution without even having to move your origin server to something larger.

The preceding load tests were performed with the LoadStorm Load Testing Tool on DeliverGood’s Magento store, where a CDN distribution was setup in each of the three statuses: none, static, and dynamic delivery. Implementing Cloudfront to work with Magento ultimately goes one of two ways.
Static content delivery can give you that extra boost of scalability without sinking in all the time and effort.
Dynamic content delivery will give you much greater scalability at the cost of more time and effort.

At this point it is up to the developer. Would it be worth it to invest the time and maintenance into making dynamic content delivery functional? Or does sticking with static provide enough scalability for your purposes? This is where web developer prowess come into play.

The post How Busy is the CDN? appeared first on LoadStorm.

The post WebPerfLab – Impact of a CDN appeared first on LoadStorm.

Before we delve into the details of the results, we first need to explain what a Content Delivery Network is and how it works, so we can understand why these improvements were so dramatic.

How it works

A Content Delivery Network (CDN) is a system of distributed servers that takes advantage of server placement, caching, and DNS to deliver content quickly and efficiently. Rather than distributing all information from your main server (called the “origin server”), it uses a series of proxy caches (called “edge servers”) to get certain content to your users faster.

Put simply, CDNs work like this:

1. A user makes a request for a piece of content (e.g. photo.jpg). DNS directs the request to the nearest edge server.
2. If the edge server doesn’t have that content in its cache, or the content it does have is expired, the edge server makes a request to the origin server for the content.
3. The origin server returns the content to the edge server. The edge server then caches this fresh content.
4. Finally, the content is delivered to the end user from the edge server.

On subsequent requests for the same content, the process goes a little differently:

1. A user makes a request for a piece of content (e.g. photo.jpg). DNS directs the request to the nearest edge server.
2. The edge server has the content cached, so it delivers that content to the end user directly. No requests are made to the origin server.

This happens for ANY user that gets directed to this edge server. When one user makes the request, all subsequent users in that area will be drawing from the content that’s stored in the edge server cache. In this way, CDNs work like browser caches, but they are shared between multiple users.

This type of caching works best on “static content” or content that isn’t going to change very much. Content that is constantly expiring or changing won’t be stored in the edge server for very long, meaning it gives no benefit from being cached like this. Things like pictures, CSS documents, media files, and JavaScript files are all good candidates for CDN storage. HTML pages, on the other hand, are typically handled directly by the origin server because they must be dynamically built by the web application for each user.

As you can see, most requests are now being handled by the CDN, freeing up valuable resources within the origin server. As a result, the origin server can handle a greater number of users since each user is making significantly fewer requests to it.

You can read more about how CDNs work here.

How to Implement

Originally we were going to compare the efficiency of a bunch of CDNs paired with our website. This turned out to be a project for another time since applying a CDN to our website messes with DNS and that’s something we didn’t want to have to deal with. In the end, we only ended up testing one: Amazon Cloudfront. This was the one that made the most sense anyway, since LoadStorm is hosted through AWS and would therefore be the easiest to set up.

For a detailed look at how to set up a Cloudfront CDN and integrate it into WordPress using W3TC, click here.

Results

Overall, load time did not significantly decrease by attaching a CDN, only dropping by about 4.6%. However, increasing page speed isn’t exactly the function of a CDN. To truly see the impact the CDN has on our website, we must perform a load test!

In addition to the benchmarking tests we performed with WebPageTest, we also performed some initial benchmarking tests with LoadStorm, testing our website up to 5000 concurrent users.

At the time of benchmarking, we received our first timeout error at around 1,600 users. Not too bad, but we can do better.

Now let’s run the exact same test after enabling a CDN and see how well the website does.

Not a single error, and we reached 5,000 users with no complications. Since the CDN is now handling the bulk of the content requests, this takes a massive load off of the main servers. Five thousand is easily high enough to handle the amount of traffic LoadStorm’s website gets, and we could probably stop there if we wanted to…but let’s keep going.

Next, we’ll hammer it again with LoadStorm, this time going up to 25,000 users!

Unfortunately, we had to cut this one short. Due to some complications involving the LoadStorm website’s database being located on the same server as the LoadStorm application’s database, we accidentally came pretty close to crashing them both. Nevertheless, we found our breaking point: 7628 concurrent users. So the number of concurrent users we could handle before getting timeouts increased by 376%.

That’s to say nothing of what the CDN did to our maximum throughput and peak requests per second! Throughput peaked at 53,455 kB/s, which is over four times the benchmark’s value of 12,730 kB/s. Requests per second similarly quadrupled, going from 537 requests/s to 2,250 requests/s. All from making a single change. All from setting up a CDN.

Bottom Line

If you’re looking for an easy way to improve the scalability of your website, setting up a CDN is really the first thing you should do. It’s an quick way to dramatically increase the number of users your website can handle. This works by passing off most of the workload to the CDN, so most requests can be handled outside of the main server, freeing up resources to handle more users. Curious about how big an impact a CDN has or could have on your website? Try LoadStorm for free today and find out!

The post WebPerfLab – Impact of a CDN appeared first on LoadStorm.