Testing Load Balancing

Objective

This guide explains how to use Testing Load Balancing on Ruk-Com Cloud PaaS, with ordered procedures and practical verification points.

Before you begin

• Sign in with an account permitted to manage the relevant environment.
• Confirm the target environment, region and resources before saving changes.
• Create a backup or rollback plan before changing a production system.

When your project is in demand and has many visitors. You will face a problem – the need to optimize hardware performance. Because it should be able to quickly handle and respond to all incoming user requests. Adding additional resources will temporarily improve performance in that situation. Helps protect servers from failure. But it will not be able to solve the problem that is causing it. and results in the need to setclustering solutionwith automatic load balancing built in

Deploying an application cluster is relatively easy using Ruk-Com Cloud. Just add a few application server instances to your environment. You will also launch the server. NGINX-balancer automatically in the project page section It is responsible for distributing the load evenly among the specified number of app server nodes. This is done using load balancing.

This way, your application's performance will be greatly increased by increasing the number of requests that can be served at a single time. It's a nice bonus that you can reduce the risk of not being able to access the app if one server fails. But all the rest will continue to work.

To prove that this project is effective We'll show you how to test load balancing with the help of the link # ApacheBench (ab) tool. There are several possibilities for testing a server's ability to cope with increasing and changing loads. Although ab is designed for testing Apache installations, it can also be used to compare different HTTP servers.

Let's get started and test it in real time.

Create Environment and Deploy Applications

1. Log in to the Ruk-Com Platform and click the button.Create environmentin the upper left corner of the dashboard.

2. The Environment topology dialog window appears immediately. You can choose the programming language. required applications/web servers and databases

As we are going to load test the Apache PHP server, select and specify the resource usage limit using the cloudlets slider, then attach the Public IP address for this server and type the name of the new Env (e.g. balancer). Click Create.

3. In just a few minutes your Env will appear on the dashboard.

4. Once the Env is created, you can deploy your application. We will use the package HelloWorld.zip is the default Therefore, you just need to deploy (deploy) to the desired Env with the corresponding button and confirm the deployment (deploy) in the open frame.

Control Point Test

To analyze the results, you will need something to compare with. So let's do some control point testing using an environment created as a single node application server.

As mentioned above, we will use the toolApacheBench (ab)for these purposes A single-threaded load can be created by sending a specified number of concurrent requests to the server.

So, follow the steps below.

1. ApacheBench is part of the standard Apache source distribution, so if you don't have it yet, Use the following command via terminal. (Or skip this step if you have one.)

apt-get install apache2-utils

Wait until the installation is complete.

Note:
You can see more detailed information about the ab command used at this link.

2. Enter this next line in the terminal:

ab -g res1.tsv -n 500 -c 10 {URL_to_your_env}

Replace the {URL_to_your_env} section with the link to your Env (e.g. in our case,http://balancer.app.Ruk-Com.cloud/) To get it, click the Open in Browser button next to Env and copy the relevant URL from your browser's address bar.

The specified command will send a total of 500 requests to the specified Env, divided into batches of 10 concurrent requests at one time. All results are stored in the res1.tsv file within your home folder (or enter the full path to the desired directory if you want to change the file location).

You can also specify custom parameters for the commands mentioned above if you want.

This test may take some time depending on the set parameters, so please be patient.

3. The resulting generated file should look like the image below.

Change Environment settings

1. Return to the Ruk-Com Cloud dashboard and click Change environment topology for your environment balancer.

2. Within the opened Environment topology box, add additional application servers (for example, add another Apache instance) - use the + button in the section.Horizontal scaling wizardThen enable the Public IP property and specify a resource limit for the node.NGINX-balanceradded automatically As this will become the starting point of your application, select Apply to continue.

3. When all required changes have been successfully implemented. You should disable sticky sessions for the balancer server, otherwise all requests from that IP address will be redirected to the same instance of the application server.

So click the Config button next to the Nginx node.

4. Go to fileconf > nginx-jelastic.confcannot be edited So copy all the content and paste it into the file.nginx.conf(in the same folder) instead of merging/etc/nginx/nginx-jelastic.conf; Along the lines (circled in the following picture)

5. Then find the two sticky path parameters in the code (in the DEFAULT UPSTREAM and UPSTREAMS LIST sections) and comment them out as shown below.

Note:
Be sure to include closing braces after the sticky path string, and it should not be commented out.

6. Save the applied changes and restart the server.NGINX

Balancer test and compare results

1. Switch back to your terminal and run the ab test again with the same parameters. (Except for files whose output is –, specify a different name, such as res2.tsv)

ab -g res2.tsv -n 500 -c 10 {URL_to_your_env}

Now let's proceed with the load balancing test directly.

2. To clarify the results, we will use the data from res1.tsv and res2.tsv files, import them into a spreadsheet and plot the graphs.

Similar to the following picture:

Because of the options listed, the blue graph shows the performance of a single Apache server without a balancer (control point test results) and the red server. It will be two servers with NGINX load balancers (second test results).

Note:The received testing results (response time for each sent requests) are shown in the ascending order, i.e. not chronologically.

Note:
Test results received Response times (response time for each request sent) are displayed in ascending order, that is, not in chronological order.

As you can see, while serving low load, the performance of both configurations is almost the same. But as the number of requests increases, the response time for environments with single-app server instances increases significantly, resulting in fewer requests being served at the same time. So if you expect high load on your application server, increasing the number of instances in your bundle with a server balancer is the best way to keep your customers happy.

Enjoy all the advantages of the cloud!