Re: My Space - Making .NET a Star Performer | Hacker News Reader

Re: My Space - Making .NET a Star Performer

github.com

39 pointsmythz21 comments

This just left me scratching my head.

But really, why is this argument even important? .NET can scale, if you toss out the religious arguments then you realize that just about anything can scale if you do it right. Which is the key point isn't it? The great startup lesson is that the PEOPLE are far more important than the technology.

At a high-level its always not obvious what the best choices are and occasionally, certain products encourage you down the wrong path - providing not-so-stellar end-user experiences.

I just wanted to share what I learnt in my research and provide as much awareness and guidance as possible so that .NET developers can use this as an entry/jump point into their own research.

Also in a round-about way prove that it is possible to do in .NET and what technologies you should look at to get there. Pure, free-flowing guidance / research on this topic is not always plentiful.

I generally find that if you are well read the first steps towards scaling ASP.Net / IIS are reasonably well guided. E.g. we've had things like solid caching support at a variety of different levels (app, cache, output etc) built right into the server / framework for a long time.

The web forms model has been a huge issue for programmers who are not mindful of its consequences and I'm glad MVC is making headway. I'm also happy to see MS starting to think about more developer oriented tool sets with projects like Nuget and Entity Framework Code First.

Scaling to higher levels is always going to require an awareness of design and architecture more fundamental than knowing any particular technology well.

Yeah that "premature optimization..." trope always bugs me. It is not a license to write the most non-performant code you can think of and then spend hours and hours tuning it later. That phrase was coined back when optimization meant inlining assembly, not simply putting some thought into your algorithms.

Part of the problem is TDD, people see the green bars fill but the customer regects it because guess what. In real world usage we arent running the method once, we are running it millions of times.

The operative word is "premature". Optimize when it is time to optimize - the OP touches on that.

If you know a given routine will be run a lot, then some optimization right off the bat is a good idea.

Now, that "knowing" is a little more difficult, but comes with user feedback and experience.

I just finished re-writing a wcf service using a home made async socket server over TCP. WCF is just way to complex to get right. By default, out of the box is it scaled down and slow. You have to do all kinds of config magic to get it to perform or send large amounts of data.

It took me a couple days of coding to have an async socket server (using .net async IO) up and running. It was so much easier.

Contrast that with several weeks spent learning WCF and then searching through blog posts to find the correct config example to handle problem after problem.

Caveat: I don't need to switch between different providers, manage security, etc, etc which WCF can do out of the box. I just needed a way to get data from a long running server to a web page. I just wanted some simple IPC, which WCF is not.

I need to write up a full post-mortem on this at some point, but I just needed to get that off my chest.

Yeah the impression I've gotten is unless you need most/all of the tools WCF supplies you shouldn't use it because it's so painful. And how often do you really need a majority of the stuff it supplies?

I know what you're talking about. WCF config doesn't come across as easy - sometimes you just wanna say "listen on port 1234 for these messages". The complex capabilities combined with some stupid default settings makes it much more daunting than it should be.

That said, after you get a few basics down, it really is rather straightforward. The gain for me is not having to manually write code to deal with security/encoding/serialization/exceptions. I mean, you define an interface, slap some attributes on, add 5 lines of config, another 5 to start the server, and that's pretty much it.

You should consider the powerful messaging features in Redis if you want fast IPC. Here's an article with an example using my C# Redis Client: https://github.com/ServiceStack/ServiceStack.Redis/wiki/Redi...

The section on non-blocking servers is just plain wrong. .NET and IIS have had this feature for at least ~8 years now. ASP.NET Webforms and ASP.NET MVC both have great support for various asynchronous patterns to support non-blocking operations. ADO.NET also has this built-in. I've been involved with projects that have used these features to great effect scaling into tens of thousands of simultaneous connections per server.

The IHttpAsyncHandler doesn't work the same as the non-blocking event loops in Unix which only uses a single process for all requests. We actually didn't fare to well ourselves and had a poor experience trying to debug them in IIS, in the end we moved to a bespoke windows service to service our comet requests.

But you're right it should be included - care to contribute a piece on the topic?

True, you won't get a single thread. You'll get a Threadpool. But we did like the flexibility of the Threadpool for things that had to be done synchronously or were not worth optimizing. It also allowed apps to take advantage of all CPU cores without extra configuration. With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want).

> With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want).

I am curious about this, can you provide a link or reference with more information?

http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thr...

"... If you’re curious to see how much faster ASP.NET requests execute without the thread switch, you can set the value to 0. This will cause the request to execute on the IIS I/O thread, without switching to a CLR Threadpool thread. ..."

Of course you would only ever set this if you are really doing every bit of I/O asynchronously in your application. Otherwise bad, bad things would happen (deadlock under load).

I've written some very high scale .NET socket/server code and this article left me scratching my head. In particular, the section on Blocking IO is confusing at best. I'm especially surprised to not see any mention of IOCPs and how they work in .NET since they're so core to any high scale server code.

Basically, it's because I have never developed with IOCP's before and their reliance on P/Invokes means its not a very popular option in .NET.

However I very much welcome any clarifications/contributions on this topic - please do send me a pull-request :)

Nice blog post. But why is it hosted as a GitHub readme?

well it's a personal real-world study to see if the Git/Hub workflow model works in collaboratively editing documentation :) especially since the audience that can help are going to be members of GitHub :)

I appreciate it. Using tools in ways not originally intended is a good thing. I'm curious if anything evolves from your idea.

If I read it correctly he's basically saying that, no, .NET doesn't really scale. Which seems to be the opposite of what he's wanting to say?

Where does he say that?

Reply on news.ycombinator.com