So as we figured out at the previous post the load testing is just as important for the site as attractive design and competent advertising.
Sudden surge of visitors exceeding the capabilities of the Web server can cost for companies tens and sometimes hundreds of thousands of dollars. Therefore, it is worth caring of the server selection and its configurations from the early days of your website development.
There are many tricks to increase the speed of web pages loading.. In some cases it is possible to achieve productivity growth of 500%-600% using simple optimization techniques.
The best answer for the question “How will I force the site to run faster?” is to use caching.
ViSolve reveals quite interesting return on investment data if you have two caching servers.
Now we will try to understand how two different types of caching help to keep the server resources and reduce the response time of Web pages.
What is caching?
«In computer engineering, a cache is a component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data is contained in the cache (cache hit), this request can be served by simply reading the cache, which is comparatively faster. Otherwise (cache miss), the data has to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the greater the number of requests that can be served from the cache, the faster the overall system performance becomes». (http://en.wikipedia.org/wiki/Cache). In other words caching is just saving some data in memory for later use without redoing resource-intensive operations.
Web applications constantly address to the database and files. Why do we always load the system with repeated complicated requests? When reading data from the hard drive it is necessary to reach the sector with stored information on the other hand read it. The data is retrieved for memory almost instantly.
The purpose of caching is to speed delivery of content to the user avoiding unnecessary operations performed by the web server. Transferring a file to memory allows you to reduce significantly the number of disk reads, which reduces the waiting time between clicking on a link and a full page load. There can be no productivity without caching.
Caching can be divided into 3 levels:
- 1. The Web Server Caching
- 2. The Application Caching
- 3. The Database Caching
Let’s explore how the Web Server can help with the optimization using the browser-caching and memory sharing.
Web Server Cache Control
The most well known type of cache is browser’s cache stored on your computer. Once the browser loads and displays the file (such as image, css or js files, etc.) downloaded data is not removed, and stored in special storage on your hard disk. When you request the file being previously loaded, web server tells the browser whether to request the data from the network or you can use a local copy of the file.
The Web server uses HTTP-headers to regulate what information can be used without change, and what to update. Cache control headers are critical for web application optimization of productivity, because they directly affect the speed of loading the requested content.
The Expires Header
The basic mechanism of caching is the Expires header. It reports the expiration date provided in the response data. The value indicates the date and time in UTC format (RFC 1123) after which the cache should be considered outdated, and the requests are redirected to the source server to verify its completeness or get new response:
Expires: Mon, 18 Oct 2010 14:15:00 GMT
This header is supported almost everywhere. It is equally well suited to caching static images, and to regularly updated pages. It is enough to specify an appropriate value. If you select an incorrect date or date in the past one, the data will be considered as non-cached.
The use of the Expires header requires that the clock in the cache and the source server are synchronized. Otherwise, the same timestamp can be interpreted in different ways. Also do not forget to update the expiration date, if necessary. Otherwise, on its expiry the caching will stop working, and all requests will be sent to the server.
In order to force the Apache Web Server to generate proper Expires HTTP-headers, you should edit the .htaccess file (located in the root folder of the site), or the httpd.conf / vhost.conf file (depending on used web hosting configuration) and add the following lines :
ExpiresByType text/css "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
This fragment of a configuration file of the Apache web server checks module mod expires, and if the module mod_expires is available generates HTTP-header Expires, which set the period of storage facilities listed above in the browser cache and proxy servers for one year since the date of the first request. Some manuals suggest the simpler way, by replacing lines 03-08 with:
ExpiresDefault text/css "access plus 1 year"
I am against such approach, because it affects many more objects than necessary, and can lead to unpredictable consequences.
What is necessary to do, if I need to update a static object before its browser cache and proxy server storage expires? The easiest way is to change the URL. In more detail, the site developer should provide the option to add some additional key to the URL of the renewed object. This key should depend on the last modified date and have a minimum length of eight characters (the last condition is important to prevent collisions in the caching subsystem of the Mozilla Firefox browsers). This approach is more complicated in terms of implementation, however, it is most effective in term of site support convenience, because allows to establish long terms storage of objects in the browser cache and proxy servers and eliminates the problems associated with the upgrading of the renewed data.
To be continued 1st February…