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
Since we are going to migrate from http-parser to Balsa Parser (#21245, #28896), I did some quick benchmarking recently and found that Balsa Parser is 10% slower than the current http-parser implementation, though it claims to have similar performance.
# http-parser
All done 5496764 calls (plus 64 warmup) 3.493 ms avg, 18322.5 qps
# Balsa Parser
All done 5058443 calls (plus 64 warmup) 3.795 ms avg, 16861.4 qps
The benchmarking is performed with Envoy running in a pinned single thread, echoing back 1kB headers with Fortio from 64 concurrent connections, no filter except HCM and HTTP router, full CPU load.
I also made a draft commit with llhttp implementatoin, a successor of http-parser, which has been mentioned a lot of times, e.g., #5155, #9033 and #15814. The result looks good.
# http-parser
All done 5496764 calls (plus 64 warmup) 3.493 ms avg, 18322.5 qps
# llhttp
All done 5626763 calls (plus 64 warmup) 3.412 ms avg, 18755.8 qps
I know that enable Balsa Parser will let us support some requested features, do you think we can add an API option to support different parsers instead of using runtime guard to introduce a new one and deprecate the old one?
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.
Title: Performance issue with Balsa Parser
Description:
Since we are going to migrate from http-parser to Balsa Parser (#21245, #28896), I did some quick benchmarking recently and found that Balsa Parser is 10% slower than the current http-parser implementation, though it claims to have similar performance.
The benchmarking is performed with Envoy running in a pinned single thread, echoing back 1kB headers with Fortio from 64 concurrent connections, no filter except HCM and HTTP router, full CPU load.
I also made a draft commit with llhttp implementatoin, a successor of http-parser, which has been mentioned a lot of times, e.g., #5155, #9033 and #15814. The result looks good.
Note that I did not exactly follow the What are best practices for benchmarking Envoy? article when collecting this benchmarking data.
I know that enable Balsa Parser will let us support some requested features, do you think we can add an API option to support different parsers instead of using runtime guard to introduce a new one and deprecate the old one?
The text was updated successfully, but these errors were encountered: