

Re: My Space - Making .NET a Star Performer - mythz
https://github.com/mythz/ScalingDotNET

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

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

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

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

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

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

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

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

~~~
mythz
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?

~~~
jconley
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).

~~~
cipherzero
> 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?

~~~
jconley
[http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-
thr...](http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-
on-iis-7-0-and-6-0.aspx)

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

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

~~~
mythz
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 :)

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

~~~
mythz
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 :)

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

------
petervandijck
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?

~~~
DrJokepu
Where does he say that?

