For my webapp I'm going to need to have many timeouts running at once at any given point, possibly around 10,000-100,000. What I'm wondering is how well this function scales.
I don't need it to be that accurate, mostly accurate within 10-100 ms. Would it be better to have a single function run on an interval (say, to run every 50 ms), that checks the current datetime compared to the saved datetime and invokes the function if so?
Does anyone have any insight in to the underlying implement of setTimeout and can shed some light as to how well it can be used en-masse?
More questions I had: Does anyone know of a limit to how many timeouts can be running at once? Also, with both approaches I'm concerned about there not being enough time to process each timeout per interval and it getting "behind" in terms of triggering the timeout function in time.
Actually you cannot determine the exact interval between timeouts, because all it does is it pushes your callback to the callback queue after the threshold and when the event loop will get that callback, push to the call stack and execute it - is non-deterministic. The same is with intervals. You may appear in a situation, when, for example, 5 callbacks will be executed one after another without a delay. This is javascript ))
This is too long for a comment.
possibly around 10,000-100,000
Let's consider what this means. Say that each queued callback takes ~10ms to run, and you queue up 50,000 of them to run in 50ms. Only one of them can run at a time. So by the time the event loop even checks to see if it's time to run the 1000th callback, 10 whole seconds have passed. By the time you get to the 50,000th callback it will have been ten whole minutes! Now obviously if your queued callbacks take fractions of a millisecond that two order-of-magnitude dropoff makes the math a little less dismal, but if they have to do any I/O this probably isn't going to work and it probably won't work no matter what, at least not for a webapp that also has to serve clients.
Related
I need to perform many "setTimeouts" 60 seconds. Basically, I'm creating a database record, and 60 seconds from now, I need to check whether the database record was changed.
I don't want to implement a "job queue" since it's such a simple thing, and I definitely need to check it around the 60 second mark.
Is it reliable, or will it cause issues?
When you use setTimeout or setInterval the only guarantee that you get is that the code will not be executed before the programmed time.
It can however start somewhat later because other code that is being executed when the clock ticks (in other words other code will not be interrupted in the middle of the handling of an event to process a timeout or interval event).
If you don't have long blocking processing in your code it means that timed events will be reasonably accurate. If you are instead using long blocking calls then probably node is not the correct tool (it's designed around the idea of avoiding blocking "synch" calls).
you should try WorkerTimer.js it is more good for handling background processes and more accurate than the traditional setInterval or Timeout.
it is available as a node.js npm package.
https://www.npmjs.com/package/worker-timer
I'm designing an app to run on very low spec machine..and i needed it to be efficient as possible..
I needed to issue around 10 intervals at every second that simply makes an ajax call.. and then does a few add/remove classes and (think of it as SERVER Status monitor)
I know in FLASH (oh good old flash days) having a lot of intervals can cause processor spikes .. so i'm very conservative with issuing setIntervals in AS 2.0 before.
I was wondering if this is the same case with JS? or is it alright for JS to have a bunch of intervals (that does lightweight tasks) running? I noticed a lot of sites do this , even facebook has tons of intervals running, loading scripts, etc..
And oh, for one interval, I wanted to run it at 50ms (it loads as status.php link) ... this ok?
I could probably optimize my interval calls, no problem but i'm just wondering how "heavy" or "lightweight" background intervals are in JS..
Thanks all
10 intervals at every second meaning a call every 100ms should not be an issue in my opinion, but if you ask me I would fire a call every 250ms.There is not much difference between the two that the user will notice.
Also make sure that there is a mechanism to handle long running response from server in case there is a delay and stop the interval firing if there is drag.
As a matter of personal feeling, I tend to prefer setTimeout over setInterval -- to the point I don't use setInterval at all.
The issue that you might run into is if one process takes longer than it should -- let me give you an imaginary situation:
window.setInterval(takes100msToRun, 50);
window.setInterval(takes50msToRun, 50);
window.setInterval(takes20msToRun, 50);
The problem is that the first interval will take longer than it should, so the second two interval requests are now behind and the browser will try to catch up by running them as quickly as then can. The second interval takes 50ms, -- so its still running behind when the third interval hits.
This creates an ugly situation that can lead to a lot of drag.
On the other hand, if you setTimeout, then you aren't say "Run this every 50 ms", but rather "Run another one of these 50ms from we finish." (Assuming, of course, that the functions set up another setTimeout to re-execute.)
It is absolute rubbish for things that need good clock timing, but its superior for everything else.
setTimeout and setInterval will affect performance, but little.
Since there are lots of functions triggered/listening/running in the browser.
Even a tiny operation like move your mouse to vote up for this answer, there are thousands of events got triggered, and tens of functions start running.
Don't use setInterval. As a matter of fact, the library underscore doesn't use it either.
See how they implement the _.throttle without setInterval.
http://learningcn.com/underscore/docs/underscore.html#section-66
I have a very short question. What happen if I use setInterval method to call an ajax function like checking message in inbox every 3 second (or if I can do in every 1 second would be nice!)
Well this is what I use:
setInterval(function() {
chk_inbx (var1, var2);
}, 8000);
I call this function every 8 second right now. I see no problem. (or maybe I don´t have so many users right now)
But what happen if I change it from 8000 to 3000 or even 1000 ?
UPDATE
I have test the polling (LONG POLLING (in php) starts hanging after 5 requests to database
)
I wonder what ´s diferences between setTimeout and setTimeout with polling.
What I understand is in php file they put the sleep(); function and use timestamp
to determin if the data is old or not.
But mine, I use N nd Y to determine if msg is read or not. if N then show the rowCount.
So what is the different ? can anyone help me ?
It could cause issues if the request takes longer to complete than your polling time. The duration of the request will depend on both your user's network speed and geographical location. Browsers will limit the number of concurrent requests, but they will keep queueing the new requests and the queue will grow to an unreasonable size, possibly slowing down or even crashing some browsers.
There are better ways to achieve what you want to do. The most common and cross-browser (websockets could also solve this problem in modern browsers) way is to use long polling.
With long polling you send a request as soon as you receive a response, so you are always polling continuously. The web server handles the process idling and repeated checks for new messages without generating a response until either a timeout (you can pick something like 30 seconds) or there is new data to inform the browser about.
You should avoid using setInterval() in this way.
The problem with setInterval() is that it keeps firing the event every 3 seconds (or whatever), even if the previous event hasn't finished yet.
If your response time is slower than the interval time, this can cause major problems with requests piling up on top of each other and maybe not even responding in the same order that they were requested.
This will become more and more noticeable the smaller the interval you set, but it can be a problem even for big intervals if you have any kind of blocking event in your JS code - an alert() box would be the classic example - as you can end up with large numbers of interval events piling up waiting for the alert to be cleared, and then all firing at once.
A better solution is to use a self-firing setTimeout().
This would use setTimeout() to start the event sequence, which then calls another identical setTimeout() call internally when its event is completed. This ensures you will never have multiple events piling up like you can with setInterval().
I have a setinterval function in my javascript that I want to be as fast as possible, i.e. check the status of an event every 1ms. Is it possible that this would be asking too much from a user's browser? It seems to work just fine, but I am wondering if its a bad practice.
It is not only possible, it's quite common. It's a race-condition by its very nature. If you depend on the code inside the callback to be executed before the next interval, use a recursive setTimeout instead.
Also, unless your interval is called lockUpBrowser, that duration between callbacks is likely much too short for realistic performance handling.
(function myRecursiveTask() {
// Do your task here
myTask();
if (!someConditionToAllowABailOut) {
setTimeout(myRecursiveTask, 100); // 100ms loop
}
}());
setInterval is not guaranteed to execute at precisely the interval specified.
It will execute as soon as possible, but since javasript is single-threaded and some other code may execute at this time your callback may be delayed.
If you're using setInterval with 1ms than you're probably trying to solve your problem in a wrong way.
Yes, if the function reference passed to setInterval takes longer to execute than the interval, calls to the function will queue and bog down the browser. If you're trying to perform an animation and want to change each step as fast as possible, there is a requestAnimationFrame function that should be used for modern browsers. Personally, I've never needed to perform a function faster than every 15ms.
I would certainly question the need for such an approach. What are you needing to check for every 1ms that you can't check for every 10ms, 100ms, or every second?
Are you 100% certain that the check functionality that you will run every will always execute in < 1ms such that you don't have multiple check processes stacking up to run.
How much memory and CPU does the process take, and are you going to potentially slow down the user's browser to the point where simply actions like scrolling become painful for the user?
is an while loop too slow for you?
while (condition)
{
//code block to be executed
}
i know i'm not ansering your question but, i think there is no better ways to do something like that...
Ben Cherry has a good article about this where he tests different browsers to find how fast setInterval can be before it becomes unreliable. The speed at which a setInterval or setTimout fires is dependent on the browser.
In particular, if you’re looking for consistent timer intervals across browsers, you have to use something >15ms.
So if you can set the time greater than 15ms you won't run into problems.
I guess that once it's executed it's on the queue, but in the queue is there any assurance it will invoke exactly after X milliseconds? Or will other heavy tasks higher on the queue delay it?
The semantics of setTimeout are roughly the same as in a web browser: the timeout arg is a minimum number of ms to wait before executing, not a guarantee. Furthermore, passing 0, a non-number, or a negative number, will cause it to wait a minimum number of ms. In Node, this is 1ms, but in browsers it can be as much as 50ms.
The reason for this is that there is no preemption of JavaScript by JavaScript. Consider this example:
setTimeout(function () {
console.log('boo')
}, 100)
var end = Date.now() + 5000
while (Date.now() < end) ;
console.log('imma let you finish but blocking the event loop is the best bug of all TIME')
The flow here is:
schedule the timeout for 100ms.
busywait for 5000ms.
return to the event loop. check for pending timers and execute.
If this was not the case, then you could have one bit of JavaScript "interrupt" another. We'd have to set up mutexes and semaphors and such, to prevent code like this from being extremely hard to reason about:
var a = 100;
setTimeout(function () {
a = 0;
}, 0);
var b = a; // 100 or 0?
The single-threadedness of Node's JavaScript execution makes it much simpler to work with than most other styles of concurrency. Of course, the trade-off is that it's possible for a badly-behaved part of the program to block the whole thing with an infinite loop.
Is this a better demon to battle than the complexity of preemption? That depends.
The idea of non-blocking is that the loop iterations are quick. So to iterate for each tick should take short enough a time that the setTimeout will be accurate to within reasonable precision (off by maybe <100 ms or so).
In theory though you're right. If I write an application and block the tick, then setTimeouts will be delayed. So to answer you're question, who can assure setTimeouts execute on time? You, by writing non-blocking code, can control the degree of accuracy up to almost any reasonable degree of accuracy.
As long as javascript is "single-threaded" in terms of code execution (excluding web-workers and the like), that will always happen. The single-threaded nature is a huge simplification in most cases, but requires the non-blocking idiom to be successful.
Try this code out either in your browser or in node, and you'll see that there is no guarantee of accuracy, on the contrary, the setTimeout will be very late:
var start = Date.now();
// expecting something close to 500
setTimeout(function(){ console.log(Date.now() - start); }, 500);
// fiddle with the number of iterations depending on how quick your machine is
for(var i=0; i<5000000; ++i){}
Unless the interpreter optimises the loop away (which it doesn't on chrome), you'll get something in the thousands. Remove the loop and you'll see it's 500 on the nose...
setTimeout is a kind of Thread, it holds a operation for a given time and execute.
setTimeout(function,time_in_mills);
in here the first argument should be a function type; as an example if you want to print your name after 3 seconds, your code should be something like below.
setTimeout(function(){console.log('your name')},3000);
Key point to remember is, what ever you want to do by using the setTimeout method, do it inside a function. If you want to call some other method by parsing some parameters, your code should look like below:
setTimeout(function(){yourOtherMethod(parameter);},3000);
The only way to ensure code is executed is to place your setTimeout logic in a different process.
Use the child process module to spawn a new node.js program that does your logic and pass data to that process through some kind of a stream (maybe tcp).
This way even if some long blocking code is running in your main process your child process has already started itself and placed a setTimeout in a new process and a new thread and will thus run when you expect it to.
Further complication are at a hardware level where you have more threads running then processes and thus context switching will cause (very minor) delays from your expected timing. This should be neglible and if it matters you need to seriously consider what your trying to do, why you need such accuracy and what kind of real time alternative hardware is available to do the job instead.
In general using child processes and running multiple node applications as separate processes together with a load balancer or shared data storage (like redis) is important for scaling your code.
setTimeout(callback,t) is used to run callback after at least t millisecond. The actual delay depends on many external factors like OS timer granularity and system load.
So, there is a possibility that it will be called slightly after the set time, but will never be called before.
A timer can't span more than 24.8 days.