Overview:
The Apache HTTP server is an open source, configurable and extensible,multi-platform Web server. It was initially developed in 1995 using NCSAhttpd (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 HTTPprotocol. 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.
➤ 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.
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 HTTPprotocol. 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 gatherstatistics, 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 Counter:
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.
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.
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.
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.
No comments:
Post a Comment