Cloud
Examine critical components of Cloud computing with Intel® software experts
107 Discussions

Improve Latency of NGINX in AWS using Intel’s QAT Engine for OpenSSL - Part 5 of a 5 Part Series

RajivMandal
Employee
0 0 5,633

This is Part 5 of a 5 part Series

Wecome to the 5th and final installment of our blog series covering how to significantly reduce latency of NGINX web server in AWS using Intel's QAT Engine for OpenSSL.

In this post we will cover:

  • Installing non-optimized NGINX on Machine-1
  • Installing the SSL certificate on Machine-1
  • Testing the web server to ensure it responds to https requests on port 443
  • Installing the wrk benchmark tool on the Test_Client machine
  • Performing a baseline benchmark on Machine-1 using the wrk benchmark tool
  • Performing the same benchmark test on the optimized Machine-2 using the wrk benchmark tool
  • Comparing the results and measuring the performance improvement.

You can get caught up on where we are by reading part 1, part 2, part 3 and part 4

 

Non-Optimized NGINX Installation -- Machine-1

In this section, we will set up the open-source NGINX available from apt distribution channel. Once the NGINX is set up, we will install an SSL certificate to make this a secured website. Several of the steps will be like the setup on Machine-2. The main differences in this section will be the following:

  • We will set up open-source NGINX from nginx.org instead of building the NGINX from NGINX async source code.
  • We do not need to set up the QAT engine for OpenSSL.

Setup Commands

Log in to Machine-1 via SSH as "ubuntu" user.

Run these commands in the order listed to set up NGINX on Machine-1.

# Setup NGINX on Ubuntu
sudo apt-get-update && sudo apt-get upgrade -y
sudo apt install nginx
sudo ufw app list
sudo ufw allow 'Nginx HTTP'
sudo systemctl status nginx
sudo systemctl enable nginx

 

Install the SSL Certificate on NGINX Server -- Machine-1

In this part of the setup, the NGINX server is created on Machine-1. We will install the SSL certificate and the private key in our NGINX server. The steps will be similar to setting up the SSL certificates for Machine-2. As before, we have used SSL certificates from ZeroSSL and our domain, gotoclouds.co, is hosted on GoDaddy.

When we test this NGINX web server, we will update the IP address on the A record within our hosted zone on Route 53 to be the public IP address of this NGINX web server. This will make requests made against our domain gotoclouds.co to be directed to this web server.

Pre-Requisites

To mimic a similar setup, you will need to have these pre-requisites in place. In the A record within our hosted zone on Route 53, update the IP address to the public IP address of this Machine-1 NGINX web server.

  1. Make sure your domain name resolves to the public IP address of this NGINX server Machine-1.
  2. Generate a new SSL certificate from your Certificate Authority.
  3. Download the private key and certificate files on your local system.
  4. Copy the private key from your local system to the /etc/ssl/private directory on the NGINX web server you are setting up.
  5. Copy the certificate file from your local system to the /etc/ssl/certs directory on the NGINX web server you are setting up. In our case, we had a certificate.crt file and a ca-bundle.crt file that was provided through Certificate Authority. We had to concatenate the files together and had to rename the concatenated file as certificate.crt. In the concatenation process, the certificate.crt file went first and the ca_bundle.crt file went after that. We used a command line like the one below.
# Run this command as root
cat certificate.crt ca_bundle.crt >> certificate.crt

 

Configuration Update in NGINX.conf file

Open the nginx.conf file in the editor and paste in the configurations from this example non_optimized_nginx.conf. Note this example configuration will NOT have the QAT engine module enabled.

sudo nano /etc/nginx/nginx.conf

 

Inside the nginx.conf file, there are a few places where the domain name needs to be updated. In the example nginx.conf, the domain name is gotoclouds.co. You will need to update the domain names with your domain_name. Below are the places in the nginx.conf file where this needs to be updated.

image7A.png

 Image: The places to update the file are highlighted in red.

 

Image7B.png

  Image: The places to update the file are highlighted in red.

After making the changes, save the file and exit using <CTRL>+X, then Y, then press Enter.

Create the following folder structure in your NGINX web server. The domain_name in the path below should be replaced with the name of your own domain.

sudo mkdir /var/www/domain_name/html

 

Open an editor to paste the below html into the index.html file. The command to edit the index.html file and the html is provided.

sudo nano /var/www/domain_name/html/index.html
<h1><strong>This is a test page for NON-OPTIMIZED NGINX Web Server. This page is
being served securely over HTTPS</strong></h1>
<p>&nbsp;</p>
<p><em><strong>THANK YOU FOR VISITING !!</strong></em></p>

 

Restart NGINX service

sudo systemctl restart nginx

 

Test the Domain Using https://

Test to see the secured web page is working. Open a browser and put the URL as https://domain_name. Change the domain name to your domain name. You should be able to see the secured web like the sample below.

Note: In order to hit the NGINX web server from your browser, enable the http (port 80) and https (port 443) on Machine-1's EC2 security group from the source IP which is the machine on which you will launch the browser.

image8.png

 

Set Up the Test Client

