[PoC2] RESTful Web Services on Fire

After installing NGINX on an EC2 instance and implementing an http-requester for generating high load requests to test it, It’s time to serve some cool RESTful web services and to make the PoC’s face more to the ground.

Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server.

For handling high throughput on REST web services, I favoured Netty, which also integrates with REST frameworks like RESTEasy. I also took a look at Apache CXF’s Netty support but thanks to their well-organized! and awesome! documentation, couldn’t find any clue about if they’ve implemented such a thing or not. Netty provides non-blocking IO so my assumption was to have a high throughput value when my client stressed under heavy load.

Speaking of client, I implemented a hello world REST service that utilizes Netty and RESTEasy under the hood, which is named netty-rest-simple. I created a fat jar out of it by the help of maven shade plugin. My machine setup was like, having my REST client installed on one EC2 instance and having http-requester installed on another. The AMI that is used for both of those setups was: ami-a8221fb5 and the instance type was: m4.xlarge.

http-requester is invoked with following parameters. Notice that the internal IP’s of the instances are being used for better performance. Also instances are sit on top of a private VPC and they are also placed into a placement group.

java -jar http-requester-0.0.1.jar 10.0.0.61 8080 1000000 1000000 200

Here are the results:

1277 req/sec
2155 req/sec
2224 req/sec
2364 req/sec
2615 req/sec
2880 req/sec
2910 req/sec
3060 req/sec
3302 req/sec
3568 req/sec
3621 req/sec
3569 req/sec
3699 req/sec
3799 req/sec
3870 req/sec
3759 req/sec
3728 req/sec
3873 req/sec
3796 req/sec
3832 req/sec
3918 req/sec
3855 req/sec
3876 req/sec
3874 req/sec
3920 req/sec
4283 req/sec
4707 req/sec
4873 req/sec
4991 req/sec
5294 req/sec
5907 req/sec
6716 req/sec
7425 req/sec
7490 req/sec
8114 req/sec
8706 req/sec
9351 req/sec
9674 req/sec
9895 req/sec
10083 req/sec
9926 req/sec
10338 req/sec
12211 req/sec
12924 req/sec
13324 req/sec
13656 req/sec
14025 req/sec
14481 req/sec
14857 req/sec
14598 req/sec
14819 req/sec
14556 req/sec
15291 req/sec
15639 req/sec
15772 req/sec
16000 req/sec
16849 req/sec
16269 req/sec
15952 req/sec
16051 req/sec
17111 req/sec
17040 req/sec
18276 req/sec
19209 req/sec
20311 req/sec
21104 req/sec
20413 req/sec
21559 req/sec
21620 req/sec
21302 req/sec
21292 req/sec
21408 req/sec
20772 req/sec
21282 req/sec
20862 req/sec
20972 req/sec
21679 req/sec
21297 req/sec
21087 req/sec
21271 req/sec
21419 req/sec
20766 req/sec
21358 req/sec
21176 req/sec

The numbers are saturated at 20k-21k/sec, which looks good for a simple REST web service. When I did top on the server instance I saw that the CPU utilization is at %100. So it’s obvious that we created a bottleneck on the CPU.

So I tried m4.2xlarge, which doubles the previous hardware. My client again consumed all the juice and its results were as follows:

2884 req/sec
5010 req/sec
5984 req/sec
6710 req/sec
7110 req/sec
7147 req/sec
7771 req/sec
7679 req/sec
8876 req/sec
13118 req/sec
15043 req/sec
16692 req/sec
18035 req/sec
19903 req/sec
22182 req/sec
23238 req/sec
24391 req/sec
24869 req/sec
24769 req/sec
25232 req/sec
25458 req/sec
25389 req/sec
25075 req/sec
26179 req/sec
27508 req/sec
32490 req/sec
36415 req/sec
37547 req/sec
36767 req/sec
37473 req/sec
37562 req/sec
37470 req/sec
36816 req/sec
37482 req/sec
37442 req/sec
37465 req/sec
37461 req/sec
36908 req/sec
37451 req/sec

Numbers are saturated at 37k/sec, which is quite satisying. With this setup again my client sucked up all CPU power, it was around %90.