Server Stress Testing - Using Apache Bench
Performing server stress testing with Apache Bench to assess server performance
Server stress testing is a must before going live, no exceptions!
Just imagine you’ve been working overtime for months, the system goes online.
And you’re celebrating with pizza and cocktail, only to find out suddenly the server crashes due to overwhelming traffic!
That’s why conducting stress tests beforehand makes a good system!
Before going live, we’re often asked about the server’s capacity to handle business loads, or sometimes not asked at all.
But one day, when the service suddenly surges, a large influx of users overwhelms the system.
The boss thinks it’s a gold rush moment, but what comes first is complaints about the server CPU usage exceeding 100%, followed by service interruptions.
The tool introduced this time can help us detect this problem in advance, allowing us to prepare contingency measures mentally in advance.
Whether it’s by upgrading the hosting plan or implementing rate limiting measures, we can prevent service interruptions.
Apache Bench
Apache Bench
, also known as “ab,” is already installed by default on MacOS.
It’s different from A/B testing; Apache Bench is one of the open-source testing tools developed by Apache.
Its primary purpose is to stress test websites or API servers by sending a large number of requests simultaneously to increase server load
and then analyze the performance test results to adjust the hosting environment.
It must be used with caution because its principle is similar to DDoS (Distributed Denial of Service) attacks
, where a large number of requests are sent to the server every second!
Usage
Start testing a specific URL with ab <url>, and there are many parameters available for use.
Common Parameters
You can see them using the ab -h command:
Usage: ab [options] [http[s]://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make at a time
-t timelimit Seconds to max. to spend on benchmarking
This implies -n 50000
-s timeout Seconds to max. wait for each response
Default is 30 seconds
-b windowsize Size of TCP send/receive buffer, in bytes
-B address Address to bind to when making outgoing connections
-p postfile File containing data to POST. Remember also to set -T
-u putfile File containing data to PUT. Remember also to set -T
-T content-type Content-type header to use for POST/PUT data, eg.
'application/x-www-form-urlencoded'
Default is 'text/plain'
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute Add cookie, eg. 'Apache=1234'. (repeatable)
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-q Do not show progress when doing more than 150 requests
-l Accept variable document length (use this for dynamic pages)
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-r Don't exit on socket receive errors.
-m method Method name
-h Display usage information (this message)
-I Disable TLS Server Name Indication (SNI) extension
-Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers)
-f protocol Specify SSL/TLS protocol
(TLS1, TLS1.1, TLS1.2 or ALL)
-E certfile Specify optional client certificate chain and private key
The most commonly used parameters include:
-n: Number of requests to perform during the test, default is 1.-c: Number of multiple requests to make at a time, simulating concurrent users, default is 1.-e output.csv: Export performance test raw data to a CSV file namedoutput.csv.
References: Using ApacheBench for Web Stress Test
[Note] Adjusting php-fpm
An interesting tuning experience; the PHP-FPM threads are insufficient.
If you haven’t encountered this, you might not pay much attention, so let’s take some notes: PHP FPM Max Children
Combined with the explanations in this article: Optimizing Linux, Nginx, and PHP-FPM connection count
If you’re using Docker containers, you can enter the PHP-FPM container and find the configuration file
/usr/local/etc/php-fpm.d/www.conf
You can adjust it from the outside like an Nginx config file and mount it in, or set it during Dockerfile packaging.
