Ugacomp

How can I simulate traffic on a Linux server using Apache Bench?

Where necessary, you may need to have access to a VPS server so you can follow how to implement the steps in this article.  You can get a cheaper VPS Server from Contabo with 4vCPU cores, 8GM RAM, and 32TB Bandwidth for less than $5.50 per month. Get this deal here now

Table of Contents

Cloud VPS S

$5.50 Monthly
  • 4 vCPU Cores | 8GB RAM

CLOUD VPS M

$15.50 Monthly
  • 6 vCPU Cores | 16GB RAM

CLOUD VPS L

$17.50 Monthly
  • 8 vCPU Cores | 24GB RAM

Apache Bench (also known as ab) is a command-line tool used for benchmarking and load testing web applications or HTTP servers. It is a part of the Apache HTTP Server project and is installed by default with most Apache distributions like Apache Webserver.

Apache Bench can simulate multiple concurrent users accessing a web application, and measure the application’s response time, throughput, and other performance metrics. It can be used to test the performance of a web server, test the scalability of an application, and identify potential performance bottlenecks.

RECOMMENDED READING: How does Alibaba Cloud Free trial work?

How does Apache Bench work?

Apache Bench works by sending HTTP requests to a specified URL, with a specified number of concurrent requests and total requests to be sent. It then measures the time taken to receive a response from the web server and calculates various metrics such as:

The number of requests per second

This is the rate at which Apache Bench can send HTTP requests to the web server being tested. It represents the number of requests that are completed within one second.

This metric is an important indicator of the web server’s performance under a specific load, as it reflects the server’s ability to handle a certain amount of traffic. The higher the number of requests per second, the better the server’s performance is considered to be.

It is also important to note that the number of requests per second can be affected by various factors such as network latency, server load, and the size and complexity of the requests being sent. Therefore, it should be used in conjunction with other metrics such as response time and error rate to provide a more complete picture of the server’s performance.

RECOMMENDED READING: How to use Alibaba Cloud Free credit to Set up an Ubuntu server

The average response time

Average response time refers to the average amount of time taken by the web server to respond to each HTTP request sent by Apache Bench. It is measured in seconds and is calculated by dividing the total time taken for all requests by the number of requests.

The average response time is an important performance metric as it reflects the time it takes for the server to process each request and send a response back to the client. A lower average response time is generally considered better, as it indicates that the server can process requests more quickly and efficiently.

The average response time can be affected by various factors such as network latency, server load, and the complexity of the requests being sent.

The standard deviation of response time.

The standard deviation of response time refers to the statistical measure that indicates the degree of variation or dispersion of the response times for each HTTP request sent by Apache bench. It is measured in seconds and is calculated by taking the square root of the variance of response times.

The standard deviation of response time is an important performance metric as it indicates how consistent the server’s response time is. A lower standard deviation is generally considered better, as it indicates that the server can respond to requests more predictably and consistently.

What is the primary use of Apache Bench?

Apache Bench is a simple and effective tool for load testing and benchmarking web applications, and it is widely used by developers, testers, and system administrators to evaluate the performance of web applications and servers.

Do you need to install Apache Bench?

Usually, Apache Bench comes preinstalled with Apache HTTP Server, but can also be installed as a standalone package on various operating systems.

To check if Apache Bench is already installed on your system, you just need to type the following command on your terminal and hit enter;

ab -v

How can I install Apache Bench manually on Ubuntu Linux?

If Apache Bench is not installed on your server by default after installing the Apache web server, you can manually install it. Here are the steps to manually install it:

Update the system

We need to update our Ubuntu server by running the apt update command as follows;

sudo apt update

Install the Apache2

Whenever you install Apache server on your system, it natively ships with other tools like Apache Bench. So, all you have to do is to install Apache server and you will be able to have access to this tool. Below is the command for installing Apache on Linux:

sudo apt-get install apache2

Alternatively, you can just install the apache2-utils package and you will be able to have the Apache Bench installed. And here is the command:

sudo apt-get install apache2-utils

Verify the installation

Now, you can verify if the Apache Bench has been installed by running the following command:

ab -v

The above command will show the Apache Bench version running on your system and the output on your terminal will look as follows;

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Apache Bench Parameters

Apache Bench parameters are command-line options that can be used to configure the Apache Bench tool to simulate different scenarios and test different aspects of an HTTP server. The parameters can be used to specify the number of requests to send, the concurrency level, the time to run the test, the HTTP method to use, and other configurations.

Here is the table summarizing all the Apache Bench parameters you’re likely to explore when running a traffic simulation and load test on your application:

ParameterDescription
-nThe number of requests to perform.
-cThe number of multiple requests to make at a time.
-tThe amount of time in seconds to perform the benchmarking test.
-pThe path to a file containing a list of POST data in the form “name=value”.
-TThe content type of the POST data.
-HA header to include in the request, in the format “HeaderName: HeaderValue”.
-dThe data to send in a POST request, in the form “name1=value1&name2=value2”.
-uThe file containing data is to be sent with a PUT request.
-eThe path to a file to which to write raw output data.
-gThe path to a gnuplot output file.
-rDon’t exit on socket receive errors.
-sThe size of the TCP send/receive buffer.
-kThe username and password to use for authentication, in the format “username: password”.
-vDisplay verbose information.
-VDisplay version information.
-XThe HTTP request method to use, e.g. GET, POST, HEAD.
-AThe User-Agent string to send in the request header.
-BAllow blank lines within response headers
-CUse the HTTP KeepAlive feature.
-DThe file containing data to be sent with a WebDAV request.
-fAllow the benchmarking test to continue after a non-2xx response is received.
-FThe file containing data is to be sent with a WebDAV request.
-iUse HEAD instead of GET.
-jUse Basic authentication.
-lUse HTTP/1.0 instead of HTTP/1.1.
-mThe HTTP method to use, e.g. GET, POST, HEAD.
-MThe file containing data is to be sent with a multipart/form-data POST request.
-nThe number of requests to perform.
-PThe password to use for authentication.
-qDo not display progress.
-SDo not display status messages.
-wPrint the test

The simulation and load testing results will depend on the parameters you define when executing the Apache Bench commands on the terminal. So, understanding the parameters and how to use them is so useful in this scenario.

Simulating traffic with Apache Bench

To set up your traffic simulation and HTTP server load-testing environment, you need to have two Linux instances running separately. One instance will run the Apache Bench tool and the second instance will be hosting the application using either Apache or even an Nginx HTTP server.

So, we’re going to use the Apache Bench Linux instance to run traffic simulation tests against the application hosted on the second instance, which either has Apache or Nginx HTTP server running. Our goal is to determine the kind of potential the web server on the second instance has in processing requests based on various metrics like the number of concurrent users.

Requests and Concurrent Requests

In Apache Bench, the “number of requests” refers to the total number of HTTP requests that will be made to the server. This means that if you set the number of requests to 1000, Apache Bench will make 1000 separate requests to the server and report back the results.

For example, the following command will make 1000 requests to the URL: https://example.com/ with a concurrency level of 100:

ab -n 1000 -c 100 http://example.com/

On the other hand, the “number of concurrent requests” refers to the number of requests that will be made at the same time. This means that if you set the concurrency level to 100 as we did earlier in the example, Apache Bench will make 100 requests at the same time and repeat this process until the desired number of requests has been made.

You will notice that we’ve used two Apache Bench parameters: -n to define the number of requests and -c for the number of concurrent requests.

Defining and understanding the number of requests and the total concurrent requests to a server hosting an application can handle gives you a good picture of what you need to set up a resilient infrastructure with scalability and performance optimization in mind.

When a server is overwhelmed with more requests than it can handle, the average response time will be high, and this could lead to serious application performance issues, eventually hurting your traffic performance.

Request and Response Time

