When to use asynchronous or synchronous method?

Question

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

Can I lose performance? In which situations should I use one or the other, could give examples?

If I have many users consulting on a single page async with request to the database, wouldn’t this generate a long queue depending on the application’s running time? How this is managed not to stop others from running?

The use of asynchronous methods prevents Ddos attacks?

Answer 1

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

The general recommendation of using asynchrony is when the operation takes at least 50ms. Less than that does not compensate. In fact you have to measure your situation, there are cases that even more may not compensate. And this may vary over time with various updates.

Asynchronmentalism is useful to improve user experience when there is some operation that takes a lot of time to execute. So a customer can remain available when he orders something for a long service. It’s not used to make something faster.

If you consider that asynchrony rarely gains in operations that require only processing, without IO, then it’s rarely useful anywhere, unless you set up the HTTP server to not accept too many requests and overload the server, or the IO operations are too long, or at least you don’t have much control of the time it will take.

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

I can lose performance?

Yes, asynchrony is not free. Whenever you use it you will have a loss of performance, especially if you use thread. The gain it gives is concurrent execution, so you can meet more requests. Specific request will not be faster under any circumstances.

So make sure there’s some gain before using this mechanism.

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

Access to database, file system, various server services that make IO, services external to the server, especially through the internet, finally any IO that is long.

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

If I have a lot of users searching a single async page with a database request, wouldn’t that generate a long queue depending on the application’s run time? How this is managed not to stop others 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 HTTP server configuration. What’s the point of not having the queue on the HTTP server and having it in your application or in the database query?

The use of asynchronous methods prevents Ddos attacks?

There are cases that can facilitate Ddos. There is a question of how to do it in a way that does not cause more problems than solutions.

If your application’s direct client is an HTTP server and the application lets it meet more requests asymptotically, it can jam the application or database and end up stopping everything. The problem is that the HTTP server is your client there and it can ask a lot, unlike a normal user. When the customer can ask for more that the service can meet is an invitation to disaster.

The same goes for any other resource that does IO and is less capable than the HTTP server. This you have to evaluate on a case-by-case basis. Of course there are some ways to scale the IO to meet every demand. You need to assess whether it pays off or whether it’s better to go the simple way. There is no single rule.

Scaling up causes Ddos to take longer or even be avoided in "weak" attacks. But after a certain point it is possible that the scale gain worsens the situation because it transfers the problem to a place where it is more difficult to do throttling.

Additional information

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

I’m only talking about ASP.NET MVC. There may be other restrictions due to the other technologies involved in the operation.

If you want to dig deeper, there’s a article in MSDN Magazine.

Documentation.

Answer 2

When to use asynchronous or synchronous methods in controllers (Index, search, delete, create) of ASP.NET MVC applications?

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

I can lose performance?

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

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

You did not quote Entity Framework as tag, but it is important to cite it as an example because it is very common to use 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 database operation (whether selection, inclusion, update or exclusion), and is therefore considered a long operation.

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

Cases in which the execution must be asynchronous are all those whose obtaining the result is essential for the continuation of the logic of the method to be followed. The exception are trade scopes from . NET 4.5.1, where TransactionScope won the option TransactionScopeAsyncFlowOption.

If I have many users consulting on a single page async with request to the database, this would not generate a long queue depending on the execution time of the application?

How this is managed not to stop others from running?

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

Once the transaction scope has been blocked, the transaction coordinator harmonises transactions on the order of arrival, either to a single database server or to a cluster.

The use of asynchronous methods prevents Ddos attacks?

No. It’s two different things. Ddos is a purposeful overload to the server by triggering a significant amount of requests in a short time, drowning the server, if this server instantiates memory for each request met. By targeting server memory (primary memory), the use of asynchronous methods helps, but does not avoid the problem.

To avoid Ddos, there are two ways:

1. Configuring by the server;
2. Configuring by the application, using some library.

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

By the application, you can use Bandit. There’s Nuget. Or the Mads Kristensen method.

Answer 3

In my opinion, the use of asynchronous media brings complexity that in most cases can be avoided, using synchronous methods.
Each case should be evaluated, and it will depend a lot on the developer feeling safe, because he should master the technique.
There is an excellent article (in English) 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 the asynchronous tasks to the operating system.