Gnatsd: a high performance NATS messaging server written in Go

by krobertson • 13 years ago

33 7 13 years ago

At first glance, NATS looks similar in goal to MQTT. Can anyone describe the differences?

After some googling, I found this description here[1]. It sounds like a straightforward pub-sub server (similar to redis pub/sub?).

  [1]: http://www.activestate.com/blog/2013/01/building-paas-ruby

jvoorhis• 13 years ago

NATS is the pub-sub messaging protocol and implementation created by Derek Collision, who architected the first iteration of Cloud Foundry. It is a simple pub-sub service at its core, but the Ruby and NodeJS clients implement various messaging patterns similar to what is supported by ZeroMQ. It is used extensively within Cloud Foundry.

orenmazor• 13 years ago

at first I definitely thought this was related to the old gnu bug tracker.

DrJosiah2• 13 years ago

This is probably a bit off topic, but I notice that they implemented their own hashmap with pluggable hash functions. Awesome in theory (and practice), though I notice that the performance of their custom hash table is poorer than Go's built-in hash map (Go's hashmap takes 1/2, 3/4, and 9/10th the time of their hashmap for small, medium, and large keys, respectively - though this could be related to the updated aes hash in Go, and that my processor supports it).

While looking through the implementations, the Gnatsd hashmap implementation is a simple table with buckets, where as the Go hashmap also uses a table with buckets, though each "bucket" has 8 slots by default (and does subsequent chaining). Go's chunking of buckets helps caches work better, reduces random reads, and helps to minimize overhead (fewer pointers if you have fixed-size data). Read the first 83 lines of http://golang.org/src/pkg/runtime/hashmap.c to see what good structure design and experimentation gets you.

Does someone have an example where a 'go test --bench="." -gcflags="-B"' call in the gnatsd/hashmap path actually comes out ahead for the Gnatsd hashmap using a recent Go?

krobertson• 13 years ago

Derek's hashmap was faster than than Go 1.0's built in hashmap. With Go 1.1 or 1.1.1 (don't remember which one exactly), the standard one did become faster, though Derek had decided to stick with it as is. I can ask him what the reason was... I don't recall right now.

DrJosiah2• 13 years ago

I think I may know why they are sticking with the self-built version: random key selection. The built-in hash map doesn't include a method to discover a random key, but the gnatsd hashmap does.

Gnatsd: a high performance NATS messaging server written in Go

Related Stories