It isn't the end of the world in .Net but it will be the difference between a server handling fewer than 10K simultaneous requests and over 100K on modern hardware.
In general, as much as possible service could should be async... That said, a lot of code isn't. The breakup of the request pipeline and thread pooling in ASP.Net make it slightly less necessary, as it's still very efficient.
That said, you should probably introduce it using Parallel Linq as much as possible, and/or when you need to consume multiple resources in a given request.
If you're writing stand alone applications, and already using threads/thread pools, then it's probably less of an impact. If you're writing server/service applications then it does make a difference in terms of scalability.
But that's kinda my point, I don't use it because it makes the code more complicated, it's a premature optimization. C# is already blazingly fast.
To put it in context, 10K simultaneous requests is 10 billion page views per day (10000 * 10 * 60 * 60 * 24, assuming 100ms processing time, which is actually pretty high for .Net, mine are usually 60ms even on crap hardware. Yes it's a silly calculation, but it gives you an idea about the scale we're talking about). If you're at that scale, you can afford to hire John Skeet to go back over your code and add a few `async`s into it where appropiate.
From what you just said it seems that anyone using it all the time is unnecessarily cluttering their code.
I don't think that it's really a matter of cluttering code all that much... the keyword implies the intent and should be relatively easy to understand. Then again, I've spent about half my time in node the past few years, and getting async/await with babel makes the world easier to use.
Also, It's not like it doesn't do you any good. With async you may be able to reduce the size of your cloud instances, as an example... saving money in the end. Doesn't mean as much if you have a dedicated server, or existing codebase though. If you're doing a green web project, you should probably use async from the start.
In general, denormalizing and caching data, and using async requests are what improves overall responsiveness in an application. Async allows for a given request to have more than one outbound IO statement waiting for a response, and return the aggregate together.
Yes, but how many C# projects ever need that scale? If it's an internal enterprise app, the bread and butter of C# apps, it's a totally useless optimization. It wouldn't reduce the size at all.
The kind of web scale business that should be using async, let's be frank, those kind of projects don't use C#. Go look at the YC list of technology, not a single C# user on there.
If that's all you the benefit of using async is, it hopefully looks like I'm ok not using it.
But even in the enterprise responsiveness is appreciated... if you're making multiple calls on the backend... resource authentication, related item lookup, and other services, if you can run all of these requests asynchronously, then it's the max of those items plus a little overhead for conjunction... not using async is the aggregate... it's the difference between a sub-100ms response, or over... 100ms is nearly transparent, more than that is not.
I don't disagree that it isn't that much of a benefit in many cases, but tbh if I'm to chose between async usage and, for example ever seeing EntLib Data classes, or a DI/IoC tool when no testing is being done, I'll take async. There are plenty of practices in C#/.Net shops that are just hideous to work with, async imho isn't one of them.
We have a site that hits 10k simultaneous requests all the time and we do not get 10 billion pageviews per day. Here's a few reasons why:
Most sites have a peak load. Some of ours have a difference of 4x from peak to trough.
Traffic bursts are also common. Especially if something is going wrong. You should always plan for something going wrong.
Nothing sucks more than going down because of a traffic burst because you just brought your systems back up from a failure. In the past we didn't always plan for this and it could take an hour to get the site back to full health even after we fixed the original problem.
That's what I meant by a silly calculation as it assumes uniform load. But on the other hand, you've been so tight lipped about the actual details, I have no idea what to make of that. What is your normal response time? 60ms or 6 seconds? What tech stack are you using? What is your actual daily traffic?
Async has nothing to do with C# being fast. In fact, the faster C# is, the more you need async, because the more the % time blocked will increase.
Ideally, you'd have one thread per CPU. That's the most efficient. In reality, enough stuff blocks we gotta throw extra threads to let things saturate.
You can scale up the number of process-scheduled tasks much more than the number of kernel level threads. (Though, esp on x64, people might get really far just spamming threads.)
That's mixing speed up with volume. It would only matter if the volume of requests was higher too. If everything runs faster, the number of required threads goes down as the requests will be less likely to happen at the same time.
inbound service request
request remote resource
wait
request additional details for logged in user
wait
request X info
wait
resolve inbound request
Scenario 2
inbound service request
async requests
request remote resource
request additional details for logged in user
request X info
wait
resolve inbound request
In general, as much as possible service could should be async... That said, a lot of code isn't. The breakup of the request pipeline and thread pooling in ASP.Net make it slightly less necessary, as it's still very efficient.
That said, you should probably introduce it using Parallel Linq as much as possible, and/or when you need to consume multiple resources in a given request.
If you're writing stand alone applications, and already using threads/thread pools, then it's probably less of an impact. If you're writing server/service applications then it does make a difference in terms of scalability.