Response time measures how quickly the server can process a request and return a response to the client. Response time is often used as a performance metric to evaluate the efficiency and effectiveness of a server in handling a given load of requests.

When performing load testing with Apache Bench, response time is an important metric to monitor. A higher response time can indicate that the server is struggling to handle a load of requests, which can result in degraded performance or even server failures. A lower response time generally indicates that the server is able to handle a load of requests more efficiently.

Analyzing Performance

In this example, let’s try to make a load test to the server by sending 100 ‘requests’ with 10 ‘concurrent requests’. We’re going to run this test on some hypothetical example.com website, and here is the ab command we will use;

ab -n 100 -c 10 https://example.com/

So, the output of the load test will be as follows;

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.example.com (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.example.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        58769 bytes

Concurrency Level:      10
Time taken for tests:   1.004 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5911100 bytes
HTML transferred:       5876900 bytes
Requests per second:    99.56 [#/sec] (mean)
Time per request:       100.444 [ms] (mean)
Time per request:       10.044 [ms] (mean, across all concurrent requests)
Transfer rate:          5747.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   46  30.9     41     263
Processing:    37   40  21.7     38     255
Waiting:       12   15  21.7     13     230
Total:         77   86  37.5     79     301

Percentage of the requests served within a certain time (ms)
  50%     79
  66%     79
  75%     80
  80%     80
  90%     82
  95%     84
  98%    296
  99%    301
 100%    301 (longest request)

Understanding the Output Values

You will notice that your terminal will be greeted with certain values as a result of the load test you’ve implemented using the Apache Bench tool. Now, here is the meaning of some of these values:

  • Server Software: This value indicates the software used by the server to respond to requests. In this case, the server software used is Apache web server. This means that the application we targeted is being powered by Apache server.

  • Server Hostname: The hostname of the server that was tested. This is a domain name attached to the server on which the application is being hosted.

  • Server Port: The port number used by the server for the test. HTTPS requests by default use port 443. On the other hand, the server uses port 80 to process HTTP requests by default.

  • Document Path: This is the specific URL or path of the resource (web page, image, file, etc.) that is being requested from the server during the benchmark test.

  • Document Length: This refers to the size of the HTTP response body returned by the server in bytes. It represents the total number of bytes received by the client in response to a particular HTTP request. The document length is an important metric to measure the performance and efficiency of a web server, as it affects the amount of data that needs to be transferred over the network.

  • Concurrency Level: This is the number of simultaneous requests that are made to a web server by the tool during a load-testing session.

  • Time taken for tests: The is the total time taken by Apache Bench to complete the test. The time taken for a test in Apache Bench depends on several factors such as the number of requests being sent, the size of the requests and responses, the network bandwidth, and the server’s processing power.

  • Complete requests: This is the number of HTTP requests that have been completed by the server and received a response from the server.

  • Failed requests: This refers to HTTP requests that could not be completed successfully. A failed request occurs when the web server or application being tested responds with an HTTP error code (such as a 4xx or 5xx status code), or when the request times out or encounters some other network or server error.

  • Total transferred: This is the amount of data that has been transferred from the server to the client during the benchmarking process. This includes both the content of the response and any headers or metadata associated with the response.

  • HTML transferred: This specifically represents the size of the HTML content that was received from the server in response to each request. When Apache Bench requests a server, the server responds with an HTTP response that includes various types of data, including the HTML content of the requested page. The “HTML transferred” metric in Apache Bench reflects the size of that HTML content, in bytes, for each request.

  • Requests per second: This is the number of HTTP requests that the tool can send to a web server in one second. It is a measure of the tool’s ability to simulate a high level of traffic to a web server and is often used to test the server’s performance and capacity under various load conditions.

  • Time per request: This is the amount of time it takes for a server to respond to a single request from a client. In web development, this metric is often used to measure the performance of a web server and is usually expressed in milliseconds. For example, if a web server receives 100 requests and the total time taken to process those requests is 10 seconds, the time per request would be 10000 milliseconds (10 seconds divided by 100 requests), or 100 milliseconds per request.

  • Transfer rate: This is the amount of data transferred per unit of time during a benchmarking test. It is typically measured in bytes per second (B/s) or kilobytes per second (KB/s). The transfer rate is calculated by dividing the total amount of data transferred during the test (i.e., the sum of the sizes of all the responses) by the total time taken to complete the test. The transfer rate is an important metric for evaluating the performance of a server or application under load. A higher transfer rate indicates that the server can handle more requests and deliver responses more quickly, while a lower transfer rate suggests that the server may be struggling to keep up with the load.

  • Connection Times: This refers to the time taken to establish a TCP connection between the client (the machine running Apache Bench) and the server being tested. This includes the time taken to perform the TCP handshake, which involves the client and server exchanging a series of messages to establish a reliable connection. It can provide valuable information about the performance of the server’s networking stack and can be used to identify bottlenecks or issues related to network connectivity.

  • Percentage of the requests served within a certain time: This is the percentage of total requests that are completed within a certain amount of time. When running a load test with Apache Bench, you can specify a time limit with the “-t” option, which sets the maximum amount of time to run the test. After the test is complete, Apache Bench outputs a table that includes a row for each percentage of requests that were completed within a given time frame. For example, the table might show that 90% of requests were completed within 500 milliseconds, while 99% of requests were completed within 1 second. This information can be useful for understanding how well your server is handling requests under load and identifying any performance bottlenecks.

Apache benchmarking Errors

When using Apache Bench, you may encounter different types of errors that indicate issues with the server or the network. Some of these errors include:

Connect failed

This error occurs when Apache Bench is unable to establish a connection with the server. This can happen due to network issues or server unavailability. To fix this error, you can try the following troubleshooting steps:

  • Check the server status: Make sure that the server you are testing is up and running, and that it is listening on the correct port.

  • Check firewall settings: If you have a firewall enabled, make sure that it is not blocking the connection between Apache Bench and the server. You may need to configure your firewall to allow connections on the port that you are testing.

  • Increase timeout values: If the server is taking too long to respond, you may need to increase the timeout values in your ab command. You can do this by adding the -t option followed by the number of seconds that you want to allow for a response.

  • Use a different port: If the server is already using the port that you are trying to test, you may need to use a different port for your test. You can specify a different port by adding the -p option followed by the port number.

  • Check network connectivity: If none of the above steps work, you may need to check your network connectivity to ensure that no network issues are preventing the connection between ab and the server. You can use tools like ping or traceroute to help diagnose network issues.

Failed requests

This error occurs when Apache Bench sends a request to the server, but the server is unable to process it due to issues with the server configuration or resource availability. You can take the following steps to troubleshoot this issue:

  • Identify the cause of the failed requests: The first step is to understand why the requests are failing. Check the response code and message for each failed request to see if there’s a pattern. Common causes of failed requests include server errors, network issues, and resource constraints.

  • Adjust the test parameters: If the failed requests are due to resource constraints, you may need to adjust the parameters of your test. For example, you can increase the concurrency level or the number of requests per second to put more load on the server. Alternatively, you can decrease the number of requests per second or the concurrency level to reduce the load.

  • Check the server logs: The server logs can provide valuable information about why the requests are failing. Look for error messages in the logs that correspond to the failed requests. If the server is returning error codes, such as 500 or 503, these may indicate server-side issues that need to be addressed.

  • Optimize the server configuration: If the failed requests are due to server-side issues, you may need to optimize your server configuration. For example, you can increase the server’s memory or CPU resources, adjust the timeout settings, or tune the web server parameters for better performance.

  • Use a different tool: If you’re still experiencing failed requests after trying the above steps, you may want to try a different tool for load testing. Some alternatives to Apache Bench include JMeter, Gatling, and Locust.

Non-2xx responses

This error occurs when the server sends a response code that is not in the 2xx range (e.g., 200, 201, 202, etc.). This can happen due to various reasons, such as server errors, misconfigured URLs, or authentication issues. Here are the steps you can take:

  • Check the error message: Apache Bench typically prints the error message in the terminal. Read the error message carefully to understand the cause of the error.

  • Check the HTTP status code: Look for the HTTP status code in the error message. The status code provides information about the type of error that occurred. For example, a 404 status code indicates that the requested resource was not found on the server.

  • Check the server logs: Check the server logs to find out more information about the error. The server logs can provide details about the cause of the error, such as a misconfiguration or a database error.

  • Check the request headers: Ensure that the request headers are correct and include all the necessary information, such as authentication tokens, content type, etc.

  • Check the request payload: Check the request payload to ensure that it is valid and correctly formatted.

  • Check the server configuration: Check the server configuration to ensure that it is correctly configured to handle the requests.

  • Check the network connectivity: Ensure that there are no network issues that could be causing the error.

Socket errors

This error occurs when there are issues with the TCP/IP connection between the client and the server. This can happen due to network issues, firewall restrictions, or misconfigured server settings. Take the following steps to try to fix these errors:

  • Check your network connectivity: Ensure that your network connection is stable and that there are no issues with your internet service provider or network configuration.

  • Verify the target website or server is reachable: Ensure that the website or server you are testing with Apache Bench is up and running and that there are no issues with the website or server itself.

  • Check your Apache Bench configuration: Make sure that your Apache Bench configuration is correct, including the number of requests, the number of concurrent connections, and the target URL.

  • Adjust the Apache Bench timeout setting: You can try increasing the timeout setting in Apache Bench to allow more time for the server to respond to requests. You can do this by using the “-t” option when running Apache Bench.

  • Increase the number of available sockets: You can try increasing the number of available sockets on your system to see if this resolves the issue. This can be done by adjusting the “ulimit” settings on your system.

  • Check your server configuration: If you are testing against a specific server, make sure that the server is properly configured and that there are no issues with the server’s network settings or configuration.

  • Try using a different tool: If you continue to experience socket errors with Apache Bench, you may want to try using a different load-testing tool to see if you get better results.

How to monitor your server resource usage

Load testing your server is primarily intended to help you understand if the application you’re hosting can handle a certain amount of traffic. This also means that you will need to monitor the resource usage on your system using a tool like htop, which is an interactive process monitoring package for Unix-like operating systems. This tool allows users to view and manage processes running on their system in real-time. It displays a list of running processes, along with their resource usage (such as CPU and memory usage

For Debian systems, you can install htop by running the following command:

 sudo apt-get install htop

And for CentOS/Fedora, you can use the following commands to install this tool:

sudo yum install epel-release
sudo yum install htop

To use the htop tool, all you have to do is to run the following command on the terminal of the system you’re benching with Apache Bench tool;

htop

And then, you will be able to see the CPU & RAM consumption in real-time when benching as seen in the image below;

Using htop to monitor Apache bench load testing on an application

More Apache-related articles to explore

Hire us to handle what you want

Hire us through our Fiverr Profile and leave all the complicated & technical stuff to us. Here are some of the things we can do for you:

  • Website migration, troubleshooting, and maintenance.
  • Server & application deployment, scaling, troubleshooting, and maintenance
  • Deployment of Kubernetes, Docker, Cloudron, Ant Media, Apache, Nginx,  OpenVPN, cPanel, WHMCS, WordPress, and more
  • Everything you need on AWS, IBM Cloud, GCP, Azure, Oracle Cloud, Alibaba Cloud, Linode, Contabo, DigitalOcean, Ionos, Vultr, GoDaddy, HostGator, Namecheap, DreamHost, and more.
 

We will design, configure, deploy, or troubleshoot anything you want. Starting from $10, we will get your job done in the shortest time possible. Your payment is safe with Fiverr as we will only be paid once your project is completed.