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

The C10M problem

c10m.robertgraham.com

Post reply on HN
Print view View original

71–80 of 116 posts

Re: The C10M problem

#71

Post by nostrademons »

logicchains wrote: post #57
dagw wrote: post #56

Earlier quoted context omitted.

Except the difference at the margin is never just an extra hour of a day. It's almost always weeks instead of days or years instead of month. And that is fine when you are doing things for yourself and have no other requirements on your time, but when you're being paid spending two month on something instead of week just pisses everybody around you off. I mean don't get me wrong, I'm working on a project right now th…

> Except the difference at the margin is never just an extra hour of a day. It's almost ways weeks instead of days or years instead of month. Maybe we're thinking of different things here. What I had in mind was more along the lines of for instance choosing Go or Scala instead of Rails or *.js and getting a 10x speedup at the cost of simply adding a few type declarations. There are situations like yours where deadlin…

I think both situations are highly context-sensitive.

If you're founding a startup in an emerging consumer market, you'd be making a mistake to use something like Go or Scala rather than Rails or Node.js, because your whole success is dependent upon finding out what particular combination of design, features, and experience emotionally resonates with fickle consumers' minds. That takes a lot of trial and error; anything that slows down that experimentation process is going to cost you the market. Once you've found the market you can get VC and hire experienced technologists to curse out your technology choices and rewrite it in Go or Scala or Java or C++ or whatever.

If you're CloudFlare and billing yourself as "the web performance and security company", however, building out your architecture in a performant and reliable language makes a lot of sense. You know your value proposition: you want to use whichever technology stack lets you execute against that value proposition most effectively.

Twitter got a lot of flack for being built on a "dumb" Rails architecture, but I'm also certain they would not have succeeded had they done anything else. Remember the context of their founding: Twitter grew out of an idea lab that grew out of Odeo, and at the time of their founding they were an idea that was so marginal that nobody would've bothered with it had it taken more than a weekend or so to prototype. When it turned out that people liked it, then they could afford to hire people to rewrite the software into something scalable - but those people would not have jobs had the initial concept not been proven out first.

Re: The C10M problem

#72

Post by guard-of-terra »

logicchains wrote: post #64
sitkack wrote: post #59

Earlier quoted context omitted.

Your recollection of Japanese manufacturing is clouded by mythology. Japanese quality sucked in the 1950s, they had a horrible world wide reputation for shoddy goods.

Maybe German manufacturing would be a better example?

German quality sucked some half century earlier, so much that England had to require them write "Made in" on their goods to warn consumers.

Quality comes and goes.

Re: The C10M problem

#73

Post by turbojerry »

EdwardDiego wrote: post #23
dxhdr wrote: post #20

Earlier quoted context omitted.

Port numbers must only be unique for ip:port pairs. A TCP connection is identified by the "quadruple" source_ip:source_port, dest_ip:dest_port. You can have as many connections as you want on the same source_ip on port 80 as long as there aren't 65,535 to the same dest_ip (ie as long as the quadruple is unique).

Cheers for the info! I guess that's where I got the wrong idea from - attempting to stress test one machine from another machine, I'd always hit that limit, but now I understand why.

Try Tsung for stress testing, it can use multiple IPs and therefore you can open up as many connections as you like -

http://tsung.erlang-projects.org/

Re: The C10M problem

#74

Post by swah »

Those two articles, http://blog.erratasec.com/2013/02/multi-core-scaling-its-not... (from Robert Graham) and http://paultyma.blogspot.com.br/2008/03/writing-java-multith..., seem to say opposing things about how threads should be used.

Having no experience with writing Java servers, I wonder if any you guys have an opinion on this.

Re: The C10M problem

#75

Post by logicchains »

nostrademons wrote: post #71
logicchains wrote: post #57

Earlier quoted context omitted.

> Except the difference at the margin is never just an extra hour of a day. It's almost ways weeks instead of days or years instead of month. Maybe we're thinking of different things here. What I had in mind was more along the lines of for instance choosing Go or Scala instead of Rails or *.js and getting a 10x speedup at the cost of simply adding a few type declarations. There are situations like yours where deadlin…

I think both situations are highly context-sensitive. If you're founding a startup in an emerging consumer market, you'd be making a mistake to use something like Go or Scala rather than Rails or Node.js, because your whole success is dependent upon finding out what particular combination of design, features, and experience emotionally resonates with fickle consumers' minds. That takes a lot of trial and error; anyth…

You're right I suppose. I think as someone who's not a webdev I just have trouble imagining the productivity benefits of something like Rails or Node.js. I assumed that nowadays there'd be frameworks in statically typed languages with type inferences that were almost as productive as Node and Rails, and hence could provide both fast development speed and efficient executables.

Re: The C10M problem

#76

Post by noelwelsh »

nostrademons wrote: post #71
logicchains wrote: post #57

Earlier quoted context omitted.

> Except the difference at the margin is never just an extra hour of a day. It's almost ways weeks instead of days or years instead of month. Maybe we're thinking of different things here. What I had in mind was more along the lines of for instance choosing Go or Scala instead of Rails or *.js and getting a 10x speedup at the cost of simply adding a few type declarations. There are situations like yours where deadlin…

I think both situations are highly context-sensitive. If you're founding a startup in an emerging consumer market, you'd be making a mistake to use something like Go or Scala rather than Rails or Node.js, because your whole success is dependent upon finding out what particular combination of design, features, and experience emotionally resonates with fickle consumers' minds. That takes a lot of trial and error; anyth…

