-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix timeout and concurrency layer #51
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -41,6 +41,7 @@ use { | |
}, | ||
std::{cmp::Ordering, str, sync::Arc}, | ||
tokio_stream::StreamExt, | ||
tower::limit::concurrency::ConcurrencyLimitLayer, | ||
tower_http::{ | ||
compression::CompressionLayer, | ||
cors::{Any, CorsLayer}, | ||
|
@@ -172,11 +173,17 @@ pub(crate) struct Server { | |
help = "Timeout requests after <SECONDS> seconds. Default: 30 seconds." | ||
)] | ||
timeout: Option<u64>, | ||
#[clap(long, help = "Set max concurrent connections. Default: 1024")] | ||
max_connections: Option<usize>, | ||
} | ||
|
||
impl Server { | ||
pub(crate) fn run(self, options: Options, index: Arc<Index>, handle: Handle) -> SubcommandResult { | ||
Runtime::new()?.block_on(async { | ||
log::debug!( | ||
"Starting server with {} max connections", | ||
self.max_connections.unwrap_or(1024) | ||
); | ||
let index_clone = index.clone(); | ||
|
||
let index_thread = thread::spawn(move || loop { | ||
|
@@ -276,7 +283,14 @@ impl Server { | |
.route("/tx/:txid", get(Self::transaction)) | ||
|
||
// API routes | ||
.route("/rpc/v1", post(rpc::handler)) | ||
.route("/rpc/v1", post(rpc::handler) | ||
.route_layer(TimeoutLayer::new(Duration::from_secs(self.timeout.unwrap_or(30)))) | ||
.route_layer( | ||
ConcurrencyLimitLayer::new( | ||
self.max_connections.unwrap_or(1024), | ||
) | ||
) | ||
) | ||
.layer(axum::middleware::from_fn(middleware::tracing_layer)) | ||
.layer(Extension(index)) | ||
.layer(Extension(page_config)) | ||
|
@@ -295,7 +309,6 @@ impl Server { | |
.allow_origin(Any), | ||
) | ||
.layer(CompressionLayer::new()) | ||
.layer(TimeoutLayer::new(Duration::from_secs(self.timeout.unwrap_or(30)))) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. curious: why didn't this work? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not totally sure, I suspect that the very slow requests we saw were partially due to no concurrency limit, so there were just too many threads spawned and the timeout didn't trigger at the expected time There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was able to see timeout (408 status) locally when picking a very low timeout, so it is definitely configured correctly |
||
.with_state(server_config); | ||
|
||
match (self.http_port(), self.https_port()) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for 1024? If so a comment would be nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't have a very concrete reason, just from the past we have only really seen 10 qps from the api side