Served; Build RESTful C++ servers

Served is a C++ library for easy creation of highly performant web servers. It presents a clean and elegant modern C++ interface, drastically reducing the amount of boiler-plate code that would normally be needed. Overall, it looks very promising for when you want everything to just work, without compromising on performance. Now, let’s dive right into it.

Getting To Hello World

Getting started is fairly standard for a from-source installation, you can also opt to compile it into a deb or rpm package via the build flags. Running the following commands installs served on your system. This installation requires Boost 1.53 or newer, if you do not have Boost installed on your system, you can install it using your favorite package manager or by following these instructions.

git clone https://github.com/meltwater/served.git
mkdir served/served.build && cd served/served.build
cmake ../served && make
sudo make install

Now, that you have it installed, it is time to build a simple webserver. This server will just give back “Hello world!” when you query against the endpoint GET /hello.

#include <served/served.hpp>

int main() {
 served::multiplexer mux;

 mux.handle("/hello")
  .get([](served::response & res, const served::request & req) {
   res << "Hello world!\n";
  });

 served::net::server server("0.0.0.0", "8080", mux);
 server.run(10);

 return 0;
}

To compile your program, you will need to link against the pthread, boost_system, and served shared objects, and use at least C++-11. On Linux, this would look roughly like the following.

g++ main.cpp -o demo -std=c++17 -pthread -lboost_system -lserved

Just run the binary and visit the URL http://localhost:8080/hello in your browser, and you have successfully reached the hello-world. All of the code for this demo is available on github.

Performance

Let’s take a quick look at the performance of C++ Served. At only 60k, the output binary from that demo is surprising small on my system. Of course, this is not the statically linked binary size. For this benchmark, we will be using Vegeta for load testing.

Requests      [total, rate, throughput]    99999, 20000.17, 19057.02
Duration      [total, attack, wait]        5.000256833s, 4.999908146s, 348.687µs
Latencies     [mean, 50, 90, 95, 99, max]  2.539834ms, 375.457µs, 7.240899ms, 8.184653ms, 38.421652ms, 1.691368283s
Bytes In      [total, mean]                1238770, 12.39
Bytes Out     [total, mean]                0, 0.00
Success       [ratio]                      95.29%
Status Codes  [code:count]                 0:4709  200:95290  

On my machine (Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz 16 threads), the basic hello world server was able to handle around 19,000 requests per second! Additionally, it was able to maintain relatively low CPU usage during this attack, using only ~30% of the capacity available to it.

Requests      [total, rate, throughput]    150000, 30000.10, 14094.09
Duration      [total, attack, wait]        7.948649187s, 4.999982507s, 2.94866668s
Latencies     [mean, 50, 90, 95, 99, max]  9.756488ms, 5.137985ms, 7.529834ms, 7.989994ms, 51.273487ms, 6.782636245s
Bytes In      [total, mean]                1456377, 9.71
Bytes Out     [total, mean]                0, 0.00
Success       [ratio]                      74.69%
Status Codes  [code:count]                 0:37971  200:112029 

As the request rate increases above 20k, the performance started to degrade. Here, it seems like 20k requests per second is the sweet spot. Despite this, the performance of the library is very satisfactory under the given load. The majority of requests took under 1ms when it was under the 20k stress test. This should be more than enough to meet the needs of all but the most extreme demands.