I'm trying to decide what the best solution would be for my web application. I have a page that will fire an arbitrary number of ajax requests to retrieve data from the server. For example a page on load may fire 10 ajax requests to the server and each request may take 10 seconds (+-) to return content.
In view of this being a web app in a multi user and multi concurrency environment is it a good idea to use a traditional ajax approach or would you opt for long polling, such as SignalR.
What are the pros/cons of both approaches (Pull vs Push)? Ultimately i'm after the most resource efficient approach.
Thanks
In your stated example you are talking about a pure 'Pull' scenario. ie 'When the page loads I want X, Y, Z to happen and then I want to see the results'.
Long polling/websockets (SignalR) is useful for a Push scenario - ie 'Oh look I have finished running this super long process... I better tell any users currently connected'.
You can use SignalR to run those normal style AJAX requests... but you wont get any performance enhancements. The AJAX will run asynchronously and in parallel and once the server side process is complete you will a callback that executes. Perhaps you might get a slight increase in performance as signalR will have a continuous connection running, so you will loose the slight delay in creating a connection. On the flip side the server will have a large number of open connections running which may degrade performance (especially if you are hitting it with 10 X 10 sec computations)
Related
I'm working on a single page web app which needs to load a lot of data on startup. An inital load can take up to 10 seconds, which can be quite frustrating when you just want to fix/check a minor change.
There are two ajax calls on startup which require the most time. Ideally I'd have some proxy running which can cache these calls as long as I like. It should also be possible to disable these responses easily.
This can be achieved quite easily using the AutoResponder functionality of Fiddler.
Just save the response of query and map it to a rule in the autoresponder rules.
We would like to check every 3 seconds if there are any updates in our database, using jquery $.ajax. Technology is clear but are there any reasons why not to fire so many ajax calls? (browser, cache, performance, etc.). The web application is running for round about 10 hrs per day on every client.
We are using Firefox.
Ajax calls has implications not on client side(Browser,...) but on the server side. For example, every ajax call is a hit on server. ie. more bandwidth consumption, no of server request hit increases which in turn increases server load etc etc. Ajax call is actually meant to increase client friendliness at the cost of Server side implications.
Regards,
Ravi
You should think carefully before implementing infinite repeating AJAX calls with an arbitrary delay between them. How did you come up with 3 seconds? If you're going to be polling your server in this way, you need to reduce the frequency of requests to as low a number as possible. Here are some things to think about:
Is the data you're fetching really going to change that often?
Can your server handle a request every 3 seconds, how long does the operation take for a single request?
Could you increase the delay after inactivity or guess based on previous server responses how long the next delay should be?
Can you stop the polling completely when the window loses focus, and restart it when it's in the foreground again.
If a user opens the same page in a website 10 times, your server should recognise this and throttle its responses, either using a cookie with a unique value in it (recommended) or based on the client IP address.
Above all, instead of polling, consider using HTML 5 web sockets to "push" data to the client - most modern browsers support this. Several frameworks are available that will fall back to polling if web sockets are not available - one excellent .NET example is SignalR.
I've seen a lot of application making request each 5sec or so, for instance a remote control (web player) or a chat. So that should not be a problem for the browser to do so.
What would be a good practice is to wait an answer before making a new request, that means not firing the requests with a setInterval for instance.
(In the case the user lose its connection that would prevent opening too much connections).
Also verifying that all the calculations associated with an answer are done when receiving the next answer.
And if you have access to that in the server side, configure you server to set http headers Connection: Keep-Alive, so you won't add to much TCP overhead to each of your requests. That could speed up small requests a lot.
The last point I see is of course verifying that you server is able to answer that much request.
You are looking for any changes after each 3sec , In this way the traffic would be increased as you fetching data after short duration and continuously . It may also continuous increase the memory usage on browser side . As you need to check any update done in the database , you can go for any other alternatives like Sheepjax , Comet or SignalR . (SignalR generally broadcast the data to all users and comet needs license ) . Hope this may help you .
I have a web app idea which will require AJAX requests to function. Its crucial that AJAX requests are running as long as the user is on the site.
My question is, if the user left the site up (my ajax requests will be running) for say 4/5 hours, will these AJAX requests still run, my concerns are screen dimming, screensavers, computer sleep states. Will all or none of these affect the performance of my web app?
Unfortunately, it's very client dependent. For example, mobile devices may stop processing JS when going into a sleep state (e.g., to save battery life). However, on an image rotator application I wrote some time ago, which sent regular requests to the server to retrieve images (there was good reason not to cache them, I swear), accessed primarily by non-mobile clients, I observed that requests continued for hours, even days. While I can't know if the client machine ever entered a sleep state, I'm pretty confident it did.
Long story short - I think you can't be sure, but for some target audiences, you can be reasonably sure. I would recommend investigating your audience.
If in your site users require to login simple keep a session time out option to lets say 15 mins. That means after 15 mins of idle time the session will be destroyed and the ajax requests automatically truncated.
If you do not have login this becomes difficult but still can be achieved via ip tracking or similar mechanisms but these will never be as full proof as the first one.
I must agree with Sean in that it it's very client side orientated. If the client stays active, be it through human interaction our not, then the AJAX should keep going.
I have a web application that relies on very "live" data - so it needs an update every 1 second if something has changed.
I was wondering what the pros and cons of the following solutions are.
Solution 1 - Poll A Lot
So every 1 second, I send a request to the server and get back some data. Once I have the data, I wait for 1 second before doing it all again. I would detect client-side if the state had changed and take action appropriately.
Solution 2 - Block A Lot
So I start a request to the server that will time-out after 30 seconds. The server keeps an eye on the data on the server by checking it once per second. If the server notices the data has changed it sends the data back to the client, which takes action appropriately.
Scenario
Essentially, the data is reasonably small in size, but changes at random intervals based on live events. The thing is, the web UI will be running something in the region of 2,000 instances, so do I have 2,000 requests per second coming from the UI or do I have 2,000 long-running requests that take up to 30 seconds?
Help and advice would be much appreciated, especially if you have worked with AJAX requests under similar volumes.
One common solution for such cases is to use static json files. Server-side scripts update them when the data is changed and they are served by fast and light webserver (like nginx). Since files are static and small - webserver will do that right in cache, in very fast manner.
Consider a better architecture. Implementing this kind of messaging system is trivial to do right in something like nodeJS. Message dispatch will be instantaneous, and you won't need to poll for your data on either side.
You don't need to rewrite your whole system: The data producer could simply POST the updates to the nodeJS server instead of writing them to a file, and as a bonus, you don't even need to waste time on disk IO.
If you started without knowing any nodeJS, you could still be done in a couple hours, because you can just hack up the chat example.
I can't comment yet, but I would agree with geocar. Running live or almost live web services with just polling will be solution stuck between a rock and a hard place.
You could also look into web sockets to allow push as this sounds a better solution for this than just updating every second to 30 seconds.
Good luck!
after an entire day of searches, I would to talk about the best solution for an online chat.
This is what I know:
Ajax poll is the old, bandwith consuming, and not scalable way of doing it. It makes a request for new data to the server every X seconds. This implies one database query every X seconds * number_of_connected_users.
Reverse Ajax and one of its application (comet) requires a customized web-server or a dedicated comet server which can handle the number_of_connected_users amount of long-time http connections.
My actual server is: 1 Xeon CPU, 1 GB of RAM and 1 Gb/s of bandwith. The server is a virtual machine (hence highly scalable).
I need a solution that could scale with the server and the future growing user base.
My doubts are:
How much the ajax polling method can impact my bandwith usage?
In which way can I optimize the ajax polling to make a db query only when necessary?
Can the comet server be run in the same machine of the web-server (Apache)?
With the comet way, I still need an interval to do the queries on the database and then send the response, so where is the real-time?
With my actual server, can the comet way work?
Thank you in advance.
You should never use polling if you can get away with it. It clogs up resources on both the server and client. The server must make more database requests with polling, more checks to see if data has changed.
The ajax polling method also generates more unneccessary requests. With polling, you use memory and CPU. Comet (if it's done properly) uses only memory.
The comet server can probably not run under Apache. Apache does not seem to be designed for long running requests. I'd recommend implementing your comet server in ruby (using EventMachine) an example, in Python (using Twisted), or in C.
I don't see why you need to have an interval to do database queries. When you make a change, you can just tell your comet server to notify the neccessary users of the change.
I'm writing my website in PHP.
So, I need to run a server (like twisted) and write my chat application in python?
This app should take care of incoming ajax request and push new data to clients.
If I understand well, this approach doesn't need a database, right?