Hacker News Reader

Comment by freedomben | Hacker News Reader

Maybe a dumb question nowadays because I stopped using Go around the 1.6 days, but is there still a stop-the-world garbage collector, or any other potential blockers for high performance/real time?

A previous company I worked with chose to build in C++ instead of Go because of that, as the performance requirements were very, very high. I would imagine a serious BGP usage would have very high requirements?

View on HN

BGP doesn't have very high performance requirements. It does not handle any internet traffic. All it does is configure the kernel routing tables. Even if there's some crazy 1 second GC pause it will not greatly affect the performance of the router.

Sending or receiving an internet full table (and potentially applying filters/aggregations) is still quite performance intensive, since it needs to happen quickly.

A one-second GC pause won't hurt you but managing the necessary data structures in memory can be challenging.

Anecdotally, gobgp is quite a bit slower than hand-optimized C implementations like frr (not that it matters for most gobgp use cases).

> A one-second GC pause won't hurt you but managing the necessary data structures in memory can be challenging.

How so? It's a very common pattern in garbage collected languages to preallocate an array or structures and read/write into it, then "release" the array on finishing the function.

> Sending or receiving an internet full table (and potentially applying filters/aggregations) is still quite performance intensive

Nope. I am running 15 sessions with full transit tables, multiple exchanges, and private peers on a four core ARM CPU with 4 GB of RAM.

How does it take to receive a full table?

How long? If I down all the peers and bring them up it will take 5-10 seconds to rebuild. But if you do that you're scheduling an outage anyway.

What's challenging about it? Go gives you control over the layout of your objects in memory.

I don't think BGP requires real-time. Increasing throughput via multithreading is probably much more impactful (for large deployments) and otherwise it doesn't matter.

A BGP route server might be the platonic ideal of a Go problem: it's demanding enough not to be tenable in Python, but not real-time or kernel resident, and mostly data structure --- and just a couple data structures --- intensive.

> not to be tenable in Python

https://github.com/Exa-Networks/exabgp is written in python

Sorry, I wasn't being precise. Lots of people use BGP for easy lifts, like internal policy routing inside data centers (I find this mystifying but whatever) or simply to advertise Anycast prefixes to upstreams. I was thing more about doing default-free global Internet routing with multiple peers.

I've used exabgp running on a small VM to inject 300,000 /32 routes to multiple peers. Not quite the size of the full v4 routing table, but not too far off either.

Were you taking a feed in? Or just publishing your own addresses?

just injecting routes. There are a bunch of looking glass implementations that use exabgp though.

Go's garbage collector has super short stop the world now, about 1ns IIRC. Most of the work is done concurrently from the main process threads.

> 1ns

Microsecond, perhaps. Likely millisecond. Nanosecond is faster than a single CPU instruction.

It depends on the context. Not every bgp speaker needs the full internet table and frequent route changes. If you use the network to balance traffic across servers, you just need a bgp speaker on a server to inject a few routes for the ip addresses it will handle. In that case a good api outweighs performance.

Reply on news.ycombinator.com