
HAProxy 1.8 - phil21
https://www.haproxy.com/blog/whats-new-haproxy-1-8/
======
gregmac
> HAProxy is staying true to its principle of not accessing the disks during
> runtime and so all objects are cached in memory. The maximum object size is
> as big as the value of the global parameter “tune.bufsize”, which defaults
> to 16KB. > This is a general-purpose caching mechanism that makes HAProxy
> usable as a small object accelerator in front of web applications or other
> layers like Varnish. The cool thing here is that you can control how large
> the objects to cache and accelerate delivery should be.

If this is on a server with a few GB RAM, is there any reason not to use it as
the only cache? Is there any reason not to set the bufsize to a few MB, for
example (assuming memory is not a constraint)?

I have a somewhat complex setup with several micro services each served by a
dynamic set of backends. Caching for some of it would be nice, but I couldn't
figure out a way to use varnish (or other external cache) without ending up
with 1 varnish instance per backend (a pain to maintain), introducing a single
point of failure (one per service - and still a pain to maintain), or losing
some of the benefit and power of haproxy as a frontend (with varnish in front
of it).

~~~
bpineau
Also, I understand we can configure the objects max size (with tune.bufsize).
But can we configure the whole cache size (ie. the number of tune.bufsize KB
cached objects) ?

~~~
wtarreau
Yes, it's using a similar shctx to ssl, I just don't know how to configure it
for now, let's wait for William to push a bit of doc first :-)

------
KeybInterrupt
HTTP2, Multithreading and finally no more lost TCP Connections on Service
Reload!

Awesome! Thank you!

~~~
Touche
HTTP2 on the frontend only though, a bit disappointing

~~~
latch
AFAIK, this is true of nginx also and from what I've heard in the past, they
see no reason to change it.

I can't find it now, but I'm sure they had pretty compelling benchmarks that
showed that with keepalive & low-latency networks, performance wise, there's
little, if any, performance difference.

~~~
thresh
> AFAIK, this is true of nginx also and from what I've heard in the past, they
> see no reason to change it.

