Objective

The objective of this document is to provide detailed information on “How to Improve Magento Performance”

Scope

We will cover following topics which contributes to overall Magento performance optimization.

• Architecture Design

• Apache performance tuning

• MySQL Database performance tuning

• PHP performance tuning includes PHP accelerator i.e APC

• Configuring Magento with Varnish cache

• Configuring Magento with Memcached cache

• Magento Configuration Changes for performance tuning

Architecture

One of the important aspect of Magento Performance tuning is to design the architecture based on no. of concurrent users, no. of anonymous users, Hardware configuration of the servers like Memory, CPU, HDD etc.

      Important points to consider:

• Separate Admin node (Backend) is recommended if performance is the key requirement as this will reduce the load of admin functions like Magento cron jobs from frontend servers which requires high memory and CPU.

• Separate DB servers are recommended for READ and WRITE operations which will ditribute DB activities on 2 separate nodes and hence will help in improving performance.

• Frontend caching like Varnish can be configured with Magento to cache and serve static contents and hence put lesser load on Apache which in turn helps to improve site performance to great extent (Detailed configuration will be explained later in this document).

• Backend caching like Memcached can be configured with Magento to cache objects/ strings from results of database calls (Detailed configuration will be explained later in this document).

• Choose High performance/ Light weight Load-balancer like Nginx or HAproxy if you are planning for a software load balancer

• Above diagram is just a sample architecture, this can vary based on needs and requirements of the organization.

Apache performance tuning

Once architecture is finalized and considering we are using Apache as a web server, we will now concentrate on how to tune Apache Web server

Following points to be considered:

1. Load only required Apache modules

Default apache configuration file (/etc/httpd/conf/httpd.conf) will have all apache modules loaded by default however for standard magento installation, we need only following modules enabled in Apache. Disable all other modules.

LoadModule expires_module modules/mod_expires.so - generates content expiration and cache control headers

LoadModule deflate_module modules/mod_deflate.so - compresses content before it is delivered to the client

LoadModule mime_module modules/mod_mime.so - associates the requested file with its type and behavior

LoadModule dir_module modules/mod_dir.so - Provides for "trailing slash" redirects and serving directory index files

LoadModule rewrite_module modules/mod_rewrite.so - Provides a rule-based rewriting engine to rewrite requested URLs on the fly

LoadModule log_config_module modules/mod_log_config.so - Logging of requests made to the server

LoadModule alias_module modules/mod_alias.so - Provides for mapping different parts of the host filesystem in the document tree and for URL redirection

LoadModule autoindex_module modules/mod_autoindex.so - Generates Directory Indexes

              LoadModule setenvif_module modules/mod_setenvif.so - Allows the setting of environment variables based on characteristics of the request

                  Note: Above list is derived from standard practices, It will depend upon individual scenario and accordingly modules can be loaded and unloaded.

2. Disable DNS Lookup

Make sure HostnameLookups is set to Off as this option logs the name of clients instead of IP address. If you enable this, each client request will result in at lease one lookup request to the nameserver and this will add additional latency in the response time

                  Recommended Configuration:

                  HostnameLookups Off

3. Configure AllowOverride

When this directive is set to None, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem.

When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files. These additional file system lookups add to the latency. If .htaccess is required for a particular directory, then enable it only for that particular directory

                  Recommended Configuration (Assuming Document Root is /opt/magento):

                  <Directory "/opt/magento/">

                  AllowOverride All

                 </Directory>

4. MPM(Multi-Processing Modules) Configuration

The MPMs change the basic functionality of the web server. They do this by modifying how apache listens to the network, accepts and handles requests.

Widely used Apache MPMs are Prefork and Worker

Prefork MPM implements a non-threaded, pre-forking web server that handles requests in a manner similar to Apache 1.3. It is appropriate for sites that need to avoid threading for compatibility with non-thread-safe libraries such as mod_php.

A single control process is responsible for launching child processes which listen for connections and serve them when they arrive. Apache always tries to maintain several spare or idle server processes, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new child processes to be forked before their requests can be served

Worker MPM implements a hybrid multi-process multi-threaded server. By using threads to serve requests, it is able to serve a large number of requests with less system resources than a process-based server. Yet it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads

