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

http://highscalability.com/blog/2012/10/15/simpler-cheaper-faster-playtomics-move-from-net-to-node-and.html

by jpmc • 14 years ago

30 15 14 years ago

vyrotek• 14 years ago

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.

aespinoza3• 14 years ago

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.

benologist3• 14 years ago

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!

Rastafarian2• 14 years ago

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)

mrkurt• 14 years ago

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...

Rastafarian2• 14 years ago

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.

ctrlaltesc• 14 years ago

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.

meaty2• 14 years ago

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.

benologist3• 14 years ago

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.

meaty2• 14 years ago

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

valdiorn• 14 years ago

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

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

Related Stories