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
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
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
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
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
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
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
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 e...@pixelwareinc.com 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
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
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
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
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
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
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 e...@pixelwareinc.comwrote:
On
14 matches
Mail list logo