A single control process (the parent) is responsible for launching child processes. Each child process creates a fixed number of server threads as specified in the ThreadsPerChild directive, as well as a listener thread which listens for connections and passes them to a server thread for processing when they arrive

Note: Magento recommends to use Prefork MPM as it is a thread-safe MPM

Prefork Configuration

                    MaxClients:

The MaxClients sets the limit on maximum simultaneous requests that can be supported by the server; no more than this number of child processes are spawned. It shouldn't be set too low; otherwise, an ever-increasing number of connections are deferred to the queue and eventually time-out while the server resources are left unused. Setting this too high, on the other hand, will cause the server to start swapping which will cause the response time to degrade drastically. The appropriate value for MaxClients can be calculated as:

MaxClients = Total RAM dedicated to the web server / Max child process size

The child process size for serving static file is about 2-3M. For dynamic content such as PHP, it may be around 15M. The RSS column in "ps -ylC httpd --sort:rss" shows non-swapped physical memory usage by Apache processes in kiloBytes.

Increase ServerLimit to set MaxClients above 256.

                    MinSpareServers, MaxSpareServers, and StartServers:

MaxSpareServers and MinSpareServers determine how many child processes to keep active while waiting for requests. If the MinSpareServers is too low and a bunch of requests come in, Apache will have to spawn additional child processes to serve the requests. Creating child processes is relatively expensive. If the server is busy creating child processes, it won't be able to serve the client requests immediately. MaxSpareServers shouldn't be set too high: too many child processes will consume resources unnecessarily.

Tune MinSpareServers and MaxSpareServers so that Apache need not spawn more than 4 child processes per second (Apache can spawn a maximum of 32 child processes per second). When more than 4 children are spawned per second, a message will be logged in the ErrorLog.

The StartServers directive sets the number of child server processes created on startup. Apache will continue creating child processes until the MinSpareServers setting is reached. This doesn't have much effect on performance if the server isn't restarted frequently. If there are lots of requests and Apache is restarted frequently, set this to a relatively high value.

                    MaxRequestsPerChild:

The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. It's set to 0 by default, the child process will never expire. It is appropriate to set this to a value of few thousands. This can help prevent memory leakage, since the process dies after serving a certain number of requests. Don't set this too low, since creating new processes does have overhead.

Recommended Configuration: For Single Magento Instance with 250 concurrent logged-in users with Hardware having 8 CPUs and 16 GB RAM):

<IfModule prefork.c>

StartServers 20

MinSpareServers 10

MaxSpareServers 40

ServerLimit 600

MaxClients 600

MaxRequestsPerChild 4000

</IfModule>

Note: Above mentioned settings may vary based on System configuration and Code

5. KeepAlive

The KeepAlive directive allows multiple requests to be sent over the same TCP connection. This is particularly useful while serving HTML pages with lot of images. If KeepAlive is set to Off, then for each images, a separate TCP connection has to be made. Overhead due to establishing TCP connection can be eliminated by turning On KeepAlive.

KeepAliveTimeout determines how long to wait for the next request. Set this to a low value, perhaps between two to five seconds. If it is set too high, child processed are tied up waiting for the client when they could be used for serving new clients.

Recommended Configuration:

KeepAlive On

KeepAliveTimeout 3

6. Compression

HTTP compression is completely specified in HTTP/1.1. The server uses either the gzip or the deflate encoding method to the response payload before it is sent to the client. Client then decompresses the payload. There is no need to install any additional software on the client side since all major browsers support these methods. Using compression will save bandwidth and improve response time.

HTTP Compression can be enabled in Apache using the mod_deflate module. Payload is compressed only if the browser requests compression, otherwise uncompressed content is served. A compression-aware browser inform the server that it prefer compressed content through the HTTP request header - "Accept-Encoding: gzip,deflate". Then the server responds with compressed payload and the response header set to "Content-Encoding: gzip".

Recommended Configuration (Assuming Document Root is /opt/magento):

<Directory "/opt/magento/">

SetOutputFilter DEFLATE

<IfModule mod_deflate.c>

SetOutputFilter DEFLATE

AddOutputFilterByType DEFLATE text/plain

