Simpler, Cheaper, Faster: Playtomic's Move From .NET To Node And Heroku | Hacker News Reader

Simpler, Cheaper, Faster: Playtomic's Move From .NET To Node And Heroku

highscalability.com

30 pointsjpmc15 comments

IMHO these guys just didn't architect and configure .NET to suit their loads. ADO.NET connection pool is adjustable, it's trivial to setup a (NodeJS style) single DB connection per app pool.

I'm also not seeing anything here that couldn't be done in the JVM either. The numbers aren't spectacular for eight dedicated hardware boxes.

Well, good for them for choosing a technology that they enjoy and making it work. There's more than enough room for another mature application platform.

They seriously must have been doing something wrong. We scale to 2000 requests a second on a good day on one not very hefty quad core SQL server 2008 box with 16Gb of ram and 2 front end web servers and a virtual active directory host. The requests are between 2-4 SQL queries a hit as well and can return hundreds of rows with 6 way joins galore thanks to nhibernate. Latency per hit is always less than 80ms.

We've done literally no tuning as well. It's all out of box. It just sucks up the requests and spits them out with a smile.

2,000 reads a second is not the same as tens of thousands of rows being updated or inserted a second. MSSQL is also not the bottleneck, flushing data to it is decoupled from the requests.

We do that as well. Our architecture is CQRS based so we're doing massive batched denormalisation and heavy writes.

Nice write up. Things have certainly changed since the first time I saw benologist comment about the original architecture on HN. At the time I was excited to know there were other startups using .Net.

I know, I was also excited. We feel lonelier now.

Still by reading the article I still don't see how moving to another framework + platform made it better. Maybe our case is so very different.

I have considered the move for quite a while, every time I run the performance tests, .Net comes faster.

Maintainability wise, it is still easier to manage .Net applications than NodeJS. The tooling for testing (and not just Unit Testing) is abundant and mature.

Cost savings are also debatable. In our case, we measure Infrastructure Costs + Maintenance Costs, and windows is way cheaper putting the two together. Now, they are using a PaaS, so that might make it worth while. For us a PaaS is really not an option since we need a lot more control.

I do agree with the mongoDB choice. I love Mongodb. We us eMongoDB. But we have so many problems because it never reclaims deleted data. The size just grows. And that is maintenance hell. We are analyzing potential replacements.

For us, NodeJS still doesn't have that much to offer. :D So we are sticking with .Net.

I'm still ~50% .NET, the website and a lot of backend processing and maintenance software is staying C# because there's no benefit in shifting that to whatever language like there was with the API server.

I have started running some stuff under mono though!

You know, we have also began testing with mono on the backend. And I love it. This create a really cool flexibility of running your apps in Linux and Windows... :D

Did you had a look at .NET 4.5? It has WebSocket support and very convenient async keyword. Seems to me it can match easily match Node for a site like Playtomic.

(I was replaying to benologist's comment, but there's a bug in HN system)

This all started a few years ago on .NET 2.0 originally, the NodeJS rewrite began before the 4.5 beta was even announced.

While .NET 4.5 makes a lot of things easier, there's nothing new. Sweeping generalization: it's all been syntactic sugar since generics arrived in 2.0. (This was especially evidenced by all the magic done by the Rx people as the only MS team interested in supporting 'legacy' framework versions.)

For example, the 'official' WebSocket support (SignalR):

https://github.com/SignalR/SignalR/issues/96

  > Please support .NET 3.5 Please
  > ...
  > Of course it's technically possible, but it's not a goal.

Look into capped or TTL collections on Mongo, those are generally best for handling data churn. You can also check out the new usePowerOf2Sizes option on collections to see if that will help (TTL collections use these implicitly): http://docs.mongodb.org/manual/reference/commands/#usePowerO...

Thank you. I will definitely check that out. :D

Highscalability.com just hit my company proxy and was classified as a "malware site"... wtf?

Reply on news.ycombinator.com