Is there any article on how synchronized are the times across multiple dynos in heroku, and how reliable they are?
I am running a node.js application on Heroku and need to know if the time that I get using Date.now() or new Date() is synchronized across multiple dynos?
Using cluster module, it seems that all the processes running on the same dyno have the same time. Do they use the local machine time or a clock server?
I tested with two dynos in the same app to print the timestamp as soon as they start and they seemed to have the same time. Is this reliable?
I did not test with dynos on different apps. Are they likely to have the same time or in a reliable difference range?
By the same time, i mean the time differences were less than 1000ms, which can be due to slightly difference process staring times.
I don't think so and I don't think it's reliable.
The post How do I establish clock synchronization in the cloud (AWS, heroku, etc) across many nodes? have some good general information both in the question and answer about NTP, virtual machines and the cloud.
This is a little late, but YES, Heroku dynos have synchronized time.
Screenshot of the Support Ticket:
NTP is pretty accurate too, and 1000ms is definitely within NTP's range.
Related
I have been testing some viewport issues for mobile and probably ran
git push heroku master
about 50 times in the last 3 hours. I am now seeing from the google speed tests that:
Reduce server response time In our test, your server responded in 8.9
seconds. There are many factors that can slow down your server
response time. Please read our recommendations to learn how you can
monitor and measure where your server is spending the most time. Hide
details
This wasn't popping up earlier this morning and was under .5 seconds. Did I damage one of my dynos on the heroku servers?= My site isn't really getting any traffic yet so I haven't been doing any stage testing.
What is the best way to test production?
I was reading through this but was wondering if there is a better way to test production quickly.
https://devcenter.heroku.com/articles/multiple-environments
Thanks,
Jeff
There's nothing wrong with pushing many times in a row, but every time you push, your dynos will cycle. This takes something like 5 to 15 seconds depending on the size of your slug.
Generally this means that the first query sent to your app at the moment your dynos are cycling might hang for about that long. If Google checked your server's speed at that time, then that explains the response time. However, there shouldn't be any lasting effects after you finish pushing repeatedly.
If I recall correctly there is a Heroku labs option to cycle dynos to eliminate this pause, basically taking down some of your dynos and then cycling them while the other ones are still up, but I do not recommend using it as it makes code pushes very unpredictable and can result in two versions of your app being live at the same time.
I have a Play application hosted by Heroku with 5 dynos. Its seems like my dynos were been restarted randomly in different time period. For example, three of them were restarted by itself 22 hours ago, and two of them were restarted 10 hours ago (not sure if this time was triggered by clearing the cache). It seems like that cached data isn't persistent between dynos. My problem is when I sent same request to my Heroku application multiple times, I get different cached response, in the response, some are most up to date data, others were old data. I assume this is because my request was processed by different dyno. After restart all my dyno fixed the problem(I assume this also clear cache in all dynos).
So I want to know what triggered the random dyno restart, and why it does that?
How to solve cached data inconsistency in this case?
Thanks
I think you should use mutualised cache in order to avoid this kind of problem when you scale horizontally.
Couchbase is a good solution to do it. We use this internally at Clever Cloud (http://www.clever-cloud.com/en/), that is the reason why we released a Couchbase as a service.
As for dyno restarts, did you try the documentation? Dyno's are cycled at least once per day
My understanding is that Heroku charges Cron tasks based on the actual amount of time the task runs, using a dyno (based on: https://devcenter.heroku.com/articles/scheduler#dynohour-costs).
So, if I need a quick task to run every X minutes, I could use the cron addon to process it, instead of a worker dyno and I would be charged a fraction of the cost.
So, if everything above is true, what is the use of the Iron.io workers? They charge (about) the same as dynos from the cron jobs and they can't connect to the DB.
I have a feeling that I am missing something.
I'm under the impression that IronWorker can use the databases for Heroku. I may be mistaken about this, however.
I can't claim a great deal of experience with cron tasks on Heroku, so forgive me if I get its limitations wrong. However, I'm under the impression that scaling from one dyno to many dynos is a little bit of a process. Where IronWorker shines is really in enabling the number of worker servers to fluctuate based on demand--you have the capacity to scale at a moment's notice, but are only paying for the scale you're actually using.
I want to host a static website on Heroku, but not sure how many dynos to start off with.
It says on this page: https://devcenter.heroku.com/articles/dyno-requests that the number of requests a dyno can serve, depends on the language and framework used. But I have also read somewhere that 1 dyno only handles one request at a time.
A little confused here, should 1 web dyno be enough to host a static website with very small traffic (<1000 views/month, <10/hour)? And how would you go about estimating additional use of dynos as traffic starts to increase?
Hope I worded my question correctly. Would really appreciate your input, thanks in advance!
A little miffed since I had a perfectly valid answer deleted but here's another attempt.
Heroku dynos are single threaded, so they are capable of dealing with a single request at a time. If you had a dynamic page (php, ruby etc) then you would look at how long a page takes to respond at the server, say it took 250ms to respond then a single dyno could deal with 4 requests a second. Adding more dynos increases concurrency NOT performance. So if you had 2 dynos, in this scenario you be able to deal with 8 requests per second.
Since you're only talking static pages, their response time should be much faster than this. Your best way to identify if you need more is to look at your heroku log output and see if you have sustained levels of the 'queue' value; this means that the dynos are unable to keep up and requests are being queued for processing.
Since most HTTP 1.1 clients will create two TCP connections to the webserver when requesting resources, I have a hunch you'll see better performance on single clients if you start two dynos, so the client's pipelined resources requests can be handled pipelined as well.
You'll have to decide if it is worth the extra money for the (potentially slight) improved performance of a single client.
If you ever anticipate having multiple clients requesting information at once, then you'll probably want more than two dynos, just to make sure at least one is readily available for additional clients.
In this situation, if you stay with one dyno. The first one is free, the second one puts you over the monthly minimum and starts to trigger costs.
But, you should also realize with one dyno on Heroku, the app will go to sleep if it hasn't been accessed recently (I think this is around 30 minutes). In that case, it can take 5-10 seconds to wake up again and can give your users a very slow initial experience.
There are web services that will ping your site, testing for it's response and keeping it awake. http://www.wekkars.com/ for example.
Can anyone have an estimate of how much data can be inserted in a 5MB database?
Also, would 1 Dyno handle a slashdot,hackernews, etc frontpage?
Thanks.
Quiet a surprising amount... well enough to get you started thats for sure.
I use 1 dyno all the time for low traffic (like my personal website and a few xml servers, but obviously the great thing is if you start getting loads of visitors to your site and are having performance issues all it takes is one little click to add extra dynos.
You should also consider the worker hours, not sure about what you are doing, but a lot of apps could need background process.
This service could be interesting if you are using Ruby, it scales dynos on Heroku:
http://hirefireapp.com