AddOutputFilterByType DEFLATE text/html

AddOutputFilterByType DEFLATE text/xml

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE application/xml

AddOutputFilterByType DEFLATE application/xhtml+xml

AddOutputFilterByType DEFLATE application/rss+xml

AddOutputFilterByType DEFLATE application/javascript

AddOutputFilterByType DEFLATE application/x-javascript

</IfModule>

</Directory>

7. Caching

In caching, a copy of the data is stored at the client or in a proxy server so that it need not be retrieved frequently from the server. This will save bandwidth, decrease load on the server, and reduce latency. Cache control is done through HTTP headers. In Apache, this can be accomplished through mod_expires and modules. There is also server side caching, in which the most frequently-accessed content is stored in memory so that it can be served fast. The module mod_cache can be used for server side caching.

Recommended Configuration (mod_expires):

<ifmodule mod_expires.c>

<filesmatch "\.(css|js|gif|jpg|png|jpeg|ico|pdf)$">

ExpiresActive on

ExpiresDefault "access plus 1 year"

</filesmatch>

</ifmodule>

Note: Above settings will cache static contents with mentioned file types in client browsers for period of 1 year. These settings may also vary based on individual requirements. This will also help in improving Yslow ratings.

Recommended Configuration (mod_cache):

<IfModule mod_mem_cache.c>

CacheEnable mem /

MCacheSize 262144

MCacheMaxObjectCount 1000

MCacheMinObjectSize 1

MCacheMaxObjectSize 2048

</IfModule>

Note: We need to enable mod_cache module in case we want to configure server side caching. All size is in KBytes. We can also cache contents on disk (instead of Memory). Refer link http://httpd.apache.org/docs/2.2/mod/mod_cache.html

MySQL Performance Tuning

Recommended Configuration (For server with 24 GB RAM – These settings might vary based on server configuration)

Cache Configuration

thread-cache-size = 16

No. of threads the server should cache for reuse. When a client disconnects, the client's threads are put in the cache if there are fewer than thread-cache-size threads there. Requests for threads are satisfied by reusing threads taken from the cache if possible, and only when the cache is empty is a new thread created. This variable can be increased to improve performance if you have a lot of new connections

table-open-cache = 4096

The number of open tables for all threads. Increasing this value increases the number of file descriptors that mysqld requires. You can check whether you need to increase the table cache by checking the Opened_tables status variable. If the value of Opened_tables is large and you do not use FLUSH TABLES often (which just forces all tables to be closed and reopened), then you should increase the value of the table_open_cache variable.

table-definition-cache = 2048

The number of table definitions that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables. The table definition cache takes less space and does not use file descriptors, unlike the normal table cache

query-cache-size = 128M

The amount of memory allocated for caching query results. The default value is 0, which disables the query cache. The permissible values are multiples of 1024; other values are rounded down to the nearest multiple.

query-cache-limit = 2M

Do not cache results that are larger than this number of bytes.

Buffer Configuration

sort-buffer-size = 8M

Each session that needs to do a sort allocates a buffer of this size. sort_buffer_size is not specific to any storage engine and applies in a general manner for optimization

read-buffer-size = 2M

Each thread that does a sequential scan allocates a buffer of this size for each table it scans. If you do many sequential scans, you might want to increase this value

read-rnd-buffer-size = 16M

When reading rows in sorted order following a key-sorting operation, the rows are read through this buffer to avoid disk seeks. Setting the variable to a large value can improve ORDER BY performance by a lot. However, this is a buffer allocated for each client, so you should not set the global variable to a large value

join-buffer-size = 16M

The minimum size of the buffer that is used for plain index scans, range index scans, and joins that do not use indexes and thus perform full table scans. Normally, the best way to get fast joins is to add indexes. Increase the value of join_buffer_size to get a faster full join when adding indexes is not possible.

Temporary table configuration

tmp-table-size = 128M (The maximum size of internal in-memory temporary tables.)

max-heap-table-size = 128M (This variable sets the maximum size to which user-ceated memory tables are permitted to grow)

InnoDB Configuration

innodb-buffer-pool-size = 10G

