Re: free vs. paid heroku app performance
> > What is Heroku's timeout when spinning up dynos/workers? I thought > that I'd seen this mentioned somewhere, but I can't find it now. I ask > because an app I'm thinking of would need to hit external services and > the database when starting up, which could take a while. > > 30 seconds. > Is there a limit to how long a daily cron job can run? I'm planning on > some number crunching that could take up to an hour or so. > > You should aim for a few seconds, minute at most. If you need that long a job, you should be using a worker to run it. Oren -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
> What other questions do you guys have on the area that I should include? Two: What is Heroku's timeout when spinning up dynos/workers? I thought that I'd seen this mentioned somewhere, but I can't find it now. I ask because an app I'm thinking of would need to hit external services and the database when starting up, which could take a while. Is there a limit to how long a daily cron job can run? I'm planning on some number crunching that could take up to an hour or so. Thank you! -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
What's heroku's official stance on users using various methods to prevent dynos from being idle? I personally have a production app that only uses 1 dyno and need to wait a while for the first request to get processed while the dyno spins back up. While I understand Heroku's reasons for spinning down dyno's that are not being used, I also have heard that slow responses from a web site will impact search engine ranking (faster responses are better). I think this may have been mentioned already but is Heroku planning on offering an "add-on" in order to prevent spinning down dynos for a nominal fee? This seems like a no brainer since users are going to use other methods to keep their dynos alive anyway. Thanks, Shane On Tue, Aug 31, 2010 at 2:15 PM, Oren Teich wrote: > > >> I don't really mind the sluggish spin up time. What I do mind is >> having slug compilation occasionally take 4+ hours instead of the >> normal 3 minutes. That means I can't show my boss the current state of >> > > Slug compile should never take that long. It sounds like a bug - we have > noticed a few stale lock files on compiles. We're digging in to see what's > going on over the next few weeks on this particular area. > > For the sake of clarity (and a future docs page I'll put up): > > h1. When do you idle my app? > > Only dynos are idled, not workers. If you have only 1 free dyno, your app > will be spun down after a period of inactivity. This period is variable > depending on demand on the platform, but is never less than 20 minutes or > more than 1 hour. > > No other resources are different. Git push, slug compilation, etc are all > identical. > > Increasing your dyno to >1 will prevent your app from idling out. > > Note: other resources (workers, add-ons) do not effect dyno idling at this > time. If you have 1 dyno + 10 workers, your dyno will still idle out after > a period of inactivity. We never idle out workers. > > What other questions do you guys have on the area that I should include? > > Oren > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > -- -Shane -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
> > I don't really mind the sluggish spin up time. What I do mind is > having slug compilation occasionally take 4+ hours instead of the > normal 3 minutes. That means I can't show my boss the current state of > Slug compile should never take that long. It sounds like a bug - we have noticed a few stale lock files on compiles. We're digging in to see what's going on over the next few weeks on this particular area. For the sake of clarity (and a future docs page I'll put up): h1. When do you idle my app? Only dynos are idled, not workers. If you have only 1 free dyno, your app will be spun down after a period of inactivity. This period is variable depending on demand on the platform, but is never less than 20 minutes or more than 1 hour. No other resources are different. Git push, slug compilation, etc are all identical. Increasing your dyno to >1 will prevent your app from idling out. Note: other resources (workers, add-ons) do not effect dyno idling at this time. If you have 1 dyno + 10 workers, your dyno will still idle out after a period of inactivity. We never idle out workers. What other questions do you guys have on the area that I should include? Oren -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
My slug is pretty big, about 50 MB, mostly due to gem dependencies. I figure I could shave about 5 MB if I spent an entire day shaving off unused bits. But I doubt this would make any perceivable difference. I don't really mind the sluggish spin up time. What I do mind is having slug compilation occasionally take 4+ hours instead of the normal 3 minutes. That means I can't show my boss the current state of the app, which is pretty embarrassing and shakes his confidence in hosting the production app with Heroku. I pointed out the slow spinup because there seemed to be a strong connection between that and the slow slug compilation. I recently upped my staging to 2 dynos (1 paid), to see if the problem goes away. -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
Hello Deepak, A single / free dyno spins down when it is not in use. Much like passenger / mod_rails on your local box. It cost ram/cpu/money to run a dyno on an ec2 instance. If you are not using it (and you are not paying for it), then there is no reason why Heroku should dish out the money to pay for something you are not using. If you want to pay for it by getting another dyno, then I guess you can be the judge on whether to have the app running or not. It seems curious to me that people want Heroku to pay for their staging environment to be up all the time. For me, staging is a pre-release testing environment. Guess others have a different view. Keenan On Aug 29, 2010, at 6:48 AM, deepak wrote: > what is the reasoning behind this. Did you test this or is it given in > the docs? > Deepak > > On Aug 26, 11:32 pm, Eric Anderson wrote: >> On 08/26/2010 11:30 AM, marcel wrote: >> .. >> OTOH if you pay for at least 2 dynos then they NEVER spin down meaning >> your app is always nice and responsive even if nobody has it it for a while. >> . >> Eric > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
what is the reasoning behind this. Did you test this or is it given in the docs? Deepak On Aug 26, 11:32 pm, Eric Anderson wrote: > On 08/26/2010 11:30 AM, marcel wrote: > .. > OTOH if you pay for at least 2 dynos then they NEVER spin down meaning > your app is always nice and responsive even if nobody has it it for a while. > . > Eric -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
If you think that its dying when the slug is being compiled, or you just want to improve your slug loading time, you might want to tell it which parts of your repo are not needed during runtime. some common things to add to your .slugignore file *.psd *.pdf test spec doc you might also check if any of your vendored gems/plugins are not needed during runtime (testing related stuff most likely) The point is not that having these components is slowing down runtime (though they might, slightly), but rather that including them in the slug will slow down the spin-up time for no good reason. you can find out more at: http://docs.heroku.com/slug-compiler On Sat, Aug 28, 2010 at 3:42 PM, Dennis wrote: > I think I have to agree with Stefan - *particularly* when it comes to > staging. Why not take the cheapest entry level package for staging for > a month - any outfit that advertises "rock solid ruby platform" > should give good to excellent service for even the cheapest "paid-for" > package. > > I totally agree with your previous post and its sentiments - the need > to be aware of, and working on, the problem when the client calls at > 2:00 a.m. is critical - it has to be one of the worst feelings ever to > have your client inform you the site is down and not be aware of it. > > However the discussion started on the topic the free account's > (staging) performance ... doesn't surprise me it's poor to fair ... > > > On Aug 28, 1:43 pm, David wrote: > > It's in the best interest of any web site operator to know when their > > web site is down external from your hosting company regardless of > > platform, language, or baseline hosting provider's functionality. > > When I get a phone call at 2am that the web site is down, I should > > already be on it. > > > > It just happens that it has the same benefits for spun down processes. > > > > I understand where you're coming from in regards to all the free sites > > but most likely the operators of those sites are leveraging Varnish > > and site monitoring is simply going to hit the same cached route. We > > can only work with what we have, if they want it done differently - > > give us the option. Besides, I pay plenty a month for it to work in > > my situation. > > > > /david. > > > > On Aug 27, 10:52 am, Stefan Wintermeyer > > wrote: > > > > > > > > > Am 27.08.2010 um 15:27 schrieb David: > > > > > > That's what we do, setting up site monitoring is part of my normal > > > > routine so I have something checking the site every 5 mins including > > > > staging. > > > > > I think that might not be in the best interest of the Heroku guys. If > they wanted it that way they'd have built it in. > > > > > Stefan > > > > > -- > > > AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied --> http://www.amooma.de > > > Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998 > > > > > Asterisk 1.6:http://das-asterisk-buch.de > > > Ruby on Rails 3:http://ruby-auf-schienen.de > > > Videos and slides of AMOOCON:http://amoocon.de > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- -John -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
I think I have to agree with Stefan - *particularly* when it comes to staging. Why not take the cheapest entry level package for staging for a month - any outfit that advertises "rock solid ruby platform" should give good to excellent service for even the cheapest "paid-for" package. I totally agree with your previous post and its sentiments - the need to be aware of, and working on, the problem when the client calls at 2:00 a.m. is critical - it has to be one of the worst feelings ever to have your client inform you the site is down and not be aware of it. However the discussion started on the topic the free account's (staging) performance ... doesn't surprise me it's poor to fair ... On Aug 28, 1:43 pm, David wrote: > It's in the best interest of any web site operator to know when their > web site is down external from your hosting company regardless of > platform, language, or baseline hosting provider's functionality. > When I get a phone call at 2am that the web site is down, I should > already be on it. > > It just happens that it has the same benefits for spun down processes. > > I understand where you're coming from in regards to all the free sites > but most likely the operators of those sites are leveraging Varnish > and site monitoring is simply going to hit the same cached route. We > can only work with what we have, if they want it done differently - > give us the option. Besides, I pay plenty a month for it to work in > my situation. > > /david. > > On Aug 27, 10:52 am, Stefan Wintermeyer > wrote: > > > > > Am 27.08.2010 um 15:27 schrieb David: > > > > That's what we do, setting up site monitoring is part of my normal > > > routine so I have something checking the site every 5 mins including > > > staging. > > > I think that might not be in the best interest of the Heroku guys. If they > > wanted it that way they'd have built it in. > > > Stefan > > > -- > > AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied --> http://www.amooma.de > > Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998 > > > Asterisk 1.6:http://das-asterisk-buch.de > > Ruby on Rails 3:http://ruby-auf-schienen.de > > Videos and slides of AMOOCON:http://amoocon.de -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
It's in the best interest of any web site operator to know when their web site is down external from your hosting company regardless of platform, language, or baseline hosting provider's functionality. When I get a phone call at 2am that the web site is down, I should already be on it. It just happens that it has the same benefits for spun down processes. I understand where you're coming from in regards to all the free sites but most likely the operators of those sites are leveraging Varnish and site monitoring is simply going to hit the same cached route. We can only work with what we have, if they want it done differently - give us the option. Besides, I pay plenty a month for it to work in my situation. /david. On Aug 27, 10:52 am, Stefan Wintermeyer wrote: > Am 27.08.2010 um 15:27 schrieb David: > > > That's what we do, setting up site monitoring is part of my normal > > routine so I have something checking the site every 5 mins including > > staging. > > I think that might not be in the best interest of the Heroku guys. If they > wanted it that way they'd have built it in. > > Stefan > > -- > AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied --> http://www.amooma.de > Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998 > > Asterisk 1.6:http://das-asterisk-buch.de > Ruby on Rails 3:http://ruby-auf-schienen.de > Videos and slides of AMOOCON:http://amoocon.de -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
Am 27.08.2010 um 15:27 schrieb David: > That's what we do, setting up site monitoring is part of my normal > routine so I have something checking the site every 5 mins including > staging. I think that might not be in the best interest of the Heroku guys. If they wanted it that way they'd have built it in. Stefan -- AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied --> http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998 Asterisk 1.6: http://das-asterisk-buch.de Ruby on Rails 3: http://ruby-auf-schienen.de Videos and slides of AMOOCON: http://amoocon.de -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
Thanks for the helpful tips about keeping the app responsive. Has anyone else encountered ridiculously long slug compilation (several hours), or is it just me? Its happened on at least 4 days in the past month. I checked the heroku status page each time, but only one of the times coincided with an official heroku problem. The production app was unaffected except for the official outage. I wonder if paying for a dyno would help reduce this problem too? -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
That's what we do, setting up site monitoring is part of my normal routine so I have something checking the site every 5 mins including staging. A couple free options: http://aremysitesup.com/ http://www.uptimerobot.com/ And when you're ready for the big time: http://pingdom.com/ (though I'll gladly hi-jack this thread if someone has better suggestions...) /david. On Aug 26, 3:04 pm, Shane Witbeck wrote: > Can't you set something up to request a page on the app every so often to > simulate traffic? I ran into the same issue on Google App Engine and did > this to prevent the resources behind my app to not wind down. > > On Thu, Aug 26, 2010 at 2:32 PM, Eric Anderson wrote: > > > > > On 08/26/2010 11:30 AM, marcel wrote: > > >> Also, it often takes 10-20 seconds to get a page to load after a > >> period of inactivity, compared to lightning speed for the production > >> app. > > > If you are using the "free" heroku plan they do spin down the single dyno > > when not in use. This makes sense as probably a LOT of those apps are just > > something someone was playing with and does not use on a regular basis. Also > > if they are not getting paid you can understand them wanting to minimize > > resources. > > > OTOH if you pay for at least 2 dynos then they NEVER spin down meaning your > > app is always nice and responsive even if nobody has it it for a while. > > > I WISH they offered the ability to purchase 1 persistent dyno. I don't > > really need two (my app is lightly used) but I don't want the startup delay. > > Seems if they offered 1 dyno that was persistent for $5-15/month that would > > lower the barrier to entry for becoming a paying customer and allow them to > > offer a single persistent dyno without dragging their profit down. > > > Eric > > > -- > > You received this message because you are subscribed to the Google Groups > > "Heroku" group. > > To post to this group, send email to her...@googlegroups.com. > > To unsubscribe from this group, send email to > > heroku+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/heroku?hl=en. > > -- > -Shane -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
Can't you set something up to request a page on the app every so often to simulate traffic? I ran into the same issue on Google App Engine and did this to prevent the resources behind my app to not wind down. On Thu, Aug 26, 2010 at 2:32 PM, Eric Anderson wrote: > On 08/26/2010 11:30 AM, marcel wrote: > >> Also, it often takes 10-20 seconds to get a page to load after a >> period of inactivity, compared to lightning speed for the production >> app. >> > > If you are using the "free" heroku plan they do spin down the single dyno > when not in use. This makes sense as probably a LOT of those apps are just > something someone was playing with and does not use on a regular basis. Also > if they are not getting paid you can understand them wanting to minimize > resources. > > OTOH if you pay for at least 2 dynos then they NEVER spin down meaning your > app is always nice and responsive even if nobody has it it for a while. > > I WISH they offered the ability to purchase 1 persistent dyno. I don't > really need two (my app is lightly used) but I don't want the startup delay. > Seems if they offered 1 dyno that was persistent for $5-15/month that would > lower the barrier to entry for becoming a paying customer and allow them to > offer a single persistent dyno without dragging their profit down. > > Eric > > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- -Shane -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
On 08/26/2010 11:30 AM, marcel wrote: Also, it often takes 10-20 seconds to get a page to load after a period of inactivity, compared to lightning speed for the production app. If you are using the "free" heroku plan they do spin down the single dyno when not in use. This makes sense as probably a LOT of those apps are just something someone was playing with and does not use on a regular basis. Also if they are not getting paid you can understand them wanting to minimize resources. OTOH if you pay for at least 2 dynos then they NEVER spin down meaning your app is always nice and responsive even if nobody has it it for a while. I WISH they offered the ability to purchase 1 persistent dyno. I don't really need two (my app is lightly used) but I don't want the startup delay. Seems if they offered 1 dyno that was persistent for $5-15/month that would lower the barrier to entry for becoming a paying customer and allow them to offer a single persistent dyno without dragging their profit down. Eric -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: free vs. paid heroku app performance
On Thu, Aug 26, 2010 at 11:30 AM, marcel wrote: > Also, it often takes 10-20 seconds to get a page to load after a > period of inactivity, compared to lightning speed for the production > app. I can't find it in the docs, but I'm pretty sure that your dyno will "spin down", or "go to sleep", or whatever dynos do when they are not being used after a certain period of time without any requests. The reason you see that on staging and not production is likely because there are no requests coming into staging for long enough that your staging dyno rests its inactive head. The 10 second period is the dyno "waking up" and if you keep QAing on staging over the next few minutes you shouldn't see the same delay. Dan -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
