Live data from Hacker News

Weave is kinda slow

generictestdomain.net

41–50 of 164 posts

Re: Weave is kinda slow

#41
post #30

hello, weave here. a few very quick comments! weave has lots of very happy users who find that weave is plenty fast enough for their purposes, see eg http://blog.weave.works/2015/02/24/get-your-kicks-on-cloud66... the strong points of weave network, as it is right now, are ease of use (not to be sniffed at), and enormous flexibility. it is really quite easy to create an application involving containers, that runs any…

>weave has lots of very happy users who find that weave is plenty fast enough for their purposes That just means that your users aren't using it for large production workloads or they are just wasting excessive resources to make up for it.

Couldn't the same be said for [insert dynamic langugage here] ?

Fast enough is fast enough, as they say...

Re: Weave is kinda slow

#42

Would have been interesting to compare http://www.projectcalico.org/ .

Agree. I may try some benchmarks, as I have recently added support for Calico (as well as Weave, which was my original choice due to its simplicity) as another swappable SDN providers for Clocker [1].

[1] http://clocker.io/

Re: Weave is kinda slow

#43
post #20
post #8

flannel appears to be what kubernetes is using as well and I know it is what RedHat is using for their OpenShift platform ontop of k8. It seems like the obvious path forward.

Flannel relies on etcd. I had stability issues with v1 of etcd which meant flannel couldn't route packets. Since then, the idea of using an immature SDN atop an immature distributed key value store fills me with dread.

What do you use instead?

Re: Weave is kinda slow

#44
post #30

hello, weave here. a few very quick comments! weave has lots of very happy users who find that weave is plenty fast enough for their purposes, see eg http://blog.weave.works/2015/02/24/get-your-kicks-on-cloud66... the strong points of weave network, as it is right now, are ease of use (not to be sniffed at), and enormous flexibility. it is really quite easy to create an application involving containers, that runs any…

>weave has lots of very happy users who find that weave is plenty fast enough for their purposes That just means that your users aren't using it for large production workloads or they are just wasting excessive resources to make up for it.

That's an entirely subjective statement. What do you mean by 'large'?

Re: Weave is kinda slow

#45
post #9

Networking is a disaster. Kernel level networking is nice, but that requires access to the kernel which you can't provide in a container. Doing so means containers no longer contain. IPV6 was supposed to solve a lot of this by having an address space so huge you could easily give every vm host a few billion IPs. But nobody uses it.

Networking isnt a disaster. It's just that the current container ecosystem on linux hasnt yet resulted in any real domain specific improvements yet. For "default" systems, networking is pretty damned reliable and performant. A lot of the problems with regards to containment have already been solved in different systems. I believe solaris or opensolaris had Crossbow [1]. Any system that aims to provide connectivity ne…

For whatever it's worth, the Crossbow technology remains at the core of our Triton container stack[1] -- and we have extended it significantly by adding VXLAN and virtual layer 2 networking.[2][3] One of the comments we have heard from many early Triton adopters is that they enjoy having IP addresses, networking stacks and bare-metal performance. ;)

[1] https://www.joyent.com/blog/triton-docker-and-the-best-of-al...

[2] http://fingolfin.org/illumos/talks/sdn.pdf

[3] https://www.youtube.com/watch?v=mLvi3nPNqiQ&list=PLH8r-Scm3-...

Re: Weave is kinda slow

#46
post #30

Earlier quoted context omitted.

>weave has lots of very happy users who find that weave is plenty fast enough for their purposes That just means that your users aren't using it for large production workloads or they are just wasting excessive resources to make up for it.

Couldn't the same be said for [insert dynamic langugage here] ? Fast enough is fast enough, as they say...

Correct! Once upon a time people said Amazon cloud was too slow. Then they said it wasn't suitable for large workloads. Then they said it did not make money ... etc etc. I'm not saying we are like Amazon, I'm just saying that making new stuff excellent in all dimensions at once in hard ;-)

Re: Weave is kinda slow

#47

hello, weave here. a few very quick comments! weave has lots of very happy users who find that weave is plenty fast enough for their purposes, see eg http://blog.weave.works/2015/02/24/get-your-kicks-on-cloud66... the strong points of weave network, as it is right now, are ease of use (not to be sniffed at), and enormous flexibility. it is really quite easy to create an application involving containers, that runs any…

I'm thinking replies like this should come from an individual, not an account representing a company. Having an individual behind the words (instead of a loose consensus mechanism for a company) goes a long way to establishing trust. Hoping to see a direct address of the observations raised in the post!

I'm not sure why you think so, but fwiw, irl, I am alexis at weave dot works

Re: Weave is kinda slow

#48
post #20
post #8

flannel appears to be what kubernetes is using as well and I know it is what RedHat is using for their OpenShift platform ontop of k8. It seems like the obvious path forward.

Flannel relies on etcd. I had stability issues with v1 of etcd which meant flannel couldn't route packets. Since then, the idea of using an immature SDN atop an immature distributed key value store fills me with dread.

Interesting. But that's an old version. Calico [1] uses etcd as well (version 2.0.5 I think?) and I've never had any problems so far...

[1] http://www.projectcalico.org/

Re: Weave is kinda slow

#49
post #39

Weave has other issues... like they homebrewed their own ECDHE-PSK-based transport encryption protocol on top of NaCl. Homebrewing your own crypto, especially transport encryption which has to solve problems like key exchange, replay attacks, etc is generally the wrong answer. Also, even if they were using a standard transport encryption like SSL/TLS or IPSEC, PSKs are generally frowned upon for anything other than p…

Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption

https://twitter.com/lclarkmichalek/status/544882194456776705

Re: Weave is kinda slow

#50
post #15

In the terminal snippets, latency is specified in "us", which I'm guessing is µs, microseconds. In the table, those latency numbers are specified in "ms". Also microseconds? Couldn't possibly be milliseconds, for two VMs that should only be a couple dozen metres away from each other, right?

yes, microseconds surely - we estimate that the cost of switching from kernel to user space, and back again, several times, adds up to 2-300 microseconds. in return for this, you gain a lot of flexibility and ease of use. for apps that need lower latency, weave is currently working on implementing a fast data path option..
Post reply on HN