Archive

Posts Tagged ‘Apache’

ab – Apache Benchmark

August 8, 2008 4 comments

ab (Apache Benchmark) is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server. It provides a quick an easy way to evaluate your http serving capabilities. ab overloads the server with http requests and measures the time it takes to serve all those requests.

The benchmark is intended for all available versions of Apache through 2.x.

A very common question is how to install ab and where to get it. The real thing is that ab comes preconfigured with your apache installation. Apache by himself is just an extension command for the Apache Web Server. So if you have already installed Apache, then you should also have the ab benchmarking tool.

What we need in order to get ab to work is type the command and append the URL address we want to test. The command is issued as follows:

# ab -n100 -c10 http://localhost:8080/index.jsp

Lets see an example screen:

The -n parameter tells ab the number of connections to send to the server. In this case we are sending just 10, while the -c means the number concurrent requests to be made. The -k option activates the KeepAlive feature and the -t is the timelimit (in seconds)for apache to spend for benchmarking.

The number of connections is the most important parameter, the first times set it to a prudent level of connections and try with different values, increase this value until you get satisfied with the benchmarking; An ab test makes consumption of the server RAM, resources, bandwidth and processor so if you put a brutally high number of connections on an underpowered server, it may get out of resources.

ab is a very simple and useful command line application. It can be understood and performed with ease on almost any kind of Apache server.

As a matter of fact, the ab testing mechanism actually is a good example of a Denial of Service (DoS) attack. Of course ab is not as dangerous and stealthy, and although its very unlikely for it to effectively damage a server, the basis remains the same.

For further information, you can always check the official webpage.

Categories: Apache Tags: ,

Apachetop Monitor

August 5, 2008 2 comments

ApacheTop is a Linux tool designed to monitor Apache Web Server real-time connections and requests. It makes use of the Apache access logs to show meaningful process information.

Monitoring Apache can be tiresome, there is no easy way to give yourself an overview of what your Apache server is really doing. This is where the ApacheTop utility comes in.

You can get the needed files from livna yum repository, apt-get on Debian based systems or download it directly from its official (and unmaintained) site:

ApacheTop

To verify the installation just type apachetop on the command line.

After the successful installation, you can pass in the parameters to ApacheTop and start the monitoring tool. By default Apachetop will use your log in /var/log/apache/access.log but for this particular example I’m not using the default file.

# apachetop -f /etc/http/logs/access_log

This will show you a screen like the next one:

 

Most of the columns are self explanatory, but in case you don’t get it here it is the explanation:

REQS – Number of simultaneous requests to the specified URL.
REQ/S – Number of requests per seconds served by apache on the specified URL.
KB – KB of data sent to the client.
KB/S – Data transfer rate.

For instance, the time range for data to be refreshed is 30 seconds; You can change this value with the proper parameter.

Use H to specify the maximum number of hits to be displayed:

# apachetop -H 100 -f /etc/http/logs/access_log

Or use T to specify the time (in seconds) for data to be refreshed.

# apachetop -T 120 -f /etc/http/logs/access_log

ApacheTop also gives you some simple filters: URLs, REFERRERS and HOSTS.

Much like his brother top, to enter a command just hit the appropriate key. From within the monitor screen, hit f to see the available options, and then hit a to add a filter.

You may have already noticed the little asterisk showing up at ApacheTop interface. Move your arrow keys up and down to the desired line, and then hit the right arrow key to access the details for that request. These details include the referrers and IPs of the clients that are making the selected request. To go back use the left arrow key.

As you can see ApacheTop is very simple, and as of October 2005, it is no longer maintained by his former developer, however it’s still a very useful application for log analysis. Give it a try.

Categories: Apache Tags:

Apache Out Of Memory Error

July 27, 2008 3 comments

For sure many people have had this kind of problem when deploying an application over Apache Web Server.

An Out of Memory (OOM) error occurs when the Apache instances start to increase their physical memory usage, overloading the server resources and forcing the system to start swapping RAM. When the swap memory depletes, the whole integrity and stability of the operating system is put at risk, then the kernel decides that is better to start killing processes in order to keep himself alive.

An example of a OOM error:
# vim /var/log/messages
July 12 13:11:19 localhost kernel: [ 8267.512850] Out of memory: kill process 7986 (apache) score 15147 or a child
July 12 13:11:19 localhost kernel: [ 8267.513008] Killed process 7986 (apache)

How the system knows which processes are safe to kill is calculated by a fast -but some times inefficient- algorithm but in general terms the parameters are the following:

  1. Which processes are running as root?
  2. How long a process has been running?
  3. How many RAM/Swap is used by a process?
  4. if (process == init) Don’t touch it!

Because in an OOM situation, the system has just a fraction of seconds to make the decision, the heuristics are not quite optimal and sometimes they will be inaccurate.

Apache processes use a ton of RAM. This becomes major threat when you realize that after each process has done its job, the bloated process sits and spoon-feeds data to the client, instead of moving on to bigger and better things.

The trick to get around this consists in fixing the Apache configuration file; The default file is the following:

# cd /etc/httpd/conf/
# vi httpd.conf

MaxClients
Max clients defines the maximum number of connections a child process can handle simultaneously. When a child process reach this limit, new connections start to queue; Of course this connections have to be saved somewhere on the system… ungracefully they’re stored on the RAM and then the swap memory.
If you use Apache to serve dynamic content, your simultaneous connections are severely limited. Exceed a certain number, and your system begins cannibalistic swapping.
By default this is set to 150. You could try increasing this value, just keep in mind that in a normal and standard installation of Apache you are limited to 256 MaxClients (I’m covering this topic on another post). If you set it to low, a message like the following will be printed in your error.log file:

[error] server reached MaxClients setting, consider raising the MaxClients setting.

MinSpareServers
When the Apache daemon (the father process) is started, a fixed number of child processes is spawned creating a pool of servers ready to serve the clients. By default this is set to 5; Creating new child processes is expensive for the system resources and the best practice is to always have servers ready for all the clients that may connect to the server. If you have a lot of traffic you should think in increasing this value.

MaxSpareServers
You can also define the max child processes your Apache server can spawn. As with the MaxClients option, when this value is reached new connections start to queue. A value between 20-50 should be fine in most situations.

MaxRequestsPerChild

Forcing your processes to die after awhile makes them start over with lower RAM usage. This can reduce total memory usage in many situations. This variable is very important on production systems. By default each Apache instance can serve an unlimited amount of clients/traffic. Child processes are never killed by the father process so, as time goes by, you can encounter with a process that has been running for, lets say, 28 days!.
If child processes never “recycle” themselves there is a high chance that the older ones may have used a lot of RAM they are not going to release until they die. Someday you will have to re-spawn this processes in order to keep the memory “clean”.
MaxRequestsPerChild defines the maximum connections a child process can serve. When the value is reached the child processes stops receiving new connections, awaits for the last current connection to be served and then it dies. Apache father process then re-spawns a new child and the cycle continues.
A value of 0 means unlimited (not recommended); In most cases values like 5000 would work fine but also values as low as 10 or 20 also may work for you. This is a game of catch-up, with your dynamic files constantly increasing total RAM usage, and restarting processes constantly reducing it. You have to experiment with this value.

There are more variables you can change and play with them, but those ones does have a little (if not null) relation with the OOM problem.

An OOM error is just a safety measure, NOT a system feature. The very existence of an OOM killer is a bug.

The goal of the sysadmin shall not be fix the OOM, but to get to the root of the problem and fix it. Poorly optimized queries and/or running the application on a piece of crap hardware, are common causes that may lead the server to an OOM.

Categories: Apache Tags: