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

Node and Scaling in the Small vs Scaling in the Large

al3x.net

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Node and Scaling in the Small vs Scaling in the Large

#41

Post by Tichy »

epochwolf wrote: post #37
Tichy wrote: post #23

Earlier quoted context omitted.

I think traditionally, something like Tomcat used to have perhaps 30 threads? Especially with todays Ajax-driven web sites, it is very easy to exhaust them. I can only point to a stupid app of mine, which triggered Twitter searches for a list of search results via Ajax (so one page of search results would trigger, say, 10 search reguests to Twitter via Ajax, proxied through the server). Since that app was written for…

Uh... rails does thread. Not sure if it's a good idea but it does have support for threads. http://guides.rubyonrails.org/2_2_release_notes.html#thread-...

OK, but I don't think the traditional hosting setups use that. Anyway, the point was that with a limited amount of threads, you can run into trouble.

Re: Node and Scaling in the Small vs Scaling in the Large

#42

Post by Tichy »

dedward wrote: post #36
Tichy wrote: post #23

Earlier quoted context omitted.

I think traditionally, something like Tomcat used to have perhaps 30 threads? Especially with todays Ajax-driven web sites, it is very easy to exhaust them. I can only point to a stupid app of mine, which triggered Twitter searches for a list of search results via Ajax (so one page of search results would trigger, say, 10 search reguests to Twitter via Ajax, proxied through the server). Since that app was written for…

But a request to twitter blocking everything else would be an issue, right? Aside: haproxy, configured cleverly, can deal with limiting the number of concurrent connections permitted to your app on a URL basis (or just about any other part of the request you can deconstruct) to allow your app to not get hung up on slow queries and keep fast queries going where you want them.

With something like node, a request to Twitter would not block.

Not sure how haproxy would help?

Re: Node and Scaling in the Small vs Scaling in the Large

#43

Post by cageface »

aaronblohowiak wrote: post #9
KirinDave wrote: post #3

I'm glad to see people starting to push back against the cult of “Evented is faster.” It may be, it may not be. The idea that it always is, though, that's balderdash.

As he notes, evented vs threaded is only important within a single machine. I would argue that your architecture for distributing load across machines is more important than evented vs threaded. If we think that the difference in performance is small (regardless of which is faster,) then the question becomes one of which programming style you prefer. Node's implementation of events means you can have mutable state wi…

I'm a little puzzled by this fascination with shared memory concurrency myself. If you have to scale beyond one physical instance, and you generally do if you have to scale at all, your scaling mechanism is your distribution mechanism. Of course, there are apps that need maximum throughput in a single address space but they seem to be very much in the minority.

Re: Node and Scaling in the Small vs Scaling in the Large

#45

Post by pvg »

blasdel wrote: post #40
pvg wrote: post #33

Earlier quoted context omitted.

some ImageMagick operations are multithreaded by default And a really icky default at that, for the performance reasons you mention and with the added bonus of a chance of hitting some pointless bug. I've been turning it off ever since I spent a pleasant evening staring at the stacks of wedged apaches that ended with a pile of ImageMagick functions culminating in futex-something-or-other.

It gets ickier too — IM has flags for limiting its memory usage, but instead of modifying the algorithm, it just implements its own VM system and swaps to tempfiles directly from userspace when it hits the constraint. Fucking programming like it's 1975 ( http://varnish-cache.org/wiki/ArchitectNotes )

It is, undoubtedly, one of the more appalling pieces of software in wide use. Just to complete the wild tangent, GraphicsMagick is an interface-compatible fork that claims better performance and less cruft (while still weighing in at above 280 klocs). Flickr uses it so presumably it only gives you two brain aneurysms instead of 4.7.

I also can't help but to gush about varnish a little (a handy thing to put in front of an image processing server, for one thing), which has a number of post-1975 features beyond its memory management such as an actually useful configuration language, statistics aggregation and reporting and the inexplicably uncommon ability to manage and modify configuration without a restart.

Re: Node and Scaling in the Small vs Scaling in the Large

#46

Post by gruseom »

blasdel wrote: post #30
moe wrote: post #16

Earlier quoted context omitted.

Keep in mind when reading this article that Alex recently left a little company called Twitter. It's safe to say that relatively few companies will ever have to scale the way that Twitter has. You mean the failwhale way? ;-) Not meaning to discredit al3x but I really don't consider twitter a success story in terms of scaling. I don't know if it's incompetence or just some truly bad early decisions that they're still…

I have a feeling that hiring al3x is one of the few reasons that Twitter didn't collapse into a heap of cetacean corpses. Twitter's original codebase started as a "my first blog" tutorial in Rails — the polar opposite of a messaging platform. That's a hell of a ship to turn around, especially live on the world stage while the userbase and datastore are growing exponentially and you're rapidly approaching the second h…

Twitter's original codebase started as a "my first blog" tutorial in Rails

Where on earth did you get that idea? It's not true:

http://en.wikipedia.org/wiki/Twitter#History

Moreover, the idea had been gestating for years:

http://en.wikipedia.org/wiki/Jack_Dorsey

Re: Node and Scaling in the Small vs Scaling in the Large

#48

Post by blasdel »

> Herein lies my criticism of Node’s primary stated goal: “to provide an easy way to build scalable network programs”. I fundamentally do not believe that there is an easy way to build scalable anything. What’s happening is that people are confusing easy problems for easy solutions.

Even though I disagree with much of his technical argument, this is an extraordinarily important point that I find myself agreeing with more and more upon rereading. Nothing is scalable out of the box, anything can be fucked up, and there's no silver bullet.

Re: Node and Scaling in the Small vs Scaling in the Large

#49

Post by jking »

KirinDave wrote: post #3

I'm glad to see people starting to push back against the cult of “Evented is faster.” It may be, it may not be. The idea that it always is, though, that's balderdash.

Does the thread being slower movement have anything to do with the rise of Python which doesn't have good support for thread due to GIL?

Re: Node and Scaling in the Small vs Scaling in the Large

#50

Post by Tichy »

jerf wrote: post #26
Tichy wrote: post #22

Earlier quoted context omitted.

I am not a specialist on this area. But please mention some interesting competitors to Node.js for your type 2? Personally I also like the fact that Node is Javascript. I have looked at Scala several times and superficially, it looks extremely ugly. Clojure and Haskell might be interesting, but I worry that the non-modifiable memory could bite me in the end (plus, Clojure might force me to do too much dreaded Java st…

You mentioned most of the ones I consider the real winners. Go is another possibility, though I'm not sure it fits in here; I don't know what sits at the core of the goroutines scheduler, but if it isn't select-like it probably easily could be. There are also a metric shitload of other event-based frameworks like Node.js, only for other languages, at varying levels of maturity and cruftiness. (Though part of the reas…

Thanks for the info. I don't have the experience yet, so I can't comment. Erlang definitely sounds good, too. My impression was that the hype had subsided recently, but maybe it is still going strong.
Post reply on HN