Testing Load Balancing

Testing Load Balancing

When application traffic grows, adding resources to a single server can help temporarily but does not remove the scalability limitation. A clustered application layer with automatic load balancing distributes requests across multiple application-server instances and improves both performance and availability.

In this article

Create an Environment and Deploy the Application

  1. Log in to the platform dashboard and click Create environment.
  2. In the topology wizard, choose the required programming language and application server. The source example uses Apache PHP.
  3. Set the resource limits, attach a Public IP to the application server, specify an environment name such as balancer, and click Create.
  4. After the environment appears in the dashboard, deploy an application. The source example uses the default HelloWorld.zip package.

Run the Control-Point Test

The source workflow uses ApacheBench (ab) to generate HTTP load and store response-time data.

ab -n 500 -c 10 -g res1.tsv {URL_to_your_env}
-n 500Sends a total of 500 requests.
-c 10Sends up to 10 concurrent requests at a time.
-g res1.tsvStores benchmarking results in res1.tsv.
{URL_to_your_env}The URL copied from Open in Browser.

Change the Environment Configuration

  1. Return to the dashboard and open Change environment topology for the test environment.
  2. Increase the application-server count from one to two.
  3. The platform automatically enables an NGINX load balancer in front of the application servers.
  4. Apply the topology change and wait until it completes.
Automatic load balancing: when multiple application-server instances are present, NGINX distributes incoming HTTP requests among them.

Test the Load-Balanced Configuration

Run ApacheBench again with the same request and concurrency settings, but save the result to a different file:

ab -n 500 -c 10 -g res2.tsv {URL_to_your_env}
res1.tsvSingle application-server performance.
res2.tsvTwo application servers behind NGINX.

Compare Results with Gnuplot

Start gnuplot and configure the comparison graph:

set size 1, 1
set title "Benchmark testing"
set key left top
set grid y
set xlabel 'requests'
set ylabel "response time (ms)"
set datafile separator '\t'
plot "/home/res1.tsv" every ::2 using 5 title 'single server' with lines, "/home/res2.tsv" every ::2 using 5 title 'two servers with LB' with lines
every ::2Starts plotting from the second data row, skipping headings.
using 5Uses the fifth column containing total response time.
titleLabels each graph for comparison.
with linesDisplays each dataset as a solid line.
Result ordering: the source documentation notes that response-time results are displayed in ascending order rather than chronologically.

Expected Result

At low load, both configurations can show similar response times. As the request count increases, the single application server’s response time rises more sharply, while two application servers behind NGINX can serve more concurrent requests with better response-time behavior.

Important Notes

  • The source example uses Apache PHP and ApacheBench.
  • The control test uses one application-server instance.
  • The load-balanced test uses two application-server instances with NGINX.
  • Both tests should use identical ApacheBench parameters.
  • The documented benchmark sends 500 requests with concurrency of 10.
  • Gnuplot compares res1.tsv and res2.tsv.