Is there any difference in performance ( speed wise ) between a synchronous request and and asynchronous request?
What all are the reasons for using an asynchronous request??
You should mostly always use an asynchronous Ajax Request, in fact I know only about one place where a synchronous Ajax Request should be used which is if you're in an Ajax Request embedding a new JavaScript file on the client and then referencing types and/or objects from that JavaScript file in the return from the original Ajax Request. Then the fetching of this new JS file should (or can sanely) be included through using a synchronous Ajax Request...
Other then that you should always use asynchronous Ajax Requests. The most important reason is that a synchronous Ajax Request makes the UI (browser) unresponsive...
#Thomas Hansen answer is right but I found a clear explanation with benefits of Asynchronous.
Synchronous is simple, but wait for the server response, thus block the execution of the caller for a period and slower than asynchronous while processing the request.
Asynchronous is required setting, do not wait after submitting the request and immediately return control to the caller, thus faster than Synchronous.
I am coming here when I have to use upload control which has both functionalities in the question and looking the pros and cons of this functionality.
I got the another link which explained with a real example. (the link is the specific tool, so understand the logic)
The major difference is the response time from our servers. At the time of upload, synchronous will validate file and create the passcode in real-time. Asynchronous will send the file to our server's queue and deliver notification via email once it is processed.
Synchronous is not ideal for multiple, large CSV file since you will need to wait until the file is processed by the server to submit another request. On large files, this also may cause your browsers to return with timeout errors due to the server being too busy. If you have multiple files, asynchronous will allow you to submit multiple files to the server queue to be processed with a email receipt once completed.
https://www.aspsnippets.com/Articles/Difference-between-Synchronous-Sync-and-Asynchronous-Async-Request-Call-in-AJAX.aspx
there can be serious performance implications caused when it come to highly database intensive applications .. although it's very unlikely to happen .. and sending many Synchronous ajax calls can create a backlog .. so if the application database intensive and sending so many request at once it is better to make it asynchronous.
when its set to asynch the browser will fail all unresponsive request and continue with new once..
Related
As Ajax stands, I believe it is made available to make asynchronous call to server but why does it also allow to be set to synchronous as an option?
What would be the case when you want synchronous operation using Ajax?
AJAX predates many of the libraries, extensions, and languages we currently use for handling asynchronous interactions between client and server. Initially, deferred handling of a response was not easily accomplished on the client, so the design of AJAX allowed for the developer to indicate that some operations should wait for response by executing synchronously.
The ability to operate synchronously is still included in AJAX to maintain legacy code. It is really difficult to come up with a use case today that would require the use of a synchronous AJAX call.
In, for example, JavaScript AJAX libraries it is possible to abort an AJAX request. Is there any server side advantage to this or is it just for client-side cleanliness? Is it part of TCP?
If, for example, I am requesting via AJAX a Python based server service – which is resource intensive – from my JavaScript Web App and abort this AJAX request, is it possible that aborting will ease the load on the server, or will the my ajax library just ignore the response from the server?
It does not affect the server-side if you use your frameworks abort feature. The server will still process the request regardless.
Once you made an HTTP request to a resource URL on your server (be it Asynch or not, aka ajax or "regular"), you can't abort it from your client / with another http request (unless your service has some weird listener that awaits for potential consequent http requests and stops itself up receiving one). My proposition, if you have one resource and time consuming operation, either split it into simpler operations, parallelize it or at east make some periodic responses to at least inform the user that it's still working and hasn't died
When people create real-time web apps, they are leaving a ajax request open/long running.
how do they do this in javascript?
There is really no difference from a normal ajax request. A callback is associated with the XMLHttpRequest. Once the request is complete the callback is invoked. The difference is on the server-side where the request is held open until data is ready for the client, or a timeout occurs. On the browser side, the callback is invoked as each successive request is answered. The callback must process the data from the server and initiate another request. The request is handled asynchronously, so the browser is not blocked.
A really good example of the whole thing is the chat demo included in Tornado.
I have made webpage that uses Ajax to update some values without reloading the page. I am using an XMLHttpRequest object to send a POST request, and I assign a callback function that gets called when the response arrives, and it works just fine.
But... how in the world does the browser know that some data coming from some ip:port should be sent to this particular callback function? I mean, in a worst case scenario, if I have Firefox and IE making some POST requests at roughly the same time from the same server, and even making subsequent POST requests before the responses arrive to the previous ones, how does the data coming in gets routed to the right callback functions ??
Each HTTP request made is on a seperate TCP connection. The browser simply waits for data to come back on that connection then invokes your callback function.
At a lower level, the TCP implementation on your OS will keep track of which packets belong to each socket (i.e. connection) by using a different "source port" for each one. There will be some lookup table mapping source ports to open sockets.
It is worth noting that the number of simultaneous connections a browser makes to any one server is limited (typically to 2). This was sensible back in the old days when pages reloaded to send and recieve data, but in these enlightened days of AJAX it is a real nuisance. See the page for an interesting discussion of the problem.
Each request has its own connection. Means that if you have single connection, of course you will have single response, and this response will be in your callback.
The general idea is that your browser opens a new connection entirely, makes a request to the server and waits for a response. This is all in one connection which is managed by the browser via a JavaScript API. The connection is not severed and then picked up again when the browser pushes something down, so the browser, having originated the request, knows what to do when the request finishes.
What truly makes things Asynchronous, is that these connections can happen separately in the background, which allows multiple requests to go out and return, while waiting for responses. This gives you the nice AJAX effect that appears to be the server returning something at a later time.
I'm been reading up on Ajax and would like to see from the stackoverflow community if I'm understanding everything correctly.
So the normal client server interaction is a user pulls up a web browser types in a url and a HTTP request is sent to the server requesting the page and resources( css, pics ) from the web server. The web server responds to the client via HTTP the page/resources requested and the browser renders the html/JavaScript for the user to view the page.
1) So would it be safe to say that XMLHttpRequest( XHR ) object is doing the same process as the browser except your not requesting html from the server, your requesting text in some type of format?
2) Is it true that a XHR object is much like a regular object that can be manipulated by the program creating the object( like a normal object ), but also sends and receives data with another program( web server ) via HTTP?
3) So in my mind when a XHR is created it is loaded into memory and we setup some of the objects arguments when we do the request.open(“GET”, url, true). Once we do a request.send(null) the object basically attempts to “GET” the url via HTTP and once we get the data back from the server it is put in the responseText argument. Am I understanding this correctly?
4) Also synchronous vs asynchronous. When I think of synchronous I think of steps having to be followed in order. For example, I push a button, data gets sent to server, and I have to wait for data to come back before I can do anything else. With asynchronous connections I would push button, data gets sent to server, I do what ever I want while data gets sent back. Is this a good analogy?
1) Nope. The XMLHttpRequest object does exactly what its name implies -- it initiates an HTTP request. This request can be in XML, or HTML, or PHP. At the end of the day, the browser doesn't care, because in an AJAX request, it doesn't parse the request -- you have to do it yourself. So it doesn't automatically render the HTML from an AJAX request.
2) I'm not sure about manipulation (the XHR object may be immutable) but possibly. Would you ever need to extend it or manipulate it?
Yes, you can change properties of the object and so on. I apologize. I didn't understand you at first :)
3) Yep.
4) That's a great analogy. It's exactly what happens. Another analogy is a 4 lane highway is to asynchronous as a one-way street is to synchronous. If one car breaks down on the 4 lane highway, the rest can keep moving at their normal speed -- but if one breaks down on the one-way road, everything freezes. :)
Here I leave you a good graphic to see clearly the behavior differences between the synchronous and asynchronous application models:
(source: adaptivepath.com)
It would appear that you have a job grasp of how AJAX works. I can't see much to disagree with in your summary of the plumbing of an AJAX application.
I would say however that with the XMLHttpRequest object you aren't restricted to GET. You can also use POST and other HTTP verbs.
With async calls you register a callback function, the XMLHttpRequest object calls your method when the async request completes.
Seems ok to me.
Your first point though is not entirely correct, you can request html from the server using ajax is doesn't have to text, json or xml like most examples show.