In this section, we will setup the test client. We will install an http/https benchmark took called wrk from https://github.com/wg/wrk.git which will be used to test the https website. Run the setup instructions as given below. Before running the commands below, SSH into the test client machine called Test Client as “ubuntu” user.

#Setup the test client
sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install build-essential libssl-dev git -y
sudo apt-get install unzip
git clone https://github.com/wg/wrk.git wrk
cd wrk
make
# move the executable to somewhere in you PATH, ex:
sudo cp wrk /usr/local/bin
export PATH=/usr/bin:$PATH

 

Test wrk for an https endpoint

On the command prompt terminal for the Test Client machine, run the following command:

wrk -t5 -c55 -d5 --latency https://google.com

 

The -t5 means it will execute 5 threads. The -c55 means it will open 55 concurrent connections. The -d5 means it will perform the test for duration of 5 seconds. The –latency flag means it will print detailed latency statistics. The output should look like this:

image9.png

 

Benchmark Non-0ptimized NGINX Web Server

On the Route 53 hosted zone you created, check to confirm that the A record is configured to be the public IP address of Machine-1.

Log into the Test_Client EC2 instance using SSH as "ubuntu" user.

On the command prompt run the command to install dnsutil.

sudo apt-get install dnsutils

 

Run the dig command to confirm that your domain is resolving to the public IP address of Machine-1. Sometimes due to propagation delay this can take a while. In the command below change the domain_name with your own domain name.

dig domain_name

 

Run the test for using the wrk tool to benchmark the Machine-1 NGINX web server. Replace the domain_name in the command below with your own domain name. The -t8 means the tool will generate 8 threads. -c750 means there will be 750 concurrent connections. -d1m means the test will run for 60 seconds or 1 minute. –latency flag means it will generate detailed latency statistics.

# Run the command wrk -t8 -c750 -d1m --latency https://domain_name
# Change the domain_name to your own domain name. The below line of
# code shows the example we used for our domain
wrk -t8 -c750 -d1m --latency https://gotoclouds.co

 

The results look like below. This is the result from our example domain gotoclouds.co that is pointing to Machine-1.

image10.png

 

In the results above, the P99 latency is 255.23 milliseconds and the number of requests per seconds is 2006.75.

Benchmark Optimized NGINX Web Server

On the Route 53 hosted zone you created, check to confirm that the A record is configured to be the public IP address of Machine-2. If not, edit the A record to change it to the Machine-2 public IP address.

Log into the Test_Client EC2 instance using SSH as "ubuntu" user.

Run the dig command to confirm that your domain is resolving to the public IP address of Machine-2. Sometimes due to propagation delay this can take a while. In the command below, change the domain_name with your own domain name.

dig domain_name

 

Run the test for using the wrk tool to benchmark the Machine-2 NGINX web server. This web server’s NGINX is optimized based on Intel QAT engine for OpenSSL. Replace the domain_name in the command below with your own domain name. The -t8 means the tool will generate 8 threads. -c750 means there will be 750 concurrent connections. -d1m means the test will run for 60 seconds or 1 minute. –latency flag means it will generate detailed latency statistics.

# Run the command wrk -t8 -c750 -d1m --latency https://domain_name
# Change the domain_name to your own domain name. The below line of
# code shows the example we used for our domain
wrk -t8 -c750 -d1m --latency https://gotoclouds.co

 

The results look like below This is the result from our example domain gotoclouds.co that is pointing to Machine-1.

image11.png

 

In the results above, the P99 latency is 215.88 milliseconds and the number of requests per second is 2037.13.

 

Comparing Results

The Intel optimized NGINX web server has:

  • Reduced P99 latency by approximately 18%.
  • Increased number of requests per second by approximately 2%.

Conclusion

In this blog series, we see that the Intel-optimized NGINX web server based on QAT engine for OpenSSL on 3rd Gen Intel Xeon Scalable processors improves web server performance by reducing P99 latency by approximately 18%. This is based on the new Crypto-NI instructions that are now embedded within the 3rd Gen Intel Xeon Scalable processor itself. This will significantly improve your web server performance.

Our example used infrastructure in AWS. The benefits demonstrated here can be replicated on 3rd Gen Intel Xeon Scalable processors in various environments, including other AWS instances with '6i' in the name, on-premises, in private clouds, and other public cloud environments as well.

Important Note: Please remember to destroy and delete the AWS resources created to avoid incurring charges.

 

Next Steps for Your Success

  1. Identify a web server application in your environment that can take advantage of this optimization.
  2. Evaluate and try this in your own environment.
  3. Identify the requirements to perform a POC for a suitable use case in your workloads.
  4. Reach out to your Intel team for any help and support needed.

Additional Benchmark References for NGINX web servers on AWS:

Choose AWS C6i or R6i Instances Featuring 3rd Gen Intel Xeon® Scalable Processors for up to 3.65 times the NGINX Performance

Handle Up to 3.05 Times the NGINX Connections with AWS C6i or R6i Instances Featuring 3rd Gen Intel® Xeon® Scalable Processors with Crypto Acceleration

Achieve up to 2.67 Times the NGINX Performance with AWS EC2 Instances Enabled by 3rd Gen Intel Xeon Scalable Processors

Even More Benchmarks...

Other Supporting Reference and Resources