http2 backends support is on the roadmap
[https://trac.nginx.org/nginx/roadmap](https://trac.nginx.org/nginx/roadmap)
\- so you can expect it to be implemented.

------
tamalsaha001
This is really great news for those of us who use HAProxy as an Ingress
controller in Kubernetes. Thank you @wtarreau and your team.

Disclaimer: We develop
[https://github.com/appscode/voyager](https://github.com/appscode/voyager)
which is a HAProxy based ingress controller for Kubernetes.

------
tomfitz
[https://www.haproxy.com/blog/dns-service-discovery-
haproxy/](https://www.haproxy.com/blog/dns-service-discovery-haproxy/) (which
is a link on the OP) says TTL on SRV records "is ignored by HAProxy as HAProxy
maintains its own expiry data which is defined in the configuration".

Is this true for A records too?

If so, neither haproxy nor nginx expire cached A records.

Nginx Plus does, and a few nginx plugins do, however.

[https://github.com/airbnb/synapse](https://github.com/airbnb/synapse) is a
process that polls DNS, and updates haproxy config accordingly and SIGHUPs
haproxy I've used synapse to solve this issue, but it's a moving piece I'd
rather not have involved.

~~~
bedis9
Yes, cached A records get expired in HAProxy (both community and enterprise).

HAProxy won't follow-up the TTL returned by the server. It's up to the
administrator to decide how HAProxy should behave with DNS responses.

From my point of view, you don't need synapse any more if your usage of
synapse is limited to this single feature.

------
m_mueller
I'm a bit confused about the runtime capabilities. Does "set server" mean I
can register new frontends in runtime? I mean, if we have a static DNS that
basically just has a wildcard entry that routes to HAProxy - can I add new
routes dynamically at runtime there?

About persistence: Does HAProxy have IP-based session persistence, i.e.
routing to always the same backend server for the same client IP, as long as
that server is available?

~~~
terlisimo
I don't know about dynamic frontends but regarding your second question, I can
confirm that HAProxy has session persistence capabilites.

Look up "stick" functions in HAProxy docs. You can even persist TCP
connections.

~~~
m_mueller
Thank you!

------
arrty88
How can the arguably best piece of open source tech keep get better? The only
thing I could ask for is a REST admin api to assist with my deploys.

~~~
Scarbutt
How about adding support for serving static files?

~~~
rkeene2
If you want something in the spirit of HAProxy for serving static content,
filed ( [http://filed.rkeene.org/](http://filed.rkeene.org/) ) is the fastest
static HTTP/1.1 server in the world. Putting it behind HAProxy 1.8 for TLS and
HTTP/2 would be trivial until those features are directly available.

~~~
reacharavindh
I like the idea of doing one thing well, and being great at it. Out of
curiosity, why depend on haproxy or something else to provide http/2 support?
Wouldn’t it make filed even faster (by letting the client pull all assets in
parallel) if it supported natively for serving static files? I’m imagining
static web pages with a few images to load.

As always, appreciate your open source work! Thanks!

~~~
rkeene2
HTTP/2 has been on the To Do list for a while and is a great idea for any HTTP
server that wishes to remain relevant. I just suggested HAProxy to be topical
and address HTTP/2 right now.

------
jsmeaton
Are there any plans to add UDP support to HAProxy? I wanted to use HAProxy as
a SIP/RTP proxy at my last job, but was unable to do so as we were pushing SIP
and RTP as UDP.

~~~
vbernat
Explain your use case on the mailing list. Absence of UDP support is due to
lack of useful scenarios for it.

~~~
phil21
As someone who puts this as a "want" and certainly not a "need" \- the answer
is really just management simplicity. That and HAProxy is generally a joy to
work with.

I already have a nice anycasted cluster of HAProxy servers that already have
the battle tested BGP session teardown logic/etc. integrated - I really don't
want to have to use a different load balancing method to HA my UDP services
and re-do large portions of that tooling.

It's certainly an annoyance, and being able to define traffic in the same
configuration file/syntax/etc. makes it much more maintainable for an ops vs.
engineering group.

------
hobofan
When opening the website, why do I get a credential storage prompt on Chrome
(Android)?

~~~
kuschku
If you scroll down, the page has a contact form with an email field.

Chrome detects that email field, and assumes it might be part of a login form.
(Because it is <input id="email" name="email" […] type="text">).

That triggers that.

------
will_hughes
Multithreading support. Holy cow yes.

All around good stuff, but I can't wait for multithreading.

------
JeanMarcS
Can't wait the release to push it to production servers. Once again HAProxy
offers a great software and great evolutions.

------
merb
wow this is huge: [https://www.haproxy.com/blog/dns-service-discovery-
haproxy/](https://www.haproxy.com/blog/dns-service-discovery-haproxy/) h2 only
on the frontend, as expected.

~~~
ksec
Also HTTP Small Object Caching, i wonder how it compares to varnish in
performance.

~~~
wtarreau
The purpose is _not_ to compare to varnish. If you need a real cache, please
use varnish. haproxy is to the cache what varnish is to the load-balancer. Ie:
we both do a little bit of it to simplify certain deployments, but serious
ones need both. We did this to address certain regular demands from users of
dirty servers suffering from just "GET /favicon.ico" (hence the "favicon
cache" term we've been using for a long time). I've been annoyed by seeing
people abusing the "errorfile 503" to deliver a few static objects and this is
an elegant response to address this. Over time it may turn out that it could
combine well with varnish, for example to improve a little bit the scalability
of haproxy+varnish nodes, we'll see. But it definitely is not at all an
alternative to varnish.

As a rule of thumb, I'd say that if you have a cache, keep it. If you only
have haproxy, you can try with a few rules to enable very basic caching and
see if that improves the situation for you. Then you'll get a better idea
about what would be required in your application to deploy an advanced cache
and what benefits it could bring.

------
ihattendorf
Very excited for HTTP/2 support to finally make it to HAProxy.

------
mschuster91
What use is http/2 in frontend only? No server-side pushes, the only thing I
can imagine is a tiny bit less bandwidth due to binary headers.

~~~
wtarreau
HTTP/2 was _designed_ for high latency networks. It supports stream
multiplexing and headers compression to significantly shrink page load time
over the internet. It has very limited use on the local network. Regarding
server-side push, it brings about as many issues as benefits and is often
counter-productive. Hopefully it will totally disappear when Early Hints are
standardized (addressing the same benefits without the issues).

That said, we still want to address server-side H2 in 1.9 to address the CDN
type of workloads where the origin servers might be far away. But that's less
important.

~~~
bpineau
gRPC is also a good candidate for end-to-end HTTP/2 :)

------
snvzz
The horrible "modern" web design scared me. Then I realised I was at
haproxy.com, not .org.

~~~
3131s
You really don't like that design? What's wrong with it? To my eye it doesn't
contain any of the cliches of bad modern design.

------
continuations
Any plan to have HTTP/2 on the backend?

------
ryanqian
when will have server side HTTP2 multiplex load balance?

------
vacri
_The connection has timed out

The server at www.haproxy.com is taking too long to respond._

Not the best advert for a high availability proxy...

