4 ms·

As much as I love Go and use it extensively for various production-grade projects, I'm wondering how suitable it really is for something like a load balancer.

As much as I love Go and use it extensively for various production-grade projects, I'm wondering how suitable it really is for something like a load balancer. My understanding is that Go's TLS performance is dramatically less than other C-based implementations like OpenSSL. I remember reading something about some licensing collisions between the Go project and some TLS stuff such that optimized encryption code couldn't be incorporated into the Go project directly. Cloudflare got around it and has much better performance for TLS. Apart from that, GC is still a big deal and the current net/http standard library produces a lot of garbage.

philips 11y ago
The 21x performance improvements to Go TLS was merged[1] and is available in go1.6rc1[2], IIRC. [1] https://groups.google.com/forum/#!msg/golang-codereviews/m5QTnSUZU6c/Q5RUAdefWUwJ https://groups.google.com/forum/#!msg/golang-codereviews/m5Q... [2] https://tip.golang.org/doc/go1.6 https://tip.golang.org/doc/go1.6
kelseyhightower 11y ago
Go's TLS support should be greatly improved in Go 1.6 thanks to the performance work you referenced by Cloudflare. The licensing issue was resolved and the work was merged 11/10/2016[1] While GC will always carry a cost, great improvements have been made over the last year and continues to be an area of focus for each Go release. Rick Hudson gave a nice update on Go's GC improves at GopherCon 2015 [2][3] [1] https://go-review.googlesource.com/#/c/8968 https://go-review.googlesource.com/#/c/8968 [2] https://talks.golang.org/2015/go-gc.pdf https://talks.golang.org/2015/go-gc.pdf. [3] https://www.youtube.com/watch?v=aiv1JOfMjm0 https://www.youtube.com/watch?v=aiv1JOfMjm0
darren0 11y ago
This component basically acts as a control plane for LVS which is implemented in the kernel. The data plane is not Go. Basically this load balancer is really the Linux kernel (and it's blazing fast).
SwellJoe 11y ago
I have not looked deeply at the implementation, at all, but given that the actual site refers to this as an "algorithm" for LVS, I kinda suspect all the heavy lifting is happening at the kernel level within LVS, and the go code is merely acting as a control program that tells the backend how to behave. Many high performance systems have lower performance scripting languages or similar built in or bolted on, in order to provide easier means of development without impeding performance significantly. LVS is no exception. The LVS-based systems I've built and used in the past often had a number of non-C components (mostly Perl, as it was 10+ years ago), for health checks, data gathering, making balancing decisions, etc. It is entirely possible this is the kind of work Go is doing (again, I haven't looked deeply into the code...but, I don't immediately see anything indicating Go is doing the actual load balancing, but it is obviously doing health checks and providing management access). Finally, Erlang is a garbage collected language, and yet it has been used for a couple of decades for this kind of workload. So, evidence strongly suggests it is possible for a GC language to do things like this (though, again, I don't think Go is doing the network layer work here, since LVS is in the picture).
- im_down_w_otp 11y ago
  That's because Erlang's GC is managed on a per-lightweight-process basis, which is possible because of the share-nothing nature of the concurrency model Erlang uses (actor/message-passing). Garbage collection in Go can't be implemented the same way, because Go allows for shared mutable state. That said, the work done to the GC in Go v1.5 seems quite phenomenal, but just because the two runtimes share a piece of terminology called "garbage collector", they're very, very different in terms of the semantics and effects exposed.
  - pjmlp 11y ago
    Apparently in 2016 we still need to make people aware that not all GCs are born the same way.
lobster_johnson 11y ago
This is a Layer 4 load balancer. It doesn't look at the contents of packets; it only decides where they should go. So Go's TLS performance isn't relevant here.
bkeroack 11y ago
Premature worry (aka FUD). We run Go services that terminate TLS and handle thousands of req/sec per server and it's never been even a slight concern. CPU usage for TLS has not been measurable. GC has also not been an issue, at least wrt net/http.
- ossreality 11y ago
  Go's TLS is slower than C implementations. Even with the improvement that hasn't even shipped yet. It's not FUD. It's a fact.

philips 11y ago

The 21x performance improvements to Go TLS was merged[1] and is available in go1.6rc1[2], IIRC. [1] https://groups.google.com/forum/#!msg/golang-codereviews/m5QTnSUZU6c/Q5RUAdefWUwJ https://groups.google.com/forum/#!msg/golang-codereviews/m5Q... [2] https://tip.golang.org/doc/go1.6 https://tip.golang.org/doc/go1.6

kelseyhightower 11y ago

Go's TLS support should be greatly improved in Go 1.6 thanks to the performance work you referenced by Cloudflare. The licensing issue was resolved and the work was merged 11/10/2016[1] While GC will always carry a cost, great improvements have been made over the last year and continues to be an area of focus for each Go release. Rick Hudson gave a nice update on Go's GC improves at GopherCon 2015 [2][3] [1] https://go-review.googlesource.com/#/c/8968 https://go-review.googlesource.com/#/c/8968 [2] https://talks.golang.org/2015/go-gc.pdf https://talks.golang.org/2015/go-gc.pdf. [3] https://www.youtube.com/watch?v=aiv1JOfMjm0 https://www.youtube.com/watch?v=aiv1JOfMjm0

darren0 11y ago

This component basically acts as a control plane for LVS which is implemented in the kernel. The data plane is not Go. Basically this load balancer is really the Linux kernel (and it's blazing fast).

SwellJoe 11y ago

I have not looked deeply at the implementation, at all, but given that the actual site refers to this as an "algorithm" for LVS, I kinda suspect all the heavy lifting is happening at the kernel level within LVS, and the go code is merely acting as a control program that tells the backend how to behave. Many high performance systems have lower performance scripting languages or similar built in or bolted on, in order to provide easier means of development without impeding performance significantly. LVS is no exception. The LVS-based systems I've built and used in the past often had a number of non-C components (mostly Perl, as it was 10+ years ago), for health checks, data gathering, making balancing decisions, etc. It is entirely possible this is the kind of work Go is doing (again, I haven't looked deeply into the code...but, I don't immediately see anything indicating Go is doing the actual load balancing, but it is obviously doing health checks and providing management access). Finally, Erlang is a garbage collected language, and yet it has been used for a couple of decades for this kind of workload. So, evidence strongly suggests it is possible for a GC language to do things like this (though, again, I don't think Go is doing the network layer work here, since LVS is in the picture).

im_down_w_otp 11y ago
That's because Erlang's GC is managed on a per-lightweight-process basis, which is possible because of the share-nothing nature of the concurrency model Erlang uses (actor/message-passing). Garbage collection in Go can't be implemented the same way, because Go allows for shared mutable state. That said, the work done to the GC in Go v1.5 seems quite phenomenal, but just because the two runtimes share a piece of terminology called "garbage collector", they're very, very different in terms of the semantics and effects exposed.
- pjmlp 11y ago
  Apparently in 2016 we still need to make people aware that not all GCs are born the same way.

lobster_johnson 11y ago

This is a Layer 4 load balancer. It doesn't look at the contents of packets; it only decides where they should go. So Go's TLS performance isn't relevant here.

bkeroack 11y ago

Premature worry (aka FUD). We run Go services that terminate TLS and handle thousands of req/sec per server and it's never been even a slight concern. CPU usage for TLS has not been measurable. GC has also not been an issue, at least wrt net/http.

ossreality 11y ago
Go's TLS is slower than C implementations. Even with the improvement that hasn't even shipped yet. It's not FUD. It's a fact.