Performance issue with Balsa Parser

[zhxie]

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.

# 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

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?

[RyanTheOptimist]

cc: @bencebeky @birenroy

[RyanTheOptimist]

cc: @diannahu

[github-actions]

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.

[github-actions]

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.