Speeding up Magento using CDN a (Content delivery network) In simple English.

You have a Magento site but you just can’t get it to run fast enough?

You’ve looked around the web and tried everything but you’re still unhappy?

You’ve probably tweaked your .htaccess file.
Tried multi threading.
Added full page cache and a host of other alternatives from Magento Connect.
You’ve optimised your MySql database.
You’ve run Cron jobs to clear your log files everyday.
You’ve optimised all your images.
You’ve minfied your js and css
You’ve tried sprites on your home page.

Your on Shared,  VPN or Dedicated Hosting.

Now here’s how you get upto a 300% increase in speed. Without spending a fortune.

Because Magento is memory hungry your web servers resources will be pushed to the limit especially if you’re running on a shared environment like a vpn or worse a shared hosting account and you have reasonable traffic.

Now imagine the html being loaded from your webserver and your css, js and Image files all coming from a seperate server or actually a network of seperate servers dependent on which server is closest to the geographical point your customer is situated in.

Your page load speed will increase as the CDN network takes the load off the main webserver. So if your customer is in America and your main server is in the UK your html will come from the UK (origin) whilst all the images, .js and .css files will be serverd from America (pop).

If your customer is in the UK then your customer will get the html from your local server (origin) and the images, .js and .css from a seperate UK based server (pop).

with over 50 edge servers located around the globe and multiple UK servers we can deliver your content much quicker than you can on your own from a single server.

If you already have hosting we can still setup a CDN for you.

Chances are that we can set the whole thing up,  Hosting and CDN  for marginally more than you’re paying now.

The cost is dependent on the network bandwidth you require to deliver your content.

The advantages

Super fast delivery of content anywhere in the world.

In our tests we gained on average a 300% increase in speed which makes for a faster experience for your customer.

SEO Advantages

If you increase the speed of your pageload to your customers you may well see an increase in sales, some companies have seen a 40% increase in sales after setting up a CDN.

Pageload Speed is a factor that Google use when ranking your website.

For more details call 0161 536 0334.

 

For those who are more technically minded here’s the technology.

 

 

MAGENTO HOSTING

Best Practices for Optimum Performance Magento
Table Of Contents

Introduction 3

Testing Criteria 4

Terms and Definitions 4

Benchmarking Tools 5

Software Tools & Plug-ins 5

Benchmarking Parameters 6

Benchmarking Hardware Architecture 7

Software and Benchmarking Configurations 9

Software Versions 9

Anatomy of a Siege Test – Raw Stress Testing 9

Anatomy of a Gatling Test – User Modeling Stress Testing 9

The Test Cases 11

Test 1: File Synchronization – NFS vs. Local File System 11

Test 1: Results 11

Test 2: Apache vs. Nginx 12

Test 2: Results 13

Test 3: MySQL versus Percona 15

Test 3: Results 15

Optimized Magento Site versus Optimized Magento Site with Varnish & Turpentine 17

Test 4: Best configuration versus Varnish & Turpentine 17

Result Observations and Optimal Configurations 20

The Importance of the Magento Enterprise Full Page Cache 20

The Magento DEFAULT_LIFETIME 21

Response Times 23

Understanding Magento Caching 25

Magento Backend Cache 25

Additional improvements 26

Magento Full Page Cache 26

Magento Session Cache 26

PHP opcode cache 26

Conclusion and Additional Performance Recommendations 27

Appendix A: System Configurations 28

Appendix B: Benchmarking Configurations 28

Gatling Tool 28

Siege 28

 

 

 

 

Introduction

Magento is a very popular and powerful eCommerce platform with very demanding resource requirements. While it will run out of the box using default configuration settings, extensive post-installation configuration is recommended to achieve optimal site performance (especially for high volume sites).

This paper is meant as a guide for you to ensure you’re getting the most out of your Magento installation by using best practices developed through real-world experience, where we’ve been working with the platform since 2007. We outline the differences between default and/or popular available configurations, listing the benefits and drawbacks of these changes, and what we’ve found to be optimal for scaling Magento. These different configurations are extensively benchmarked showing the benefits between configuration op­tions and the maximum performance available from each chosen setting.

Using the configuration information contained within this paper, a load-balanced web server cluster run­ning Magento Enterprise is able to process over 550 transactions per second (equating to more than 47 million transactions per day). Further performance is obtained by utilizing the Turpentine plug-in (with the Varnish reverse proxy), which can provide up to 6,940 transactions per second (over 600 million transactions per day).

All system-level configuration files are provided at the end of this document and show the exact system settings and application configuration parameters used. All benchmark application test configurations are also provided to show exactly how each test was run and how, if necessary, each can be reproduced.

Testing Criteria

Terms and Definitions

The following terminology can at times be confusing in relation to the actual process occurring. The terms used throughout this white paper are defined as follows:

Buyer

A client who completes an order.

Client

A user and (more specifically) the browser and/or browser mechanism used by the user. It does not, for the pur­poses of this paper, always denote the customer of an eCommerce transaction.

Order

The successful completion of the checkout process within Magento.

Orders per second (also denoted as O/s or Orders/sec)

The number of orders processed during one second.

Request

Any HTTP communication sent by a client (browser, etc.) to a Magento server. This includes requests sent over HTTPS and is synonymous with an HTTP request.

Requests per second (also denoted as R/s or Requests/sec)

The amount of requests being sent to a Magento server during one second. This metric does not take into ac­count how many requests result in a successful response from the server (that is, a complete transaction).

Response

Any HTTP communication sent by a Magento server to a client. This includes those requests sent over HTTPS and is synonymous with an HTTP response. Bear in mind, responses are not synonymous with a web page. A single web page may have hundreds of individual responses associated with it, including images, HTML pages, style sheets, JavaScript and other static or dynamic content.

Transaction

The combination of a successful request and response.

Transactions per second (also denoted as T/s or Transactions/sec)

The number of transactions completed during one second.

User

Synonymous with a client (for the purposes of this paper).

Visitor

A client who simply browses a website and does not complete an order.

Benchmarking Tools

Two benchmarking tools, Siege and the Gatling Stress Tool, were used extensively in testing.

Siege is an open-source, HTTP-based benchmarking utility which excels in obtaining the raw load capabilities of a website. It can stress a web address (or a list of web addresses) with various concurrency levels. It is an ideal load tester for determining the peak transactions per second for an individual client and the specific response times experienced.

The Gatling Stress Tool is also an open-source tool and is used to benchmark interactive features of a site. It can be configured to perform complex multi-step actions such as adding items to a cart and performing a checkout in the same manner a human client would. Because of this, Gatling is excellent for testing the number of orders per second a site is capable of processing under various load situations.

Software Tools & Plug-ins

The following software and other tools are mentioned throughout this white paper and are important enough to the performance of Magento to merit a brief explanation:

Alternative PHP Cache (APC)

An opcode cache for PHP. When PHP processes a script it has to digest the PHP code into an intermediate format that can be run by the PHP interpreter. Much of the work done on this digestion can be re-used in future exe­cution of the script by saving some metadata about the script in the form of opcodes. This can speed up each PHP script’s processing time by saving some time associated with compilation. APC can also be used as a mem­ory-based caching system to cache key/value pairs in memory much like memcached (see description below), though it suffers from the same deficiencies.

memcached

A memory-based caching system. By using a simple key/value system to store data in a table in memory, access to the data in memcached is very fast. However, a disadvantage to its implementation is no targeting is used when flushing the cache. A cache flush is an all-or-nothing operation which can be non-optimal if the bulk of the cache is not dirty. memcached uses a threaded model, allowing it to process requests in parallel efficiently.

PHP FastCGI Process Manager (PHP-FPM)

This allows PHP processes to be pooled and reserved on a per-user basis. Traditional execution of the PHP inter­preter involved starting up an entirely new process to handle a given request via a mechanism like CGI. PHP-FPM allows for having many PHP processes running, which greatly enhances performance. Beyond this, PHP-FPM has the added security benefit of allowing the PHP processes themselves to be assigned to a given user (which allows user segmentation not available when using traditional Apache+mod_php).

Redis

