Switch from epee http server to boost::beast http server. Min boost 1.70 #136
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Comments in log
There is roughly a 7.4% increase in performance in the switch to boost::beast. Additionally, the REST endpoints
/daemon_status
,/get_unspent_outs
, and/submit_raw_tx
do not block in ZMQ calls, allowing for better response times regardless ofmonerod
status.The REST endpoints
/login
and/get_random_outs
still need updates to prevent blocking (/login
is conditional on DB state).Additional Commentary
The REST endpoints
/daemon_status
,/get_unspent_outs
,/get_random_outs
,/get_unspent_outs
, and/submit_raw_tx
all require calls intomonerod
to complete. The endpoint/login
may perform blocking HTTP I/O if webhooks are configured for new accounts. Some of the values can be cached, but even then all of the mentioned endpoints could be temporarily blocked by a slow, unresponsive, or unavailablemonerod
(or slow HTTP server for/login
webhooks). This hurts throughput on the REST threads, especially the endpoints/get_address_info
,/get_address_txs
, and (sometimes)/login
which require disk I/O but no outside information.Since the default is 1 REST thread, these blocking events can give the appearance of an unresponsive REST server when it is
monerod
(or outside HTTP server) that is the source of the slowdown. This patch (begins) to alleviate the issue by making/daemon_status
,/get_unspent_outs
, and/submit_raw_tx
asynchronous when blocking I/O intomonerod
needs to be performed. While waiting formonerod
response, additional requests to the same endpoint will queue and then perform a batch response when themonerod
I/O completes. In the best case scenario, this takes 2-3 milliseconds, but can be longer for various reasons.Additionally,
/daemon_status
and/get_unspent_outs
now cachemonerod
responses for 5 seconds to reduce unnecessary burden onmonerod
. This improves the throughput of these endpoints dramatically, andwrk2
load stressing is now somewhat pointless on/daemon_status
in particular since it generates a cache response instantly.Implementation Details
A REST endpoint can now be: (1) full synchronous (all admin endpoints,
/get_address_info
,get_address_txs
, and/login
eventually), (2) partially synchronous (/daemon_status
, and/get_unspent_outs
) or (3) fully asynchronous (/get_random_outs
eventually, andget_unspent_outs
). These three possibilities help with micro-optimizations internally on performance:std::function
callbackstd::function
callback). Basically, some checks have to be done for synchronous endpoints, andstd::function
is duplicating the checks (in addition to being slightly slower in invocation).std::function
callbackThis patch doesn't have code comments describing how this works, I will most likely update this PR in the future with such information (before merging). Additionally,
/submit_raw_tx
still needs additional stress testing.Otherwise, this is a good end-of-month PR as its 99% complete.