I have a scenario in my existing application where on the click of a Save button a Javascript function is called. This javascript function internally makes 4-5 asynchronous calls to webservices.For some reasons we have big javascript files now with lot of business logic. Also we are facing performance issues in the application. To reduce the number of XHR calls we are making to the server, we thought of consolidating these calls on the server side and just make a single call from our Javascript.
On the server side we are using Async Await to make this calls asynchronous.So we have created a wrapper service with one method which now calls different service methods using SendAsync method exposed by HTTPClient.
Our underlying services are all synchronous and to achieve asynchronous functionality we used HTTPClient. We measured performance and it shows considerable gain.
But, one of our colleague pointed out that we will actually have an overhead of serialization and Deserialization as well as we are originating now other webservice calls from server which will ultimately run synchronously.So why not directly call the methods instead of new HTTP calls.
ow our methods are all synchronous and to make them asynchronous we will have to use Tasks which will again be overhead.
Both the approaches will be overhead but we see the making new HTTP requests using async await more inline with the microservices concept.
There is a debate and I would like to know other thoughts.
My two-cents:
The approach of aggregating the information on the server side is good.
From my point of view the use of HTTPClient internally on the server side is a solution only if you want to connect to a legacy service and you do not have the ability to integrate it directly. HTTPClient is simple to use and robust, but it's technically a lot more overhead than using a Task (think of error handling, serialisation, testing, network/socket-resources).
A Task is also nice, since it allows proper cancelation, which HTTPClient cannot achieve (HTTPClient can only close the socket, other end could still block resources).
On top of the general resource aspect, the use of Futures makes the Task a perfect match:
https://msdn.microsoft.com/en-us/library/ff963556.aspx
Related
If you use a fetch method for HTTP communication in a code that does not consider asynchronous processing at all, all functions (even the main function, to take it to the extreme) that include a fetch method, even if only a little, will need to use async/await (asynchronous processing) Is it necessary to think about
Or can we limit the scope of asynchronous processing?
It is normal to go async all the way.
If you use a hexagonal / ports-and-adapters architecture, you can (sometimes) extract the I/O operations into "ports" and keep your core business logic synchronous. But the composition of the synchronous business logic and the asynchronous ports is asynchronous, so your main entry points are almost always asynchronous.
Is it worthwhile to use Task based Asynch action methods in an ASP.NET MVC project to retrieve a bunch of EntityFramework queries which use LINQ-to-EF. The website is hosted in Azure as is the database. There are quite a few queries that load up a bunch of arrays to send via JSON to an ajax call from the client.
It is worthwhile as long as you are using truly async api (such as EntityFramework async methods) and not creating an async wrappers for example by wrapping your synchronous core in Task.Run or Task.FromResult.
Asynchronous method doesn't suppose to block any thread while it executes (Great article about this).
By the way, because both your application and database are cloud based, it actually makes sense to look into async approach since both your application and you DB can scale.
Technically, it's all three. There's network latency in sending the query/receiving the results. There's CPU-bound work when SQL Server or whatever is actually running the query against your database, and there's I/O as the database itself is a file on the filesystem.
However, from the perspective of your application, interacting with an external database via Entity Framework is network-bound, and is eligible for async as a result.
However, async is not a magical pill that will make your app run faster. If anything using async can actually slow your application down, as there's a lot of overhead to make async work. It's only purpose is to allow the thread doing work to return to the pool while it waits on some task outside of its control to finish. In the case of a database query, the query is sent off to the database which takes some period of time depending on network latency. The database must run the query and construct a result which takes some period of time depending on the resources available on that server. Then, the result is sent back to your application, which again incurs network latency. In a synchronous scenario, your application would just sit there and wait, holding onto the thread. In an async scenario, the thread is released to do other work (server other requests for the web server, etc.) and then when the database response is received the thread is requested back to finish whatever was going on in the application.
In case it's not obvious, the purpose of this is to allow the web server or whatever else you're working with to handle additional load by utilizing periods of what otherwise would be downtime doing other work. In that regard, async is important for using resources efficiently, but it's not necessarily quicker or more performant.
Do I need to do anything to make all requests asynchronous or are they automatically handled that way?
I ran some tests and it appears that each request comes in on its own thread, but I figure better to ask as I might have tested wrong.
Update: (I have a bad habit of not explaining fully - sorry) Here's my concern. A client browser makes a REST request to my server of http://data.domain/com/employee_database/?query=state:Colorado. That comes in to the appropriate method in the controller. That method queries the database and returns an object which is then turned into a JSON structure and returned to the calling app.
Now let's say 10,000 clients all make a similar query to the same server. So I have 10,000 requests coming in at once. Will my controller method be called simultaneously in 10,000 distinct threads? Or must the first request return before the second request is called?
I'm not asking about the code in my handler method having asynchronous components. For my case the request becomes a single SQL query so the code has nothing that can be handled asynchronously. And until I get the requested data, I can't return from the method.
No REST is not async by default. the request are handled synchronously. However, your web server (IIS) has a number of max threads setting which can work at the same time, and it maintains a queue of the request received. So, the request goes in the queue and if a thread is available it gets executed else, the request waits in the IIS queue till a thread is available
I think you should be using async IO/operations such as database calls in your case. Yes in Web Api, every request has its own thread, but threads can run out if there are many consecutive requests. Also threads use memory so if your api gets hit by too many request it may put pressure on your system.
The benefit of using async over sync is that you use your system resources wisely. Instead of blocking the thread while it is waiting for the database call to complete in sync implementation, the async will free the thread to handle more requests or assign it what ever process needs a thread. Once IO (database) call completes, another thread will take it from there and continue with the implementation. Async will also make your api run faster if your IO operations take longer to complete.
To be honest, your question is not very clear. If you are making an HTTP GET using HttpClient, say the GetAsync method, request is fired and you can do whatever you want in your thread until the time you get the response back. So, this request is asynchronous. If you are asking about the server side, which handles this request (assuming it is ASP.NET Web API), then asynchronous or not is up to how you implemented your web API. If your action method, does three things, say 1, 2, and 3 one after the other synchronously in blocking mode, the same thread is going to the service the request. On the other hand, say #2 above is a call to a web service and it is an HTTP call. Now, if you use HttpClient and you make an asynchronous call, you can get into a situation where one request is serviced by more than one thread. For that to happen, you should have made the HTTP call from your action method asynchronously and used async keyword. In that case, when you call await inside the action method, your action method execution returns and the thread servicing your request is free to service some other request and ultimately when the response is available, the same or some other thread will continue from where it was left off previously. Long boring answer, perhaps but difficult to explain just through words by typing, I guess. Hope you get some clarity.
UPDATE:
Your action method will execute in parallel in 10,000 threads (ideally). Why I'm saying ideally is because a CLR thread pool having 10,000 threads is not typical and probably impractical as well. There are physical limits as well as limits imposed by the framework as well but I guess the answer to your question is that the requests will be serviced in parallel. The correct term here will be 'parallel' but not 'async'.
Whether it is sync or async is your choice. You choose by the way to write your action. If you return a Task, and also use async IO under the hood, it is async. In other cases it is synchronous.
Don't feel tempted to slap async on your action and use Task.Run. That is async-over-sync (a known anti-pattern). It must be truly async all the way down to the OS kernel.
No framework can make sync IO automatically async, so it cannot happen under the hood. Async IO is callback-based which is a severe change in programming model.
This does not answer what you should do of course. That would be a new question.
I'm just wondering, if I have an ASP.net Web Application, either WebForms or MVC, is there any situation where doing stuff asynchronously would make sense?
The Web Server already handles threading for me in that it spins up multiple threads to handle requests, and most request processing is rather simple and straight forward.
I see some use for when stuff truly is a) expensive and b) can be parallelized. but these are the minority cases (at least from what I've encountered).
Is there any gain from async in the simple "Read some input, do some CRUD, display some output" scenario?
If a page is making a request to an external web service on every request, then using the asynchronous BCL APIs to fetch data from the web service will help free up resources on the server. This is because Windows can make a distinction between a managed ASP thread that is waiting for stuff (asynchronous web service call) and a managed ASP thread that is doing stuff (synchronous web service call). These asynchronous calls may end up as I/O Completion Ports behind the scenes, freeing ASP from essentially all of the burdens. This can result in the web site being able to handle more simultaneous requests. Specifically, when an ASP thread is waiting for a callback from an asynchronous operation, ASP may decide to reuse that thread to serve other requests in the meantime.
The synchronous BCL way to invoke external resources is the Get(), Read(), EndRead() etc family of methods. Their asynchronous counterpart is the BeginGet(), EndGet(), BeginRead(), EndRead() etc family of methods.
If you have a page that does two things simultaneously, and both are essentially wait for external data type operations, then the asynchronous BCL APIs will enable parallellism automatically. If they are calculate pi type operations, then you may want to use the parallell BCL APIs instead.
Here's one example when you will clearly gain from an async call: imagine that in order to render a page you need to aggregate information coming from different web services (or database calls) where each being independent and resulting in a network call. In this case the async pattern is very good because you have IO bound operations for which IO Completion Ports will be used and while waiting for the response you won't monopolize worker threads. While the operations are running no thread will be consumed on the server side.
If you have many CPU bound operations than async pattern will not bring much benefit because while you free the request worker thread from performing the operation, another thread will be consumed to do calculations.
I find this article a very useful reference.
I'm setting up a web service in Axis2 whose job it will be to take a bunch of XML and put it on to a queue to be processed later. I understand its possible to set up a client to invoke a synchronous web service asynchronously by creating a using an "invokeNonBlocking" operation on the "Call" instance. (ref http://onjava.com/pub/a/onjava/2005/07/27/axis2.html?page=4)
So, my question is, is there any advantage to using an asynchronous web service in this case? It seems redundant because 1) the client isn't blocked and 2) the service has to accept and write the xml to queue regardless if it's synchronous or asynchronous
In my opinion, asynchronous is the appropriate way to go. A couple of things to consider:
Do you have multiple clients accessing this service at any given moment?
How often is this process occurring?
It does take a little more effort to implement the async methods. But I guarantee, in the end you will be much happier with the result. For one, you don't have to manage threading. Your primary concern might just be the volatility of the data in the que (i.e. race/deadlock conditions).
A "sync call" seems appropriate, I agree.
If the request from the client isn't time consuming, then I don't see the advantage either in making the call asynchronous. From what I understand of the situation in question here, the web-service will perform its "processing" against the request some time in the future.
If, on the contrary, the request had required a time consuming process, then an async call would haven been appropriate.
After ruminating some more about it, I'm thinking that the service should be asynchronous. The reason is that it would put the task of writing the data to the queue into a separate thread, thus lessening the chances of a timeout. It makes the process more complicated, but if I can avoid a timeout, then it's got to be done.