When should I use asynchronous or synchronous methods in ASP.NET MVC applications (index, search, delete, create)?

The general recommendation for asynchronous use is when the operation takes at least 50ms. Less than that does not make up for it. In fact you have to measure your situation, there are cases that even more can not compensate.

Asynchronism is useful for improving the user experience when there is some operation that takes a lot of time to execute. So a customer can remain available when he asks for something for a service that takes time. It is not used to make something faster.

If you consider that asynchrony seldom gives gain in operations that require only processing, without IO, then it is rare to be useful anywhere, unless you configure the HTTP server to not accept too many requests and overload the server, or operations of IO are too long, or at least you do not have much control of the time it takes.

There will be scale gain in doing some long IO operation on action .

  

Can I lose performance?

Yes, asynchronism is not free. Whenever you use it you will experience a loss of performance, especially if you use thread . The gain it gives is running in parallel, so you can meet more requests. The specific request will not be faster at all.

So make sure there is some gain before using this mechanism.

  

In which situations should I use one or the other, could you give examples?

Access to database, file system, various services of the server that makes IO, services external to the server, especially the internet, any long IO.

IO asynchrony can release an ability to serve more requests if done properly when there is gain.

  

If I have many users querying on a single async page with requisition to the database, would not this generate a large queue depending on the application's runtime? How is this managed so as not to prevent the next ones from running?

Each request to the page is independent and this is already a good thing to improve scalability.

The queue will be generated according to the configuration of the HTTP server. What's the use of not having the queue on the HTTP server and having it in your application or query to the database?

  

Does using asynchronous methods prevent DDoS attacks?

There are cases that can facilitate DDoS. It's a question of what to do in a way that does not cause more problems than solutions.

If the direct client of your application is an HTTP server and the application lets it handle more requests asynchronously, it can bog down the application or the database and end up stopping everything. The problem is that the HTTP server is your client there and it manages to ask a lot, unlike a normal user. When the client can ask for more that the service can meet is an invitation to the disaster.

The same goes for any other feature that does IO and is less capable than the HTTP server. That you have to evaluate case by case. Of course there are some ways to scale the IO to meet any demand. You need to evaluate whether it pays off or better to go down a simpler path. There is no single rule.

Increasing scaling causes DDoS to take longer or even be avoided in "weak" attacks. But after a certain point it is possible that the gain in scale will worsen the situation because it transfers the problem to a place where it is more difficult to do throttling .

Additional information

Making the page in the client (browser) asynchronous is interesting in many situations because it allows the page to continue to function normally while waiting for the return of a request to the server. But you can not guarantee that the request will be made asynchronously. It is always "law" that you can not trust the customer that you do not have full control of.

I'm just talking about ASP.NET MVC. There may be other restrictions depending on the other technologies involved in the operation.

If you want to dig deeper you have a MSDN Magazine article .

Documentation .

  

When should I use asynchronous or synchronous methods in ASP.NET MVC applications (index, search, delete, create)?

In all input and output operations or operations whose execution is long: access to databases, files, external services, etc.

  

Can I lose performance?

It may, but it depends on how you are using the operation. For example, using Thread.Run() for everything does not necessarily make the application faster. Excessive use of the thread pool is a situation that can lead to loss of performance.

  

In which situations should I use one or the other, could you give examples?

You did not cite the Entity Framework as tag , but it is important to cite it as an example because it is very common to use the Entity Framework with ASP.NET MVC.

In any operation with the Entity Framework it is recommended to use asynchronous operations, precisely because it is a bank operation (be it selection, inclusion, update or deletion), and is therefore considered a long operation. >

In calls to web services or endpoints REST it is also recommended to use asynchronous operations. In the examples on the internet, it is easy to see that only asynchronous operations are used for consumption of services. See that the HttpClient class has no synchronous option for Get methods.

Now cases in which the execution must be asynchronous are all those whose achievement of the result is imperative for the continuation of the logic of the following method. The exception are transaction scopes from .NET 4.5.1, where TransactionScope has been granted the TransactionScopeAsyncFlowOption .

  

If I have many users querying on a single page async with request to the database, would not this generate a large queue depending on the application's runtime?

     

How is this managed so as not to prevent the next ones from running?

It depends. In asynchronous scope, the parallel load is passed to the database, if the library in question has asynchronous support in C # (the SQL Server client). The most critical case that this can happen is in operations involving transactional scope and there is no contingency to balance the load (or rather, Microsoft Distributed Transaction Coordinator ).

Once the transactional scope is blocked, the transaction coordinator harmonizes the transactions on a first-come, first-served basis, to a cluster .

  

Does using asynchronous methods prevent DDoS attacks?

No. They are two different things. DDoS is a purposeful server overload with the firing of a significant amount of requests in a short time, drowning the server, if this server instantiates memory for each request served. By targeting server memory (primary memory), the use of asynchronous methods helps, but does not prevent the problem.

To avoid DDoS, there are two ways:

By the server, is a bit more complex , but it is a more complete method. It involves constant monitoring and blocking of IP ranges.

By application, you can use bandit . There's NuGet. Or the Mads Kristensen method .

In my evaluation, the use of asynchronous means brings complexity that in most cases can be avoided, using synchronous methods. Each case must be evaluated, and it will depend very much on the developer feeling safe, as he must master the technique. There is an excellent article that addresses the subject: Attack of the Killer Microseconds
The article highlights that Google prefers to use synchronous programming whenever possible and try to leave asynchronous tasks for the operating system.