Re: Question about Maglev algorithm
On Fri, Dec 28, 2018 at 07:55:11PM +0100, Aleksandar Lazic wrote: > Well as far as I understood the pdf one of the biggest difference is that > Maglev is a distributed system where the consistent hash is for local system. No, not at all. The difference is that it's designed for packet processing so they have to take care of connection tracking and per-packet processing cost. From what I've read in the paper, it could be seen as a subset of what we already do : - server weights are not supported in Maglev (and very likely not needed) - slow start is not supported - server insertion/removal can be extremely expensive (O(N^2)) due to the way they need to build the hash table for fast lookup - no possibility for bounded load either It's really important to understand the different focus of the algorithm, being packet-oriented instead of L7-oriented. This explains a number of differences and choices. I think Maglev is excellent for what it does and that our mechanism wouldn't be as fast if used on a per-packet basis. But conversely, we already do the same and even much more by default because we work at a different layer. Willy
htx with compression issue, "Gunzip error: Body lacks gzip magics"
Hi List,
When using compression with htx, and a slightly delayed body content it
will prefix some rubbish and corrupt the gzip header..
Below output i get with attached test.. Removing http-use-htx 'fixes'
the test.
This happens with both 1.9.0 and todays commit a2dbeb2, not sure if this
ever worked before..
c1 0.1 len|1A\r
c1 0.1
chunk|\222\7\0\0\0\377\377\213\10\0\0\0\0\0\4\3JLJN\1\0\0\0\377\377
c1 0.1 len|0\r
c1 0.1 bodylen = 26
** c1 0.1 === expect resp.status == 200
c1 0.1 EXPECT resp.status (200) == "200" match
** c1 0.1 === expect resp.http.content-encoding == "gzip"
c1 0.1 EXPECT resp.http.content-encoding (gzip) == "gzip" match
** c1 0.1 === gunzip
c1 0.1 Gunzip error: Body lacks gzip magics
Can someone take a look? Thanks in advance.
Regards,
PiBa-NL (Pieter)
# Checks htx with compression and a short delay between headers and data send
by the server
varnishtest "Connection counters check"
feature ignore_unknown_macro
server s1 {
rxreq
txresp -nolen -hdr "Content-Length: 4"
delay 0.05
send "abcd"
} -start
haproxy h1 -conf {
global
stats socket /tmp/haproxy.socket level admin
defaults
mode http
option http-use-htx
frontend fe1
bind "fd@${fe1}"
compression algo gzip
#filter trace name BEFORE-HTTP-COMP
#filter compression
#filter trace name AFTER-HTTP-COMP
default_backend b1
backend b1
server srv1 ${s1_addr}:${s1_port}
} -start
# configure port for lua to call fe4
client c1 -connect ${h1_fe1_sock} {
txreq -url "/" -hdr "Accept-Encoding: gzip"
rxresp
expect resp.status == 200
expect resp.http.content-encoding == "gzip"
gunzip
expect resp.body == "abcd"
} -run
Re: Question about Maglev algorithm
Well as far as I understood the pdf one of the biggest difference is that Maglev is a distributed system where the consistent hash is for local system. What I think is if consistent hash uses the peers table for balancing it could be similar to Maglev, but I'm not a algo expert, just an Idea. I don't know if it's have any benefits for haproxy, I have seen this algo on envoy site and wanted to know what the experts here means about it :-) https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/load_balancers Regards Aleks Ursprüngliche Nachricht Von: Aaron West Gesendet: 28. Dezember 2018 19:36:03 MEZ An: HAProxy Betreff: Re: Question about Maglev algorithm I've not used it yet with IPVS because I have nothing with a new enough Kernel (4.18+ I think), however, isn't this quite similar to HAProxy's consistent hash options? Aaron Loadbalancer.org
Re: Question about Maglev algorithm
I've not used it yet with IPVS because I have nothing with a new enough Kernel (4.18+ I think), however, isn't this quite similar to HAProxy's consistent hash options? Aaron Loadbalancer.org
Re: Question about Maglev algorithm
On Fri, Dec 28, 2018 at 07:11:24PM +0100, Aleksandar Lazic wrote: > Have anyone take a look into the Maglev algorithm ? > > This paper looks very interesting > https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf Seems to be in IPVS already: https://github.com/torvalds/linux/blob/master/net/netfilter/ipvs/ip_vs_mh.c -- Valentin
Question about Maglev algorithm
Hi. Have anyone take a look into the Maglev algorithm ? This paper looks very interesting https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf Regards Aleks
Tweet about Facebook's implementation and deployment of QUIC
Hi. I just have seen this tweet, maybe it's also interesting for you. Subodh Iyengar (@__subodh) twitterte um 10:18 nachm. on Mi., Dez. 26, 2018: Slides for my presentation at ACM conext on Facebook's implementation and deployment of QUIC are now live https://conferences2.sigcomm.org/co-next/2018/slides/epiq-keynote.pdf . I presented some numbers on latency reductions we've seen so far as well as the new load balancing infrastructure we've built for QUIC. (https://twitter.com/__subodh/status/1078037284908261377) Regards Aleks
