I'm planning to set a short polling that loads image URL instead of using AJAX just to check if the image is already uploaded from the other hardware device(camera, fingerprint, etc...).
Does visiting not existing image URL every seconds affects or slow web server? Is it the same of AJAX short polling?
it has nothing to do with the slowing or fastening web server, its all about need of your application.
Usually short polling AJAX is used in order to avoid "image not found" exception. If you have some other way of handling it or if it's not a need of your application, go right ahead and load as many non existing images as you like, it won't affect any web server speed.
However, I do not recommend doing AJAX call every second if you decide to go that way because the completion of an AJAX request depends upon the internet speed of the end user and in case of slow net, browser might queue many AJAX requests which might create issues for your application.
Also, in that case, your script will use the last response returned from server which might not necessarily be the response of the last AJAX made and you might end up showing wrong results. The same thing for which we use debounce in search process.
I hope it helps
Related
I am building a mobile site that works like a slideshow. There are a number of image slides and you can swipe left and right to traverse the slides.
I would like to monitor the download speed performance of the slides using javascript and report the times to the server.
I presume that ajax is the way to report the times, although I am new to ajax. My fist concern is that the report sent to the server should be as lean as possible. Also it is only really necassary for the communication with the server to be one way.
Can the flow go just in the direction of from the browser to the server without any responses being sent back to the browser? Or do the http post and put methods have to send a response back to the browser? Obviously notthing is actually needed to be sent back to the browser and to the mobile site it doesn't even really matter if the request is a success or failure.
If a response does have to be sent to the browser what should my MVC 3 controller return? Can just a head with success or failure be returned?
Finally which of the http POST and PUT methods is best for this and what will be the best data format to use?
Do a POST to an action on the server.
I would suggest you use JSON for the data as it is quite lean and makes it easy to decode. However, if you wanted to make it really lean you you could just use a parameter on the url, like ..../reportPerf?d=123 and then your action should take a parameter "d".
The server does need to respond, but you can just
return new HttpStatusCodeResult(200)
That will only take a few bytes.
Sorry for the brevity, on a mobile device.
I use jQuery for AJAX. My question is simple - why cache AJAX? At work and in every tutorial I read, they always say to set caching to false. What happens if you don't, will the server "store" such requests and get "clogged up"? I can find no good answer anywhere - just links telling you how to set caching to false!
It's not that the server stores requests (though they may do some caching, especially higher volume sites, like SO does for anonymous users).
The issue is that the browser will store the response it gets if instructed to (or in IE's case, even when it's not instructed to). Basically you set cache: false if you don't want to user's browser to show stale data it fetched X minutes ago for example.
If it helps, look at what cache: false does, it appends _=190237921749817243 as a query string pair (random number, the actual one is the current time, so it's always....current). This forces the browser to make the request to the server for data again, since it doesn't know what that query string means, it may be a different page...and since it can't know or be sure, it has to fetch again.
The server won't cache the requests, the browser will. Remember that browsers are built to display pages quickly, so they have a cache that maps URLs to the results last returned by those URLs. Ajax requests are URLs returning results, so they could also be cached.
But usually, Ajax requests are meant to do something, you don't want to skip them ever, even if they look like the same URL as a previous request.
If the browser cached Ajax requests, you'd have stale responses, and server actions being skipped.
If you don't turn it off you'll have issues trying to figure why you AJAX works but your functions aren't responding as you'd like them to. Forced re-validation at the header level is probably the best way to gain a cache-less assimilation of the data being AJAX'd in.
Here's a hypothetical scenario. Say you want the user to be able to click any word on your page and see a tooltip with the definition for that word. The definition is not going to change, so it's fine to cache it.
The main problem with caching requests in any kind of dynamic environment is that you'll get stale data back some of the time. And it can be unpredictable when you'll get a 'fresh' pull vs. a cached pull.
If you're pulling static content via AJAX, you could maybe leave caching on, but how sure are you that you'll never want to change that fetched content?
The problem is, as always, Internet Explorer. IE will usually cache the whole request. So, if you are repeatedly firing the same AJAX request then IE will only do it once and always show the first result (even though subsequent requests could return different results).
The browser caches the information, not the server. The point in using Ajax is usually because you're going to be getting information that changes. If there's a part of a website or something you know isn't going to change, you don't bother with it more than once (in which case, caching is ok), that's the beauty of Ajax. Since you should only be dealing with information that may be changing, you want to get the new information. Therefore, you don't want the browser to cache.
For example, Gmail uses Ajax. If caching was simply left on you wouldn't see your new e-mail for quite awhile, which would be bad.
Something I am playing with at the moment is a Rest / HTML page that dynamically updates via JSON calls.
Now in the case that I want this to run on as low a bandwidth as possible.
So if the server is shut down, then booted up again I want the updates to continue again in most cases this works some cases parts of the javascript won't work and it times out.
So what is a low overhead solution to detect that the Server has started up again?
(Looking for good ideas or other methods to do this)
thoughts:
So far I have thought of having a status request but this uses bandwidth again to continually run?
Or how to only run this status request once the server had gone down and stop when its up?
You could use the setInterval function to continuously poll the server for updates. Once a request fails you could enter a so called safe-mode by sending only HEAD requests (and as suggested by #sje397 also increase the timeout interval) to reduce bandwidth and once it succeeds you enter again normal mode and continue with GET/POST.
There are also more exotic things like COMET and Web Sockets in HTML 5 that allow the server to push updates to the client.
This is a followup question to the one here
Here's briefly what I am trying to do. The File server creates a text file to indicate an end of the process. On a webpage on the Web Server, I loop every x seconds and make an ajax request to find out if the test file exists (ajax request to http://fileserver/files/UserFile.txt)
I've tried the following approaches so far:
Trigger a web method from the client side that creates a HttpContext object to verify if the text file exists. But this is too strenous on the server and I started getting all kinds of exceptions in the Event Viewer.
YQL works great but unfortunately it's too slow. The user waits atleast twice the amount of time.
I am looking for a solution that doesn't involve the server side. Somehow, I'd like to use JQuery to verify the existence of a text file on the fileserver.
Any thoughts?
You should be able to use JSONP and JQuery.ajax() to do cross-domain request work. Play with the jsonp and jsonpCallback attributes. Alternatively, you can use JQuery.getJSON().
Serving a single file from the filesystem is the most simple operation a web server can do. If that is already too much, then all other solutions will be worse. Find out why the server takes so long to serve a simple file and fix that.
Note: I'm assuming that the file is small since you say "test file". If it's a big file, the server will actually send it to the client which will need a lot of resources.
What you can try is to add an ASP page to the web site which runs code on the server that checks whether the file is there and just returns a tiny piece of HTML which you can add to the page with jQuery.load().
I may be miles off base here but... could you not create ONE asynchronous (!) Ajax client request with a HUMONGOUS timeout. Fire it, and wait. You would be invoking some server script that checks every so often, in a loop on the server (using sleep in between), whether the file exists. And not replying to the Ajax request until the file finally shows. The server script then replies and exits.
EDIT: Depending on the server-side scripting framework used, you may even get some OS support. You may be able to sleep on a status change in the directory...
I have a situation where a display on a webpage needs to be updated at random. I am wanting to do this in AJAX but am not sure how to do this other than to do a
while(true) { ajaxFunction(); sleep(1) }
Type thing.
The problem with this is that the webpage needs to be updated very quickly on a change to the server, but the changes could happen very sporadically sometimes never.
EDIT: This is an Iphone application using a UIWebView, is it possible to use the iPhone's push notification to interface with the javascript?
Thanks!
I think what you're describing is Comet and there are a couple of plugins for jQuery:
http://code.google.com/p/jquerycomet/
http://plugins.jquery.com/project/Comet
The only way I can think of is to constantly query it. Just keep your responses small so you're not moving a bunch of data around for no reason. You could even suspend the response from the server until data is available.
setInterval(function(){
$.get("updates.php", function(result) {
alert(result);
});
}, 5000);
Might even build some logic into updates.php to cancel the setInterval() after 10 minutes of inactivity on the users part. That will kill off constant requests from users who are no longer logged in.
You should consider implementing some kind of a comet (server push) technology, when you want to optimize the servers load. If you only have a few users, than a polling solution is suitable.
About comet: comet technologies are nothing else, but making a simple http request to the server, where the server does not respond to the request immediately, but waits until there is something to respond with. Until than the thread on the server is suspended.
There are some technical aspects you should consider when implementing a server push technology (like where should I suspend the thread). It is best to use an open source one. It is easy to find them on the web if you search for comet.
If the changes are sporadic, consider not using any AJAX. Wait for the user to refresh or revisit the page.