Configuring Web Systems For Best Performance

We shall start by building a front-end system and determine the purposes and tasks of this tier.

NGINX, SQUID, OOPS or other similar product can be used as a front-end server.

NGINX is a very compact and fast web (HTTP) server. NGINX consumes just a little memory, is able to serve requests for static files without assistance and can act as an accelerated non-cashing proxy. For example, if an image is requested, NGINX reads data from the disc and transfers the file to a client.

SQUID and OOPS are classic proxy servers capable of proxying requests; they usually cache static requests by storing copies of static objects in the cache (or disc for persistent objects) during a certain period of time.

We can assert that NGINX showed the best run-time results. However caching proxy servers can also produce good results.

In a two-tier architecture, a front-end system is puts forward to a client: a lightweight web or proxy server that receives user requests and executes the requests that can be processed without the back-end assistance. If using NGINX or similar server, all static objects are read directly from the disc and transferred to a client. If a caching proxy server is used, a back-end is queried for static objects, images and style-sheets only once. Afterwards, these files are stored in the front-end cache according to the cache policy and transferred to clients without querying the back-end.

The main goals we attempt to achieve by creating a front-end tier are:

• minimize queries to the back-end web server. The point is to make a front-end address the back-end only to obtain the HTML output of a PHP page. All queries to static objects are to be processes by the front-end light-weight processes, or, if using a caching proxy server, all subsequent queries after the initial one. Advice: check the back-end web server log to make sure you have configured it properly to exclude all redundant queries. The log should contain only PHP pages; other queries should not reach the back-end system and be specified in the log file.
• reduce memory consumption when processing static queries. The number of queries for static files is usually greater than for PHP pages. The front-end processes consume 2-5 MB of memory at the average; the process size slightly increase when processing static documents. This allows to significantly reduce the overall system memory consumption.
• eliminate the slow channel effect on the system performance. The front-end processes may take quite a long time to transfer content to a client, consuming little memory for static requests or HTML pages obtained from the back-end web server PHP processor. Hence, having relayed a query to the back-end, the front-end receives a response (which frees the back-end processes to handle other queries) and transfers an HTML page to a client, thus eliminating the slow channels effect. The system approximates the ideal “B” system from the example above. However, ensure that the front-end buffers are sufficient enough to receive the whole HTML page from the back-end without delay. This means that buffer size should be equal to or more than the size of the largest generated HTML page of your site.
• protect back-end from numerous queries at the expense of longer waiting for released back-end processes. Make sure that the front-end can wait for 5, 10 or 15 minutes until the back-end processes are released. This approach enable us to configure the back-end to stabilize the system and get ready for stress loads.

As you can see, the front-end allows to eliminate quite a few risks and attain the most favorable conditions for the system.

Note! If you intend to use a caching proxy server as a front-end, configure the caching time of documents. Images, style-sheets, XML files and other static objects are subjects of the caching policy. After the first request, files are stored in the proxy server and are transferred to clients without querying the back-end. The recommended image caching time is 3 to 5 days. The following code shows an example of the cache configuration that can be specifies in the .htaccess file of the server root:

ExpiresActive on 
ExpiresByType image/jpeg "access plus 3 day" 
ExpiresByType image/gif "access plus 3 day"

This example requires that a web server allows redefinition of variables in .htaccess, and the "mod_expires" module is installed. In some cases, the front-end caching policy is configured independently of the back-end configuration.

These directives instruct the front-end to cache all images. Queries for the content pages will not be cached and will be directed to the back-end.