The size of the memory buffer InnoDB uses to cache data and indexes of its tables. The larger you set this value, the less disk I/O is needed to access data in tables. On a dedicated database server, you may set this to up to 80% of the machine physical memory size.

innodb-log-file-size = 256M

The size of each log file in a log group. The combined size of log files must be less than 4GB. The larger the value, the less checkpoint flush activity is needed in the buffer pool, saving disk I/O and hence improves performance. But larger log files also mean that recovery is slower in case of a crash.

innodb-log-buffer-size = 8M

The size of the buffer that InnoDB uses to write to the log files on disk. A large log buffer enables large transactions to run without a need to write the log to disk before the transactions commit. Thus, if you have big transactions, making the log buffer larger saves disk I/O.

PHP performance tuning

Php.ini Configuration

Follwing configuration must be enabled in php.ini file for improving PHP Performance

php_flag zlib.output_compression on – Enable compression for PHP Files

php_value memory_limit 512M – Allocate specific amount of memory to PHP, this will be based on system configuration and available memory on the server

realpath_cache_size=5M - Determines the size of the realpath cache to be used by PHP. This value should be increased on systems where PHP opens many files to reflect the quantity of the file operations performed.

realpath_cache_ttl=86400 - Duration of time, in seconds for which to cache realpath information for a given file or directory. For systems with rarely changing files, consider increasing this value.

APC (Alternative PHP Cache) Configuration

APC is a bytecode cache for PHP which provides a shared memory storage for application data

Install APC module for PHP with command yum install php-pecl-apc (Make sure either remi or webtatic repository for Centos/ Redhat is enabled on server)

Enable PHP APC module and configure /etc/php.d/apc.ini with below settings:

extension=apc.so

apc.enabled=1

apc.shm_size=512M

apc.num_files_hint=10000

apc.user_entries_hint=10000

apc.max_file_size=10M

apc.stat=1

Configuring Magento with Varnish cache

Varnish is an open source, high performance http accelerator that sits in front of a web stack and caches pages. This caching layer is very configurable and can be used for both static and dynamic content. Varnish can improve the performance of Magento store without requiring any code changes.

    Important Points:

1. Varnish can be installed on same server where web server (Apache/ Nginx) is installed, however in such case since varnish will listen on port 80, we need to change default port for web server i.e. Other than 80

2. If you are having more than one web server, varnish can be installed on each web server

Installing Varnish (For Redhat/ Centos)

#rpm --nosignature -ivh http://repo.varnish-cache.org/redhat

#yum install varnish

Install Once Varnish is installed, you will get varnish configuration file i.e. /etc/varnish/default.vcl and varnish daemon file i.e. /etc/sysconfig/varnish. Both of these files needs to be configured as per requirement

Install Varnish module for Magento

Magento has varnish module i.e. "PageCache powered by Varnish", which helps improving peformance of Magento store. Once varnis is installed, you need to install this module

Installation steps (Through Magento Admin Server)

1. Download extension key for community edition from http://www.magentocommerce.com/magento-connect/pagecache-powered-by-varnish.html

2. Go to Magento Admin Node --> System --> Magento Connect --> Magento Connect Manager. Login with admin credentials and under Install New Extension --> paste extension key (downloaded from step1) and click on Install

3. Once module is installed you will get an option to configure this module. Login Magento Admin node --> Go to System --> Configuration --> Advanced --> System --> On the Right hand side, under "Page Cache powered by Varnish Settings" provide details for Varnish server(s), Port.

On the same settings page, you will also get an option to bypass specific url/ keywords from varnish (Disable caching routes) so that pages having these URLs will never get cached. These includes but not limited to checkout/ customer/ paypal/ catalogsearch etc.

4. Once this configuration is completed, you need to replace original varnish configuration i.e. /etc/varnish/default.vcl with VCL file bundled with the PageCache module for your version of Varnish (2 or 3) located at <magento_root_directory>/app/code/community/Phoenix/VarnishCache/etc/default*.vcl)

5. Restart Varnish server and Apache web server

Note: Make sure step 4 is followed as it is very important to keep default.vcl file provided by this module

Once PageCache module is installed, we now need to configure varnish. Varnish Configuration has 2 components i.e. Daemon file and Configuration file

Varnish daemon file - /etc/sysconfig/varnish