You perhaps imagine that when Twitter was created the developers sat down and said "should we write this in Rails or in Java?" I very much doubt a conversation anything like that took place. I'm almost 100% certain the developers used the tool they knew best and never considered any other alternatives. Quite possibly they had little or no experience with alternatives.

I work with both a RoR code base and a Scala code base. There is no difference in productivity that I can tell between the two. I think it is a out-dated assumption to believe that dynamic languages like Ruby or Python are more productive than modern statically typed languages. The only cost is one of learning; many more people know Ruby than Scala. This is an artifact of history (i.e. Ruby is 10+ years older than Scala; crappy CS educations that only teach Java).

Re: The C10M problem

#77

Post by rwallace »

wpietri wrote: post #13

On the one hand, I love this. There's an old-school, down-to-the-metal, efficiency-is-everything angle that resonates deeply with me. On the other hand, I worry that just means I'm old. There are a lot of perfectly competent developers out there that have very little idea about the concerns that motivate thinking like this C10M manifesto. I sometimes wonder if my urge toward efficiency something like my grandmother's…

As someone who learned to program on a machine with five kilobytes of RAM, and later had to put a fair bit of effort into unlearning some of the resulting habits:

Yes, that kind of efficiency (in terms of machine resources) and inefficiency (in terms of human resources) is effectively obsolete for general-purpose programming. What of that? If your heart's desire is to work in a context where machine resources are scarce, just work in an area like high-performance technical computing where that's still true. We do not, and never will, have any shortage of jobs where you always need more computing power.

Re: The C10M problem

#78

Post by microtonal »

dbenhur wrote: post #43
electrograv wrote: post #25

Earlier quoted context omitted.

It really just depends on how much of a computational surplus you have. Some tasks have become so incredibly easy relative to today's computational horsepower, that we can afford waste 90% of it if it means we can be 10% more productive. But this isn't true everywhere. Imagine if Google's servers cost 100x more to run, if they didn't spend time to make their code efficient. Imagine if your video games ran at a frame…

> when languages like Python and Ruby can be over 100x slower than other high level languages You said a wrong thing. Java is a far cry from a high-level language. Javascript is arguably a high-level language however, and meaningless benchmarks (aka "damn lies") attest V8 is in spitting distance of Java. http://benchmarksgame.alioth.debian.org/u32/javascript.php Scala is much higher level than Java, compiles to the s…

Javascript is arguably a high-level language however, and meaningless benchmarks (aka "damn lies") attest V8 is in spitting distance of Java.

There are far better examples. E.g. Haskell is very high-level and, as axman6 mentions elsewhere in this thread, has been shown to be able to handle 20m new connections per second.

Re: The C10M problem

#79

Post by lukego »

nl wrote: post #52
erichocean wrote: post #16

What's significant to me is that you can do this stuff today on stock Linux. No need to run weird single-purpose kernels, strange hypervisors, etc. You can SSH into your box. You can debug with gdb. Valgrind. Everything is normal...except the performance, which is just insane. Given how easy it is, there isn't really a good excuse anymore to not write data plane applications the "right" way, instead of jamming everyt…

Snabb Switch looks awesome. Is there a list of "things" (not sure of the terminology?) people have built with it? I guess the downside is that you can't virtualize it (I realize that is kind of the point, but it does reduce the accessibility of it).

I'm the Snabb Switch originator.

The project is new: I and other open source contributors are currently under contract to build a Network Functions Virtualization platform for Deutsche Telekom's TeraStream project [1] [2]. This is called Snabb NFV [3] and it's going to be totally open source and integrated with OpenStack.

Currently we are doing a lot of virtualization work from the "outside" of the VM: implementing Intel VMDq hardware acceleration and providing zero-copy Virtio-net to the VMs. So the virtual machine will see normal Virtio-net but we will make that operate really fast.

Inside the VMs we can either access a hardware NIC directly (via IOMMU "PCI passthrough") or we can write a device driver for the Virtio-net device.

So, early days, first major product being built, and lots of potential both inside and outside VMs, lots of fantastic products to build with nobody yet building them :-)

[1] http://blog.ipspace.net/2013/11/deutsche-telekom-terastream-...

[2] https://ripe67.ripe.net/archives/video/3/

[3] https://github.com/SnabbCo/snabbswitch/blob/snabbnfv-readme/...

Re: The C10M problem

#80

Post by nicpottier »

srean wrote: post #42
usea wrote: post #34

Earlier quoted context omitted.

It is wasteful to spend time doing something that benefits nobody, or where the benefits outweigh the cost. Your time is worth something.

I think the "just good enough for business" attitude contributed to the demise of the American car and the rise of the Japanese ones. The American tradition was to use engineering tolerances that would maximize throughput under the constraint that it produced a pretty functional car. The Japanese tradition on the other hand was to use tighter tolerances, well because there was room for tightening the tolerance. At th…

I think you are actually exactly opposite on this.

There are actually two books that were written about this very topic, one called "The decline and fall of the American Programmer", which was essentially making your argument, that American quality going down meant we would get eclipsed, and "The Rise and Resurrection of the American Programmer", written by the same author, saying "oops, I was wrong", because "good enough" is the winning strategy, not quality at all costs.

Note that at the time of those writings, the 'sloppy' guys were Microsoft, which is still way way more process than your typical RoR shop today has. In the days of shipping new software to websites three times a day, pragmatism rules all.

As the saying goes: "Premature optimization is the root of all evil."

Post reply on HN