<i>I’ve come to the conclusion that Heroku must be using adaptive processes to sandbag us. For example, to save on their resources, they must be creating static caches of the pages which are being requested from these cron pings. They could avoid loading my whole app back into memory with a trick like this. Please correct me if I’m wrong, but I see no other way for these pings to be successful and my app to still have bad initial load times when it is not visited for a while.</i><p>You are incorrect. We idle single-dyno apps that have not recently received requests. We do no caching, unless you are running an old bamboo app and are therefore going through varnish. See <a href="https://devcenter.heroku.com/articles/dynos#dyno-idling" rel="nofollow">https://devcenter.heroku.com/articles/dynos#dyno-idling</a>
Heroku don't hide this, it's in their documentation <a href="https://devcenter.heroku.com/articles/dynos#dyno-idling" rel="nofollow">https://devcenter.heroku.com/articles/dynos#dyno-idling</a>.<p>Imagine how many free apps are created that are never used again. Should Heroku really devote resources to these apps? I think it's perfectly reasonable to idle them after a period of inactivity. If they didn't, they would need more resources and ultimately the customers would be paying for that. They aren't a charity, they are a business.<p>It's pretty simple, if you don't want your app to idle out after 1 hour of inactivity, buy a dyno for $35 p/month.
I feel your pain, as a fellow bootstrapper, but a single paid dyno, which will keep your app unidled, is gonna cost you $35 a month. I did run into a bug recently where one of our dynos was being idled even after we paid up, but it has since been resolved.<p>I'd say just pay them another $35 a month. Considering the miracles Heroku regularly performs as an ops team, it's worth it.
> "I’m employing things like resque, redis-to-go, memcachier, and a dedicated crane database..."<p>Yet you have a 507KB (!) image on your site's home page. Optimizing that would go a long way toward improving the end-user experience.
for $108 / month you could have a very nice setup on any number of VPSs, RS, ec2, etc... you could have at least a 2GB setup either split between 2 hosts or all on one depending on how you plan on scaling... but really IMO if you plan on running anything for any matter of time beyond a (hey checkout my neat idea app) get off heroku and figure out how to setup your own systems, nginx/haproxy, etc... sure it's nice to focus only on the app side with heroku so learn stuff there but eventually unless you're getting funded - you'll need to know how to manage your own servers... just my thoughts.. and i do put lots of little projects on heroku but they're mostly none critical services... or ideas
I'd be curious what dsower's heroku logs look like. Would you mind posting the portion of this where it happened?<p>The logs should show 'idling' when idling and also show the 'pings' from pingdom and/or new relic. Looking through that it'd give us all something concrete to discuss - because quite possibly this is just a bug with Heroku's dyno idling that could have simply been submitted as a support ticket.
Reposting my comment from the website here (unreadable there):<p>I contacted support about this a while ago (was in a similar situation). Their response was "Use more than one web dyno". I didn't need more than one, but that was the only way they offered to allow my app to not "go to sleep".
This is kind of an annoying problem if you have a lot of small sites for whatever reason. I think their policy is reasonable and they are upfront about it, so I certainly don't begrudge them, but it is still annoying.<p>What is the best way to host a bunch of low-traffic sites for less than $35 (I believe that is what it costs for the second dyno, required to keep your app from being spun down) each per month? The usual answer is "PHP", but I sometimes wonder if there'd be a market (and way to make money) for Heroku-like ease of deployment/management, billed based on resources (much like a VPS) rather than per application.
I love the way the comments have steered into technology nonsense, while the issue has nothing to do with the way in which Heroku screws him over, just the mere fact that they ARE screwing him. Commenters who have suggested 'just pay $35/month for not having 10 second lag' are idiots.<p>Heroku is a great and easy service, but I find the add-on 'no lag for $35/month' which is what the dyno basically is to the poster, unacceptable. But if most commenters are willing to pay into the hype, go ahead.<p>Just go with Linode or appfog or something.
Best thing to do is provide the logs and see if it is idling.<p>I agree though that if you are hitting the damn thing every second it shouldn't go idle.
I have some feedback on your site (<a href="http://www.mycelial.com" rel="nofollow">http://www.mycelial.com</a>) that is unrelated to your post. I had no idea what your site was until I went to the About page. I think the contents of the About page should be put on the homepage.
We use Pingdom to keep a couple low-traffic sites alive without issue. I think we could provide you with more help if you posted a condensed sample of your Heroku logs.
Unfortunate responsive design.<p>Forcing me to read in landscape.<p><a href="http://www.imgur.com/SVebzkP.png" rel="nofollow">http://www.imgur.com/SVebzkP.png</a>
At least Google isn't doing it, you can enable "warmup requests".
<a href="https://developers.google.com/appengine/docs/python/config/appconfig#Warmup_Requests" rel="nofollow">https://developers.google.com/appengine/docs/python/config/a...</a><p>Btw. Heroku and App Engine apps start fast, compared to what ep.io (free) app start took, it was more like 20-30 seconds than 2-5 seconds.
To clarify: I understand that getting another dyno would solve this problem. I love heroku but I think that they need to rethink the idle process. Some users only need 1 dyno and a bunch of addons. If we are paying decent money then the idle threshold should be increased, in my opinion.
A cron job where a request is sent at regular intervals to a dyno from Phantom should solve your issue. It should be justified if you are buying addons. For free sites with no revenue to Heroku, it's reasonable since they have many sites that only get visited monthly, if that.
Seems to me the real problem is you spend 50 for a bigger DB instead of 35 for a dyno. If you got no traffic why do you need so much db cache especially in addition to memcache. You can easily fix that with pgbackups and import into a basic db.
Your post says that you want to hear from Heroku, but it doesn't mention anything about you trying to contact them directly. Did you try to contact them before making a somewhat accusatory blog post without much proof? What did they say?
Write 'intelligent' automated tests (you're a HN'er so you have these already right ;) and schedule them to run CI on your production site. That may prevent any adaptive processes from caching.
The add-ons aren't Heroku, they are 3rd parties.<p>That being said, they aren't making this policy a secret. Not sure what you have to complain about after the fact.