Overview
The Apache HTTP server is an open source, configurable and extensible, multi-platform Web server. It was initially developed in 1995 using NCSA httpd (HTTP daemon) as a base. In time, the Apache HTTP server became one of the most commonly used Web servers for commercial Web sites and Web-based applications.

As one of the dominant Web servers it is important to understand Apache’s high level architecture, counters for monitoring, tuning aspects ,and other performance related best practices. This chapter summarizes these aspects as
well as making you familiar with LoadRunner & Performance Center techniques for monitoring the Apache Web server.

Architecture

The function of a Web server is to service requests made through the HTTP protocol. Typically the server receives a request asking for a specific resource and returns the resource as a response back to the client. Apache fulfills this purpose by separating the request handling responsibility to the Apache core and Apache modules:

• The core is responsible for defining and following the steps in servicing a request.
• The modules actually implement the different phases involved in handing a request.

This architecture makes Apache a great platform for third parties to override or extend functionality as well as allow Administrators to tune the server for best memory management by turning off unused modules

Apache 2.0 architecture and capabilities are superior to those of Apache 1.3, even though both series are considered to be production quality versions. The following describe performance related characteristics in Apache 2.0
architecture:

• Multi Processing Modules. Apache 2.0 supports Multi Processing Modules (MPMs) as opposed to Apache 1.3 which is process-based that forks several children at startup. MPMs mean that Apache can be configured to be a pure process-based server, a purely threaded server or a mixture of those models. Threads are contained inside processes and run simultaneously and in most cases threaded servers scale better than process based servers.
• Module and filter. As mentioned above, Apache maintains modular architecture. Apache 2.0 adds an additional extension mechanism: filters. Filters allow modules to modify the content generated by other modules. They can encrypt, scan for viruses or compress not only static files but dynamically generated content.
• Apache Portable Runtime. Apache 2.0 runs equally well on Windows and UNIX platforms thanks to the Apache Portable Runtime (APR) library. It abstracts the differences among operating systems, such as file or network access APIs. This abstraction layer also provides for platform-specific tuning and optimization. The APR uses the concept of memory pools, which significantly simplifies the memory-management code and reduces the possibility of memory leaks.

In compliancy with Apache architecture, counters exposed by Apache for understanding and monitoring server status are available from the Apache mod_status module. The status module provides information on server activity and performance. It exposes the server statistics either in the HTML page in an easily readable form (i.e. http://your.server.name/server-status) or in a simple machine-readable list (i.e. http://your.server.name/serverstatus? auto) oriented for automating the monitoring process. Both modes can be configured to automatically refresh the status by adding refresh parameter in the URL query string (for example,
http://your.server.name/server-status?auto&refresh=30 will automatically refresh the machine-readable status every 30 seconds). The mod_status module can be configured to provide extended status. By default it is disabled.

Note: The Apache monitor connects to the Web server in order to gather statistics, and registers one hit for each sampling. The Apache graph, therefore, always displays at least one hit per second, even if no clients are connected to the Apache server.

Most Important Apache Counters

The HP LoadRunner/Performance Center Apache monitor is built to track the counters exposed in the machine-readable page (server-status?auto). HP SiteScope supports both modes. The most important counters are available in the machine-readable page.

          Counter                                         Description

• CPULoad                                       The current percentage of CPU consumed by the Apache server
• ReqPerSec                                    The number of requests per second (a.k.a. hits per second)
• BytesPerSec                                 The number of bytes transferred per second
• BytesPerReq                                The number of bytes transferred per request
• BusyWorkers                               Number of active threads serving requests
• IdleWorkers                                 Number of inactive/idle threads

Tip: All these counters are available in the server-status?auto page. You can easily create a VuGen script to parse these counters data on your own and send it to LoadRunner/Performance Center online using lr_user_data_point.

Optimization and Tuning

When performance issues are encountered, tuning and optimization are required to alleviate the issues. It is recommended to act proactively and prevent these issues from occurring in the first place. This section lists a few
possible tuning parameters, optimization practices, and benchmarking methods oriented for the Apache Web server. Before applying any of these, you should first validate the relevancy of the configuration to your specific case by understanding the parameter and the workload generated against your server.

• HostnameLookups directive should be off (off by default). When turned on DNS lookups will consume a lot of time and slow the server.
• KeepAlive directive should be on (on by default). KeepAlives provide longer HTTP sessions which allow multiple requests to be sent over the same TCP connection. This has proved to be extremely significant for speeding up response time.
•  KeepAliveTimeout directive represents the number of seconds Apache will wait for a subsequent request before closing a connection. The default configuration is 15 seconds. The higher the timeout, the more server threads will be kept occupied waiting on connections with idle clients.
• Avoid using .htaccess files. The use of .htaccess files can be disabled completely by setting the AllowOverride directive to none. When AllowOverride is set to allow the use of .htaccess files, Apache will look in every directory for .htaccess files. Permitting .htaccess files causes a performance hit, whether or not you actually even use them. Also, the .htaccess file is loaded every time a document is requested.
• It is recommended to unload unused modules in order to optimize memory utilization.
• MaxKeepAliveRequests directive. A Web server should never have to swap, as swapping increases the latency of each request beyond a point that users consider “fast enough”. This causes users to hit stop and reload, further increasing the load. You can, and should, control the MaxClients setting to prevent your server from spawning so many children that it starts swapping.

The MaxKeepAliveRequests directive specifies the maximum number of child processes that will be created to serve requests, and limits the number of simultaneous requests that will be served. Any connection attempts that are over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive. You should set this to the maximum number of clients that your environment can manage without experiencing throughput degradation or a prohibitive increase of the response time.