|Node.js vs. Scala - "Scaling in the large"||Sri Rangan||9/2/11 8:55 PM|
|Re: [nodejs] Node.js vs. Scala - "Scaling in the large"||Mark Hahn||9/2/11 10:03 PM|
The author implies that if you use Node you are locked into Node. This is a big assumption. Why is this true more for node than scala?
This isn't true for me. I've used node in combination with Apache and I've used processes with threads inside a node-based app. I'm also keeping ngen in my arsenal of tools for when I need it.
|Re: Node.js vs. Scala - "Scaling in the large"||Liam||9/3/11 12:33 AM|
Thanks for the link. It's a good read with a very valid point; Node's
not a silver bullet for massive-scale contexts.
It IS designed to be more efficient and easy-to-use than the other
readily-available options for network apps -- PHP, RoR, Python, et al.
> - Sri
> Srirangan | About <http://srirangan.net/about> Blog<http://srirangan.net>
> GitHub <https://github.com/Srirangan>
> Twitter <http://twitter.com/srirangan>
|Re: [nodejs] Node.js vs. Scala - "Scaling in the large"||Mo Cheng||9/3/11 1:08 AM|
Scalability is basically a economic problem. If your system can serve billions of visits with acceptable cost, it really doesn't matter your system is on Node.js or Apache or anything else.
The cost includes:
1) engineering cost. e.g. wages of engineers
2) operation cost. e.g. electronic and hardware bill
Node.js may help to have same single machine serve more visits due to asynchronous IO, but it may not reduce other cost such as engineering cost.
--Job Board: http://jobs.nodejs.org/
|Re: Node.js vs. Scala - "Scaling in the large"||Floby||9/3/11 2:31 AM|
I'm not sure I agree with this sentence :
" threads are constructs for a single computer, and events are
constructs for a single CPU"
> On Sat, Sep 3, 2011 at 11:55 AM, Srirangan <sriran...@gmail.com> wrote:> > I'm looking for responses to the points raised here<http://al3x.net/2010/07/27/node.html>
> > .
> > - Sri
> > --
> > Srirangan | About <http://srirangan.net/about> Blog<http://srirangan.net>
|Re: [nodejs] Re: Node.js vs. Scala - "Scaling in the large"||Mo Cheng||9/3/11 2:42 AM|
I'd like to say:
Thread should be system level concept; events are concept of application level.
|Re: [nodejs] Re: Node.js vs. Scala - "Scaling in the large"||joedev||9/3/11 5:14 AM|
I agree that scaling is hard, that is why it pays to 'scale' as little as possible - which is where doing more on less pays dividends.
|Re: [nodejs] Re: Node.js vs. Scala - "Scaling in the large"||Ambert Ho||9/3/11 10:15 AM|
That blog post is stating nothing controversial - it's pretty much done in the same manner as the posts done by many DBAs in a similar admonishing counterpoint to the "nosql fanboy" movement.
Most experienced developers know this already, I think the authors of these blog posts are just irritated by the type of person who says "MongoDB is faster because it's in memory" or "CouchDB is faster because you don't need to join data." <--- and "Node.js scales because it doesn't use threads" is a similar irritating statement.
|Re: [nodejs] Re: Node.js vs. Scala - "Scaling in the large"||Nick Campbell||9/3/11 11:06 AM|
Its not that those statements are necessarily incorrect but they aren't substantiated. They leave out a massive amount of additional information- information that would be useful to validate such claims. It is the same as fighting against someone who finds a single usecase where a technology doesn't work well and claims that the tech is terrible when if fact its terrible for that usecase.
Mostly though it is that people will make those claims without having done any research. Pick the right tool for the job.
- Nick Campbell
|Re: [nodejs] Node.js vs. Scala - "Scaling in the large"||Naouak||9/2/11 10:34 PM|
The author implies that if you do web developpement, you don't know a shit about concurrency and is insultingg web developpers (implying they are dumber tham regular programmers).
Le 3 sept. 2011 07:03, "Mark Hahn" <ma...@boutiquing.com> a écrit :>> I'm looking for responses to the points raised here<http://al3x.net/2010/07/27/node.html>
>> - Sri
|Re: [nodejs] Node.js vs. Scala - "Scaling in the large"||Marco Rogers||9/3/11 2:23 PM|
The author isn't insulting anybody except those who don't take the topic seriously and buy into pre-canned answers. Those people, along with people who read too much into things and get defensive for no reason, are the primary reason we can't have helpful discussions about these things.
|Re: [nodejs] Re: Node.js vs. Scala - "Scaling in the large"||Branko Vukelić||9/3/11 4:16 PM|
On 2011-09-03 02:31 -0700, Floby wrote:
I'm not an expert, but I believe it goes something like threads that run
Love coffee? You might love Loveffee, too.
|Re: [nodejs] Node.js vs. Scala - "Scaling in the large"||tedsuo||9/3/11 4:31 PM|
I don't think he's being insulting.
The real point he's making is pretty straight forwards: in node, there is only one concurrency model. A number of other platforms offer multiple concurrency models. If you want access to one of those other models down the line, you will have to carve off that part of your application and rewrite it in another language. And there's definitely an added cost in throwing another language into the mix, depending on what parts of your application need to be ported it could be way more of a rewrite than if you could write it all in one language. So... why not use a platform that already supports all of the concurrency models? I.E. Scala on the JVM? It's a valid enough point when choosing a platform, if you can't predict the problems your application is going to hit 2 years down the line.
How much of this can be mitigated by writing C++ addons? What of the possibility of writing threaded and actor-based components in C++? Node already exposes a number of treaded activities in this manner, but the documentation indicates that it's a painful process, and I've never written one. I don't have a big ego, so it's easy for me to ask naive questions like this. :)
|Re: [nodejs] Node.js vs. Scala - "Scaling in the large"||Branko Vukelić||9/4/11 12:05 AM|
On 2011-09-03 16:31 -0700, Ted Young wrote:
> The real point he's making is pretty straight forwards: in node,> SNIPPAGE
Yes, author does make a valid point, and I fully agree. Yet I feel most
Software engineers may seem more rational than non-programmers, but we
|Re: Node.js vs. Scala - "Scaling in the large"||Rob Evans||1/8/12 9:07 AM|
I'd like to jump in and make a few points if I may.
As you can probably imagine, scalability is a pretty damn important issue when designing a network-based game engine. Isogenic needs to be fast and efficient on both sides of the network connection and able to handle many concurrent clients.
I actually agree completely that it's not about which tool is better or worse "overall"... but rather that you need to pick one for your specific use case.
You can see a diagram of how Isogenic Engine is designed to handle multiple client connections here: http://www.isogenicengine.com/documentation/server-layout-diagram/
So far we have tested the connections up to just over 8,000 active players all in the same world, running across between one and three game servers at a time.
We are able to efficiently scale our world by firing up new game server instances that are running in their own thread and communicating with each over over TCP/IP. Persistent world changes are stored in MongoDB so that if a server instance dies or gets killed the game data is restored once the instance is brought back up.
As each new instance is brought up, it announces itself to the others and begins to accept client connections. The main management system can automatically fire up new instances so physical servers can run multiple Node.js game server instances on request from the control server.
The game being tested against is a city-builder demo called IsoCity that has a basic functional capability to allow players to place, move and remove entities from the city world which is kept in sync across all game instances and changes are communicated to connected clients so that they all see the same simulation.
Whilst around 8,000 active players might sound low to you, there is no reason why this cannot scale indefinitely using the current pattern by adding more hardware and firing up more game server instances. Connecting clients are directed to the game server with the least amount of load so that connections are distributed evenly, whilst the control server is kept informed of the number of connections each game server has and can issue fire-up commands to new instances as required.
The whole thing has been a total learning experience for me and although I do not claim to be an expert in all things scale-related, I have single-handedly deployed data analysis systems at my day-job that are used by practically every major bank in the world to do real-time intensive market analysis (not in Node.js for clarity).
Node.js DOES have it's uses and scaling (whilst not entirely automatic) can be achieved with some know-how and fore-thought.
Once Isogenic has been battle-tested with 1 million active players... then I might be telling a very different story but I'm confident at the moment that we're on the right track.
|Re: Node.js vs. Scala - "Scaling in the large"||mlegenhausen||1/8/12 11:53 PM|
The author just hacking around one thesis made by ryan, that you can
easy build scaling systems. Which is true when you have one server...
and even it is not true the benchmarks reference in the article don't
show that it is slower. Overall I would prefer a system where I don't
have to care about concurrency and in normal web development you don't
want to have to. All of the web frameworks I know from other systems
hide this currency part away from the developer.
There are so many other points he never said a word about... He sound
like the typical java developer, which I was also before and I love
1. You have only one code base. You can share the same code on both
sides and object serialization was never that easy.
Java world) when you have understand the language and don't try to use
the bad parts ;)
developers or your GUI developers can support you on the server side
or even better it is the first time that both sides understand each
other that easily. That can make your development process much more
agile. Try this with your java developers ;)
4. The performance/development time ratio I think is currently the
best. I can benefit from reusing code and the specialization in
development of web/network applications and can have a high scalable