Live data from Hacker News

Everything .NET programmers know about Asynchronous Programming is wrong

hanselminutes.com

11–20 of 57 posts

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#11
post #8

Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…

You raise a question, but there's a missing detail in your input - how many machines (and what kind) you are using. If you have 80,000,000 machines serving 80,000,000 requests - that's not very impressive. Even if you have 80 servers, that's extremely unimpressive. If you can do all of that on 1 server, then YOU probably don't need async. In fact, unless you're wasting time, 80,000,000 averages less than 10 requests/…

> In fact, unless you're wasting time, 80,000,000 averages less than 10 requests/second...

Please show your math.

I took 80000000 / (24 * 60 * 60) and I got 925.

So you seem off by about two orders of magnitude.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#12

Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…

I think async is a systems programming tool rather than an application programming tool. If you're writing a web server or a web browser, it'd be useful. But for a web application, you're already sitting on a highly scalable and robust async library called IIS so when you need a background task the easiest thing to do is to make it a RESTful API call. I find many web developers now intuitively break up their application into parallelizable chunks without ever really thinking about async or threads, they just just say "this web page is taking a long time to load, maybe I can defer some of the work until after the page load" or (as you seem to have done) "maybe I can use tools like AppFabric Workflow to orchestrate all these small tasks".

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#13

Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…

If you're not blocking threads, either explicitly on I/O, or on perceptibly lengthy CPU operations[1], and you don't have a high proportion of kernel CPU% that can be put down to the cost of thread switching, then you personally don't really need async.

But it's a big leap to go from that to saying that nobody else needs async, so it need not go in the language.

[1] Taking the calculation off the main thread isn't the only way async can help here. The primitives also give you a way for taking better advantage of multiple cores (futures) more easily.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#14

Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…

Maybe you don't need concurrency, but I certainly have in almost all my jobs thus far. async/await is pretty great for this, especially when you need to mix concurrency and UI. Making it a language feature (instead of a library) makes the concurrent operations a lot more readable by avoiding a lot of nesting.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#16
post #12

Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…

I think async is a systems programming tool rather than an application programming tool. If you're writing a web server or a web browser, it'd be useful. But for a web application, you're already sitting on a highly scalable and robust async library called IIS so when you need a background task the easiest thing to do is to make it a RESTful API call. I find many web developers now intuitively break up their applicat…

The problem is that it's pretty useless in non-systems programming language.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#17
post #8

Earlier quoted context omitted.

You raise a question, but there's a missing detail in your input - how many machines (and what kind) you are using. If you have 80,000,000 machines serving 80,000,000 requests - that's not very impressive. Even if you have 80 servers, that's extremely unimpressive. If you can do all of that on 1 server, then YOU probably don't need async. In fact, unless you're wasting time, 80,000,000 averages less than 10 requests/…

> In fact, unless you're wasting time, 80,000,000 averages less than 10 requests/second... Please show your math. I took 80000000 / (24 * 60 * 60) and I got 925. So you seem off by about two orders of magnitude.

Please show your math.

I took 80,000,000/86400 and I got 926.

So you seem to be off by about 1.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#18
post #8

Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…

You raise a question, but there's a missing detail in your input - how many machines (and what kind) you are using. If you have 80,000,000 machines serving 80,000,000 requests - that's not very impressive. Even if you have 80 servers, that's extremely unimpressive. If you can do all of that on 1 server, then YOU probably don't need async. In fact, unless you're wasting time, 80,000,000 averages less than 10 requests/…

Your math is off.

It's on a bell curve. We're regionally tied so we have 80,000,000 requests, 90% of which are over a 5 hour period so we can hit 5000 requests a second on a fun day :)

We do this on 10 servers. 4 front end, 4 back end, 2 database nodes. They are all hefty machines (FE=8xXeon,16Gb;BE=16xXeon,32Gb,DB=48xXeon,96Gb;Storage=12TiB SAN).

Our peak cluster load is about 20% (the sweet spot).

We don't need async, even if we lost half of our nodes.

Post reply on HN