NFILES=131072

MEMLOCK=82000

RELOAD_VCL=1

VARNISH_VCL_CONF=/etc/varnish/default.vcl

VARNISH_LISTEN_PORT=80

# Change this as per requirement

VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1

# Change this as per requirement

VARNISH_ADMIN_LISTEN_PORT=6082

# Change this as per requirement

VARNISH_SECRET_FILE=/etc/varnish/secret

VARNISH_MIN_THREADS=50

VARNISH_MAX_THREADS=1000

VARNISH_THREAD_TIMEOUT=120

VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin

# Change this as per requirement

VARNISH_STORAGE_SIZE=1G

# Change this as per requirement

VARNISH_STORAGE="file,,$ {VARNISH_STORAGE_SIZE}"

VARNISH_TTL=120

DAEMON_OPTS="-a :$ {VARNISH_LISTEN_PORT} \

-f \

-T :$ {VARNISH_ADMIN_LISTEN_PORT} \

-t \

-w ,$ {VARNISH_MAX_THREADS},$ {VARNISH_THREAD_TIMEOUT} \

-u varnish -g varnish \

-S \

-s "

Varnish configuration file - /etc/varnish/default.vcl

# Default backend definition. Set this to point to your content (web) server.

backend default {

.host = "127.0.0.1";

.port = "6081"; # We will configure apache to listen to port 6081

sub vcl_recv {

# To forward client's original IP address

if (req.http.x-forwarded-for) {

set req.http.X-Forwarded-For = req.http.X-Forwarded-For;

}

if (req.request != "GET" &&

req.request != "HEAD" &&

req.request != "PUT" &&

req.request != "POST" &&

req.request != "TRACE" &&

req.request != "OPTIONS" &&

req.request != "DELETE") {

return (pipe);

}

if (req.http.Accept-Encoding) {

# # parse accept encoding rulesets to normalize

if (req.http.Accept-Encoding ~ "gzip") {

set req.http.Accept-Encoding = "gzip";

} elsif (req.http.Accept-Encoding ~ "deflate") {

set req.http.Accept-Encoding = "deflate";

} else {

remove req.http.Accept-Encoding; # unkown algorithm

}

}

# Magento deals only with GET and HEAD Requests

if (req.request != "GET" && req.request != "HEAD") {

return (pass);

}

# static files are always cacheable. remove SSL flag and cookie

if (req.url ~ "^/(media|js|skin)/.*\.(png|jpg|jpeg|gif|css|js|swf|ico)$") {

set req.http.staticmarker = "1";

unset req.http.Cookie;

}

# As soon as we have a NO_CACHE cookie pass request

if (req.http.cookie ~ "NO_CACHE=") {

return (pass);

}

#Dont cache below URLs in varnish as they are dynamic and might contain customer data

if (req.url ~ "(checkout|customer|order|moneybookers|paypal|wishlist|cart| downloadarticle|downloadimage|catalogsearch|icache|phone|currency)") {

return (pipe);

}

set req.http.magicmarker = "1"; #Instruct varnish to remove cache headers received from backend

return(lookup);

}

sub vcl_hash {

hash_data(req.url);

if (req.http.host) {

hash_data(req.http.host);

} else {

hash_data(server.ip);

}

if (!(req.url ~ "^/(media|js|skin)/.*\.(png|jpg|jpeg|gif|css|js|swf|ico)$")) {

call design_exception;

}

return (hash);

}

sub design_exception {

}

sub vcl_fetch {

if (beresp.status == 500) {

set beresp.saintmode = 10s;

return (restart);

}

set beresp.grace = 5m;

# add ban-lurker tags to object

set beresp.http.X-Purge-URL = req.url;

set beresp.http.X-Purge-Host = req.http.host;

if (beresp.status == 200 || beresp.status == 301 || beresp.status == 404) {

if (beresp.http.Content-Type ~ "text/html" || beresp.http.Content-Type ~ "text/xml") {

if ((beresp.http.Set-Cookie ~ "NO_CACHE=") || (beresp.ttl < 1s)) {

set beresp.ttl = 0s;

return (hit_for_pass);

}

# marker for vcl_deliver to reset Age:

set beresp.http.magicmarker = "1";

#Don't cache cookies

unset beresp.http.set-cookie;

} else {

# set default TTL value for static content

set beresp.ttl = 4h;

}

return (deliver);

}

return (hit_for_pass);

}

sub vcl_deliver {

if (obj.hits > 0) {

set resp.http.X-Varnish-Cache = "HIT";

}

else {

set resp.http.X-Varnish-Cache = "MISS";

}

return (deliver);

}

Note: Above configuration file is an example of configuration file provided by Magento PageCache Varnish Module, it might require several changes based on architecture and environment.

Once varnish is configured, you can check varnish hit ratio with varnishstat command:

Sample Output: (Higher number of varnish hits, better will be performance and vice versa)

13056 1.00 1.82 client_conn - Client connections accepted

8055 1.00 1.12 client_req - Client requests received

4532 0.00 0.63 cache_hit - Cache hits

7 0.00 0.00 cache_hitpass - Cache hits for pass

1801 0.00 0.25 cache_miss - Cache misses

1377 1.00 0.19 backend_conn - Backend conn. success

2185 0.00 0.30 backend_reuse - Backend conn. reuses

Configuring Magento with Memcached (2 level caching)

Memcached is a free and open source distributed memory object caching system. Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.

We can configure 2 level of caching in Magento configuration which will be used to fetch data from i.e. Fast Backend and Slow backend

The Fast backend will be a small part of memory that will be checked in first for data. If this data is not found there, then it will be checked in the slow backend, bigger part of memory but slower. Magento allow this 2 type of level. We can imagine about a configuration like:

Fast: APC, Slow: file
Fast: APC, Slow: memcache
Fast: memcache, Slow: database (Recommended for clustered environment)

We will configure Memcached as a fast backend and Database as a slow backend (Assuming we have clustered enviroment and we have more than 1 Magento instance)

Install Memcached on one of the node which will act as Memcached server:

yum install memcached (Make sure epel yum repository is installed and enabled on server)
yum --enablerepo=webtatic install php-pecl-memcache (Make sure webtatic yum repository is installed and enabled on server)
yum install libmemcached-devel

Once it is installed, check if memcached PHP module is installed with php -m command

Once Memcached is installed, configure it with below settings in /etc/sysconfig/memcached:

PORT="11211" #Port on which memcached will listen

USER="memcached" #User with which memcached daemon will be started

MAXCONN="2048" #Max connections on memcached server

CACHESIZE="256" #Allocated memory to memcached in MB

OPTIONS="-l 192.168.200.70" #Memcached listen IP address

Start memcached server i.e. /etc/init.d/memcached start

Configure Magento to use memcached as a fast backend and DB as a slow backend,

Open /<magento_root>/app/etc/local.xml

<cache>

<backend>memcached</backend> #Fast backend configuration

<slow_backend>database</slow_backend> #Slow backend configuration

<id_prefix>cache_</id_prefix>

<memcached> #Define memcached server and other configuration

<servers>

<server1> #More than one memcached server can be defined

<host><![CDATA[192.168.200.70]]></host>

<port><![CDATA[11211]]></port>

<persistent><![CDATA[0]]></persistent>

<weight><![CDATA[1]]></weight>

<timeout><![CDATA[60]]></timeout>

                <retry_interval><![CDATA[10]]></retry_interval>

    </server1>

    </servers>

    <compression><![CDATA[0]]></compression>

    <cache_dir><![CDATA[]]></cache_dir>

    <hashed_directory_level><![CDATA[]]></hashed_directory_level>

    <hashed_directory_umask><![CDATA[]]></hashed_directory_umask>

    <file_name_prefix><![CDATA[]]></file_name_prefix>

    </memcached>

    </cache>

Once Memcached is installed, you can check hit ratio of memcached server with phpMemcachedAdmin - (http://phpmemcacheadmin.googlecode.com/files/phpMemcachedAdmin-1.2.2-r262.tar.gz)

Extract the installable in Document root of the web server under any directory for e.g. Memcache, and access the location to view/configure the memcached hit ratio

http://<server-name>/memcache will show you the output.  Higher the Hit ratio, higher the performance of the site

Magento Configuration Changes for performance tuning

    Magento Session Handling

Magento sessions can be stored in 4 ways i.e.

File System – Stability, Simplicity and Durability

Memcached – Fast, Cluster-friendly, Need separate instance for memcached

Database - Stable but Adds more load to databases

tmpfs Filesystem – Fast but highly volatile, Not recommended for Live stores

Here are the results of each sessions storage for varying numbers of concurrent users.

Session Storage Average Response Time (s) for a varying number of concurrent users

Reference: http://magebase.com/magento-tutorials/magento-session-storage-which-to- choose-and-why/

Concurrent users	Filesystem	Database	Memcached	tmpfs Filesystem
10	1.53	2.14	1.83	1.42
30	4.59	4.33	4.11	4.07
75	10.23	11.33	10.52	10.33

Note: File System session storage is the most stable and simple method also there is no significant performance improvement in using other methods

        Directory Structure Optimization

Magento Enterprise Edition should be used on top of Zend Framework to reduce the number of system calls required to locate a file in directory structure

Enable Mag_Compiler for Magento EE to provide extra optimization by common class files pushed to one single directory and fewer files.

Flat Catalog

Flat Frontend Catalog module is used to facilitate fast database queries in Magento. This module maintains an additional set of database tables to store catalog data in a linear format, with extra indexes for frontend catalog pages.

•                     Flat Categorizes should be enabled to Magento Enterprise Edition for improved performance

•                     Flat products should be enabled for catalogs with more than 1000 SKUs.

•                     To Enable Flat Categories and Products from Magento Admin Panel:

•                     Browse to System → Configuration → Catalog --> Click on Frontend under Catalog Tab --> Set 'Yes' for Use Flat Catalog Category and Use Flat Catalog Product

Rebuilding Indexes

Index rebuilding is a resource intensive operation and should be scheduled when customer activity is low.

         Separate Admin Node

                       Magento Admin operations are CPU and memory intensive as compared to Frontend . A separate web server can be used to migrate this additional load of admin activities   on a separate instance

                        Search Type Selection

                        Enable Fulltext search for faster result retrieval and less load on database.

                        Frontend Layout Complexity

                        Fewer blocks with simple layouts can increase the page generation time faster by 4-5%.

                        Number of HTTP Requests on the page

                      Magento Enterprise allows for combining multipe JavaScript files and stylesheets into a smaller number of files. The theme layout can be developed to include JavaScript files properly so that all the script files are combined in one file.

                         Using Parallel Connections

                   Magento Enterprise provides the capability to specify different domains for media, skin, JavaScript URL which aid in faster page rendering by loading page elements in parallel. This configuration can be made from Admin → System → Configuration → Web and specifying different URLs for media, skin and JavaScript

                         Disable Magento Modules

                         Disable modules that you are not using, Go to System -> Configuration -> Advanced -> Advanced.

                        Enable all Magento Cache:

                Though we have Varnish and Memcached configured for Magento, enabling magento in-built cache (including Full page cache) improves magento store performance significantly

                         Enable all Cache, Go to System -> Cache Management

          Combine Javascript and Combine CSS Files

                         Go to System ->Configuration ->Advanced ->Developer -> ‘Javascript settings’ and ‘CSS Settings’.

                         Layered Navigation

                         Don’t use layered navigation if you don’t really need it, it’s resource intensive.

                         Compilation

                         Use Magento’s Compilation feature. It is reported to give a 25%-50% performance boost: Go to System > Tools > Compilation

                         Number of Products Limit the number of products on a product overview page.

                         Frontend Proprties

                      Set only those attribute frontend properties to ‘Yes’ that you are actually going to use. Set all other to ‘No’. Do not use in quick search, advanced search compare, etc.: Catalog -> Attributes -> Manage Atributes -> Frontend Properties

Disable the Magento log

Go to System -> Configuration -> Advanced -> Developer -> Log Settings (default is disabled).

Enable Solr search

It is quicker compared to the default search functionality, especially when you have lots of products i.e. More than 10,000.

References

http://www.gxjansen.com/101-ways-to-speed-up-your-magento-e-commerce-website/

http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/

http://magebase.com/magento-tutorials/speeding-up-magento-with-apc-or-memcached/