A memory-based caching system. It uses a simple key/value system to store data in a table in memory (much like memcached). Redis ads the advantage of tags to the storage model, which allows an application using Redis to target any dirty sections of the cache during flush operations. Its current implementation is single-threaded, meaning it can only process requests serially (that is, one at a time) for each instance of Redis.

Varnish

A web application accelerator (also known as a caching HTTP reverse proxy). Varnish can be used to drastically speed up web applications with minimal performance degradation when configured correctly. Varnish stores the assembled web pages (or parts of web pages) in memory and relieves the application itself from having to perform any work when a cache hit is realized. The Turpentine Magento extension makes use of Varnish to greatly enhance the performance of Magento Enterprise. By default, Varnish does not work well with Magen­to because it doesn’t cache requests with cookies. Magento sends a frontend cookie with every request caus­ing a (near) zero hit-rate for Varnish’s cache. Turpentine configures Varnish to work with Magento and modifies Magento’s behaviour to significantly improve the cache hit rate.

Benchmarking Parameters

Since every Magento store is different and the amount of data housed within one can make a big difference when it comes to performance, we’ve standardized on the following Magento configuration for this white paper:

Magento version: Enterprise 1.12.0.2

Stores: 1

SKU count: 100,000

Categories: 10

Subcategories: 40

Some standard configurations are set throughout the testing as they are best practices for Magento. These con­figurations are:

• Two level Magento backend cache is enabled. First level is set for memcached.
• Second level is set to Redis with the CM_Cache plug-in.
• The two-level backend cache patch is applied.
• Sessions are stored in a dedicated memcached instance.
• The Magento compiler is enabled.
• The Magento full page cache is enabled (with the storage set to a second Redis instance).
• The APC PHP opcode cache is used.

Benchmarking Hardware Architecture

A MCE-SIP-200 server cluster was used for benchmarking in all of our test runs. This cluster consists of a firewall, two web application servers, a single database server, a dedicated load balancer, and a dedicated file server (which also shares a role as a Magento application caching server).

Web Application Server 1 Web Application Server 2 Master Database Server Dedicated Cluster File Server and Caching Server Dedicated Load Balancer Dedicated Managed Firewall Incoming requests Outgoing Tra_c Internal File and Cache Tra_c Internal Database Tra_c Internet Redundant Internal 10GbE Network

Diagram 1: MCE-SIP-200 Cluster Architecture

The MCE-SIP-200 cluster used for testing consisted of the following hardware:

Web Application Servers:

Dell R420

2x Intel Xeon 8 Core CPUs E5-2450 @ 2.10GHz

24GB RAM

2x 147GB 15K SAS RAID-1 (H710)

Database Server:

Dell R420

2x Intel Xeon 6 Core CPUs E5-2420 @ 1.90GHz

24GB Ram

4x 147GB 15K SAS RAID-10 (H710)

File Server / Caching Server:

Dell R420

2x Intel Xeon 6 Core CPUs E5-2420 @ 1.90GHz

24GB Ram

4x 147GB 15K SAS RAID-10 (H710)

Load Balancer:

Dell R420

2x Intel Xeon 6 Core CPUs E5-2420 @ 1.90GHz

16GB Ram

2x 73GB 15K SAS RAID-1 (H710)

Benchmarking Server (from which all tests were run):

Dell R420

2x Intel Xeon 6 Core CPUs E5-2450 @ 2.10GHz

24GB Ram

4x 73GB 15K SAS RAID-10 (H710)

The testing server was placed across a gigabit network which was connected from within the a data cen­ter in Dearborn, MI to the public interfaces of the testing cluster.

Software and Benchmarking Configurations

Software Versions

The following software versions were installed on all servers in the MCE-SIP-200 cluster used for testing:

CentOS 6.3 (x86_64)	Percona 5.5.28
PHP 5.3.17	MySQL 5.5.29-1
APC 3.1.9-5	memcached 3.0.6-3
Redis 2.4.10-1	Apache 2.2.23 (pre-fork MPM)
Nginx 1.0.15-3	PHP53-fpm-5.3.17-2
Varnish 3.0.2	Magento-Turpentine 0.3.1