Setting up the server

The following configuration sums up all the changes proposed in the preceding sections:

worker_processes 3;
worker_rlimit_nofile 8000;

events {
  multi_accept on;
  use epoll;
  worker_connections 1024;
}

http {
  sendfile on;
  aio on;
  directio 4m;
  tcp_nopush on;
  tcp_nodelay on;
  # Rest Nginx configuration removed for brevity
}

It is assumed that NGINX runs on a quad core server. Thus, three worker processes have been spanned to take advantage of three out of four available cores and leaving one core for other processes.

Each of the workers has been configured to work with 1,024 connections. Correspondingly, the nofile limit has been increased to 8,000. By default, all worker processes operate with mutex; thus, the flag has not been set. Each worker processes multiple connections in one go using the epoll method.

In the http section, NGINX has been configured to serve files larger than 4 MB using direct I/O, while efficiently buffering smaller files using Sendfile. TCP options have also been set up to efficiently utilize the available network.

Measuring gains

It is time to test the changes and make sure that they have given performance gain.

Run a series of tests using Siege/JMeter to get new performance numbers. The tests should be performed with the same configuration to get a comparable output:

$ siege -b -c 790 -r 50 -q http://192.168.2.100/hello

Transactions:               79000 hits
Availability:               100.00 %
Elapsed time:               24.25 secs
Data transferred:           12.54 MB
Response time:              0.20 secs
Transaction rate:           3257.73 trans/sec
Throughput:                 0.52 MB/sec
Concurrency:                660.70
Successful transactions:    39500
Failed transactions:        0
Longest transaction:        3.45
Shortest transaction:       0.00

The results from Siege should be evaluated and compared to the baseline. The following conclusions are derived while comparing the new numbers with the numbers generated in Chapter 2, Benchmarking the Server:

  • Throughput: The transaction rate defines this as 3250 requests/second
  • Error rate: Availability is reported as 100 percent; thus; the error rate is 0 percent
  • Response time: The results show a response time of 0.20 seconds

Thus, these new numbers demonstrate performance improvement in various respects.

Tip

After the server configuration is updated with all the changes, reperform all tests with increased numbers. The aim should be to determine the new baseline numbers for the updated configuration.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.220.237.24