Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weave is kinda slow

generictestdomain.net

Post reply on HN
Print view View original

31–40 of 164 posts

Re: Weave is kinda slow

#31

Post by hueving »

adamc wrote: post #16
thinkingkong wrote: post #13

Earlier quoted context omitted.

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…

"the least amount of encapsulation possible" doesn't sound like much of a solution if what you are looking for is networking with strong encapsulation.

>strong encapsulation

What does that term even mean? Are you talking about encryption? If not, there is no 'strength' to encapsulation. Something is either encapsulated efficiently or it's not.

Re: Weave is kinda slow

#32

Post by lclarkmichalek »

ceequof wrote: 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?

Wow, huge mea culpa on that one. I would assume that qperf is using us to mean microseconds, and judging by the source line

    char *tab[] ={ "ns", "us", "ms", "sec" };
it would certainly seem that way. I'll update the post, thanks.

Now I'll just be waiting for someone to complain about inconsistent precision. I am not a good scientist...

Re: Weave is kinda slow

#33

Post by bboreham »

d136o wrote: post #12

what I appreciate about weave is that it solved the cross host container networking problem easily (it's very very easy to use) and now , i.e. no waiting for promises of future solutions or fooling around with more complicated set ups. Here's where I got burned: I set up an elastic search cluster using containers and weave and life was great, but it then grew to need another node. Upon setting up the new host with do…

Hi, I work on Weave; it may well have been one of my commits that broke the protocol compatibility for you. We've changed things over time to improve performance and resilience.

It should be fairly straightforward to deploy the same version on every host, but maybe that wasn't explained well enough, or didn't work for you. We'd welcome more feedback.

Lastly, I appreciate the positive comments. "Very very easy to use" is exactly what we aimed for.

Re: Weave is kinda slow

#34

Post by hueving »

ceequof wrote: 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?

I think they are supposed to be 'us' based on the qperf output.

Re: Weave is kinda slow

#36

Post by Confusion »

mdekkers wrote: post #3

"Thankfully, the fact that these problems were solved decades ago has not stopped people from coming up with their own solutions, and we now all get to witness the resulting disasters." Spot on

So what are the decades old solutions to these problems?

Re: Weave is kinda slow

#37

Post by lclarkmichalek »

q3k wrote: post #29
justinsb wrote: post #2

User-space overlays are slow, Weave more so than flannel. The really interesting data-point for me is that flannel with VXLAN has negligible overhead.

Actually, userspace packet switching can be fast (10GbE linespeed-fast) thanks to approaches like DPDK [1], where a userspace process has zero-copy, direct access to NIC ring buffers. 1 - http://dpdk.org/

The problem with DPDK is (as I understand it) that it doesn't handle multiplexing the connection between multiple cores/processes/containers (i.e. lack of polling makes scheduling hard/impossible). The nice thing about using the Linux kernel as your data plane is that you can still have all your bog standard routing, in addition to this fun VXLAN/GRE/etc stuff. That said, I haven't ever implemented anything using DPDK, so I may be talking out my arse.

You are correct however that userspace networking is awesome, and I look forward to it becoming more and more prevalent in applications that can benefit from it.

Re: Weave is kinda slow

#38

Post by grkvlt »

weavenetwork wrote: post #22

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'd agree that Weave is great at what it does, which is providing just-enough-networking to make Docker applications as easy to design and construct as applications running on a normal LAN. This is a huge win, since I don't have to worry about portmappers and trying to discover what dynamically allocated ports are being used at runtime to connect two services.

I use Weave as the default SDN for Clocker [1] because of this simplicity, and also because it is server-less and will work on a single server Docker cloud or a cluster of tens of machines without having to think about architecture. Of course, Clocker supports pluggable SDN providers so if your networking demands are not met by Weave you can change to another provider.

I don't think Alexis (or any other Docker SDN provider) is suggesting that their software should be used for low-latency microsecond sensitive trading applications. You have to use the right tools for the job, and in this case Weave's sweet spot is its simplicity and reliability.

[1] http://clocker.io

Re: Weave is kinda slow

#39

Post by bascule »

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 point-to-point connections.

They describe the PSK as a "password", so what they really want is a PAKE algorithm, however they do not use a password hashing function, so weak "passwords" are susceptible to brute force attacks.

Anyway, all these things are why you should just stick to standard protocols like SSL/TLS or IPSEC.

Re: Weave is kinda slow

#40

Post by nine_k »

justinsb wrote: post #2

User-space overlays are slow, Weave more so than flannel. The really interesting data-point for me is that flannel with VXLAN has negligible overhead.

Using a VLAN (VXLAN), as the post shows?
Post reply on HN