Subject: Re: [boost] [http] Formal review of Boost.Http
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2015-08-12 11:04:51
> You can see that performance of Boost.Http versus Pion was roughly the
> same, but Boost.Http created no extra threads. If I used one extra thread,
> I think I could see a speedup. Also, notice that the pion example didn't
> log any output to the standard output, while the Boost.Http is printing
> everything that happens.
Thank you for the first benchmarks. I notice the Poco one is still in
The benchmarks so far (and any more that you do) are very interesting to me.
Besides a nice way to show me that Boost.Http can be used to implement
services that perform better (or no worse) than other libraries, it also
shows me how easy it is to implement the same simple service with all these
I am curious about the fact that different HTTP server libraries use
different approaches on Windows. I noticed that Casablanca, while having an
ASIO based implementation for portability, also has a HTTP.SYS based
implementation for NT. It would be pretty neat if it turns out that
Boost.Http on Windows performs equally (or really neat if it performs
better) than using the HTTP server APIs provided with the OS. Especially
when there are now other, non-performance, reasons to avoid the HTTP server
The details I would find interesting to see per benchmark (columns per
library you are comparing):
- Memory used (kilobytes)
- Non-paged pool
- CPU usage
- Throughput (send/receive bytes per second)
Casablanca, poco, cpp-netlib, proxygen and (as you've shown me in your
example code) pion provide high level HTTP abstractions. It will be nice for
me to see what your Boost.Http benchmark code looks like when it uses the
high level API you plan to write.
-- View this message in context: http://boost.2283326.n4.nabble.com/http-Formal-review-of-Boost-Http-tp4678604p4678777.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk