Everything .NET programmers know about Asynchronous Programming is wrong
1–10 of 57 posts
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#2Genuine 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: you really need async in the language?
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#3Genuine 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…
It's about concurrency, not performance. What's the 95th percentile response time (backend only)?
Take out all that complicated code, and replace it with a call to an external 3rd party API. They get a hiccup, your response time goes up by 500%, your cpu load drops, and you start timing out connections.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#4The problem that I keep seeing is people think that TPL or Async/Await heck, even Rx is a Threading library....
As a result people still use monitors or any kind of blocking wait event. Including the TaskCompletetionSource in the framework I don't think helped this.
A lot of what I've seen on different projects using these newer tools is an attempt to re-create what they would do before. Doing a Producer Consumer, that's a blocking de-queue etc.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#5Genuine 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…
It's about concurrency, not performance. What's the 95th percentile response time (backend only)? Take out all that complicated code, and replace it with a call to an external 3rd party API. They get a hiccup, your response time goes up by 500%, your cpu load drops, and you start timing out connections. C10M http://www.youtube.com/watch?v=D09jdbS6oSI
We use appfabric and workflow to handle all 3rd party integration. Nothing blocks threads. But we don't use async language features to do that. Workflow could be considered async but it's a tenuous link.
95% is 41ms.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#6Genuine 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…
"WCF, AppFabric and ASP.Net" happen to give you an awful lot of that sort of infrastructure for free, I rarely directly use anything async in my web apps either. I do wonder how you're managing responsiveness in the forms apps though?
Where the async syntax really shines is dealing with external services. If you're calling a lot of database, web services, sockets etc it can make your life easier.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#7Earlier quoted context omitted.
It's about concurrency, not performance. What's the 95th percentile response time (backend only)? Take out all that complicated code, and replace it with a call to an external 3rd party API. They get a hiccup, your response time goes up by 500%, your cpu load drops, and you start timing out connections. C10M http://www.youtube.com/watch?v=D09jdbS6oSI
We use appfabric and workflow to handle all 3rd party integration. Nothing blocks threads. But we don't use async language features to do that. Workflow could be considered async but it's a tenuous link. 95% is 41ms.
async doesn't really give you anything new you couldn't do before, just nicer syntax for composing it all. As you say you've already found other ways to compose your asynchronous flows for you.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#8Genuine 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/second, and peak is likely less than 100 requests/second. That's really not much - I do that with interpreted python.
But every language does need facility for async processing.
edit: it's 1000/second, not 10/second, as everyone down here corrected. Apparently, I cannot math before coffee. (I don't drink coffee). Apologies.
fun mnemonic: the number of seconds in a day is 864e2. (eight-six-four-(e)-two).
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#9Genuine 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…
"WCF, AppFabric and ASP.Net" happen to give you an awful lot of that sort of infrastructure for free, I rarely directly use anything async in my web apps either. I do wonder how you're managing responsiveness in the forms apps though? Where the async syntax really shines is dealing with external services. If you're calling a lot of database, web services, sockets etc it can make your life easier.
To be honest our webforms app is tiny and only does basic integration tasks between legacy software and our web app so there are no points it can block.
We do everything synchronously with respect to databases. Integration is all docoupled into workflows.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#10Genuine 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…
>This begs the question: you really need async in the language?
Or even delegates. Or interfaces. Or LINQ.
Basically you could write the same thing in C.
Or assembly.