Skip to content
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.

Sign up for GitHub

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

Jump to bottom

investigate http2 performance under chaos testing under 3% packet loss #2632

Closed
jmarantz opened this issue Feb 16, 2018 · 4 comments
Closed

investigate http2 performance under chaos testing under 3% packet loss #2632

jmarantz opened this issue Feb 16, 2018 · 4 comments
Labels
area/perf

Comments

@jmarantz
Copy link
Contributor

Description:
Dan Tehranian wote in a twilio blog post "Discovering Issues with HTTP/2 via Chaos Testing". About how packet loss creates a latency spike in Envoy under HTTP/2

I haven't dived into this deeply yet, but I wanted to capture the issue so it doesn't get lost.

Relevant Links: https://www.twilio.com/blog/2017/10/http2-issues.html
@tehranian
Copy link
Contributor

👀

@mattklein123
Copy link
Member

@jmarantz FYI this behavior is inherent in the HTTP/2 protocol and there is not very much that Envoy can do to improve the situation. The only thing that would help, which I have considered in the past, is allowing the HTTP/2 connection pool to create > 1 connection per upstream hosts. So basically at the cost of memory a user could reduce HOL blocking issues if they desire. I guess we can use this issue to track that?

@alyssawilk
Copy link
Contributor

(will be) Fixed by #2557 ;-)

@mattklein123
Copy link
Member

Going to close this for now as I don't think this is actionable. We are tracking both the QUIC work as well as other items for having multiple h2 connections per upstream host which are both ways around this issue.

jpsim pushed a commit that referenced this issue Nov 28, 2022
@RyanTheOptimist @jpsim
Use safe_malloc instead of new when creating new_envoy_map_entry (#2632)
f0f7a7d 
Use safe_malloc instead of new when creating new_envoy_map_entry
since release_envoy_map uses free instead of delete. Found when
building this code internally with some sort of strict checking enabled

Signed-off-by: Ryan Hamilton rch@google.com

Risk Level: Low
Testing: Existing tests
Docs Changes: N/A
Release Notes: N/A

Signed-off-by: JP Simard <jp@jpsim.com>
jpsim pushed a commit that referenced this issue Nov 29, 2022
@RyanTheOptimist @jpsim
Use safe_malloc instead of new when creating new_envoy_map_entry (#2632)
2468f81 
Use safe_malloc instead of new when creating new_envoy_map_entry
since release_envoy_map uses free instead of delete. Found when
building this code internally with some sort of strict checking enabled

Signed-off-by: Ryan Hamilton rch@google.com

Risk Level: Low
Testing: Existing tests
Docs Changes: N/A
Release Notes: N/A

Signed-off-by: JP Simard <jp@jpsim.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/perf
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tehranian @jmarantz @mattklein123 @alyssawilk