You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some recent analysis of flame graphs and call graphs have revealed some inefficiencies that could be greatly improved:
editor::HttpContext::on_headers can take up to 75% of the Http::readable time and 30% of Http::backend_readable, mainly due to expensive formats
Kawa::as_io_slice is up to 3 times slower than Kawa::prepare and takes up to 60% of Http::backend_writable time and 25% of Http::writable due to a Vec allocation
fmt::Display of certain structs seems really expensive, taking up to 23% of total runtime (I don't know if we can avoid it, most structs come from std like SocketAddr)
It also revealed some broader problems. Here are the ones that stand out with the percentage of total time execution in an highly optimized build with no logs nor access logs:
allocation related code: 50%
on_headers: 28%
as_io_slice: 14%
realloc: 14%
fmt related code: 14%
gettime: 11%
The text was updated successfully, but these errors were encountered:
Related note even if it doesn't impact performances noticeably, the port is still separated from the authority on the Sozu size rather than kawa's. It is also done redundantly and with two different methods: once in frontend_from_request with hostname_and_port and once in log_request with split_once.
Some recent analysis of flame graphs and call graphs have revealed some inefficiencies that could be greatly improved:
editor::HttpContext::on_headers
can take up to 75% of theHttp::readable
time and 30% ofHttp::backend_readable
, mainly due to expensive formatsKawa::as_io_slice
is up to 3 times slower thanKawa::prepare
and takes up to 60% ofHttp::backend_writable
time and 25% ofHttp::writable
due to a Vec allocationfmt::Display
of certain structs seems really expensive, taking up to 23% of total runtime (I don't know if we can avoid it, most structs come from std likeSocketAddr
)It also revealed some broader problems. Here are the ones that stand out with the percentage of total time execution in an highly optimized build with no logs nor access logs:
The text was updated successfully, but these errors were encountered: