Getline/header parsing is very inefficient

[Mic92]

It reads one byte from the stream:

cpp-httplib/httplib.h

Line 2133 in a58f042

auto n = strm_.read(&byte, 1);

This triggers one select + recv() system call on linux for each byte.

[Mic92]

I also don't understand why there is a select for a single socket. Why not just block on the socket and use read?

[yhirose]

@Mic92, sorry that this library doesn't meet your performance requirement. Let me explain the background of this library a bit. This library started to provide a solution to embed HTTP functionalities in desktop applications at my workplace. The performance wasn't a priority, rather I focused on how easily the HTTP client/server capabilities can be added to applications. That's why I keep this library as a simple single header-only library.

This triggers one select + recv() system call on linux for each byte.

You are absolutely right. If there is an easy way to do buffering in SocketStream class, I think we can reduce the recv and select calls with a small change just within the class. (I believe SSLSocketStream::read is ok, because it uses OpenSSL BIO underneath.) I don't have time to work on the improvement right now, but I would very much appreciate if you could work on it and send a pull request. :)

I also don't understand why there is a select for a single socket. Why not just block on the socket and use read?

I was trying to provide a reliable socket 'time out' detection. I tried some different ways, but select was the most reliable way working on various operating systems. If you have a better idea which is guaranteed to work on Windows, Mac and Linux OSs, please let me know. (You can also see how we got to this solution in the past issues and unit test cases.)

If you need a performance intensive cross-platform HTTP functionality, why not use drogon instead?

Thank you for bring the attention to this matter!

[Mic92]

fair enough. Drogon it is. Using socket option one can usually set timeouts on connections.

[yhirose]

Using socket option one can usually set timeouts on connections.

cpp-httplib/httplib.h

Line 2595 in a58f042

setsockopt(sock2, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(tv));

But some socket options like SO_RCVTIMEO above don't work or aren't stable as they advertise on some OSs. That's the real world unfortunately...
#34 (comment)

Even select isn't perfect for all the situations. So sometimes, users need to chose poll with CPPHTTPLIB_USE_POLL for timeout.

[yhirose]

@Mic92, approximately how much slower do you think this library is than other HTTP libraries? Is it very much noticeable in any cases, or only on some situations where the performance is really critical? Thanks for you comment since I don't have any experience of using other HTTP libraries. :)

[Mic92]

I don't have very complex applications written for cpp-httplib,
but let's just do this simple comparison with go http server from the standard library:

package main

import (
    "fmt"
    "log"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello world!")
}

func main() {
    http.HandleFunc("/some/random/url/lets/see/how/it/goes", handler)
    log.Fatal(http.ListenAndServe(":1234", nil))
}

#include "httplib.h"

int main() {
    using namespace httplib;
    Server svr;
    svr.Get("/some/random/url/lets/see/how/it/goes", [](const Request &req, Response &res) {
      res.set_content("Hello World!", "text/plain");
    });
    svr.listen("localhost", 1234);
}

And benchmark with wrk:

$ wrk http://localhost:1234/some/random/url/lets/see/how/it/goes

Result for cpp-httplib:

Running 10s test @ http://localhost:1234/some/random/url/lets/see/how/it/goes
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   342.05us    5.20ms 202.06ms   99.81%
    Req/Sec    26.13k     4.31k   37.27k    66.00%
  519796 requests in 10.00s, 51.95MB read
Requests/sec:  51973.49
Transfer/sec:      5.19MB

Result for golang:

Running 10s test @ http://localhost:1234/some/random/url/lets/see/how/it/goes
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    60.79us  127.00us   9.54ms   96.16%
    Req/Sec   102.96k     9.79k  122.31k    62.38%
  2067862 requests in 10.10s, 254.40MB read
Requests/sec: 204752.15
Transfer/sec:     25.19MB

I am surprised it's only 4 times slower on my laptop with an 8 hyper-threads i7... I think it becomes slower as soon as you start adding a real-world amount of headers and browser cookies. I mean yeah compared to some python server it's probably still some magnitudes faster, however I don't think a classical select + read http server would be more code than the current implementation.

Chears.

[yhirose]

@Mic92, thanks for the very helpful information. When I have time, I'll try to implement buffering in SocketStream to increase performance. Thanks for your fine contribution!