Hacker News Reader

Comment by bgentry | Hacker News Reader

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.

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 https://devcenter.heroku.com/articles/dynos#dyno-idling

View on HN

Regardless of his slight misunderstanding of the technical side of things, he is correct when he says that you can be paying over $100 a month for a service and still be subject to dyno idling, which does seem pretty ridiculous, especially since Heroku takes a 30% cut of all add-on revenue (https://addons.heroku.com/provider/resources/HerokuAddonsLic...)

He is paying $100 for a bunch of add-ons, which have no idling. He is not paying anything for his dyno. The only current way to avoid this behavior is to pay for a dyno.

If you don't like this behavior, that's something to complain about. I'm just stating facts to help explain why his assumptions are incorrect.

It's interesting. I created a simple app (using the free dyno), use the free new relic monitoring and that keeps the app fresh (no idling). And I have no traffic coming to the site. All i'm paying for is SSL. I would think he would have no idling with multiple services pinging it for uptime.

Having said this, 30% of $108 is only $32.40, which still doesn't reach the price of another dyno.

I don't understand how my app could be set to idle when I have pings hitting it from three separate sources. Also, the pingdom ping is looking for a specific word on one of my pages. It has to find this word to be considered successful.

How often are the pings? Do the pings wait for startup or timeout? A lot of filtering methods on the traffic data could ignore isolated pings as well. They don't have to be using on/off. They could be using a higher threshold. E.g. one ping every 10 minutes, just startup and handle it then shutdown. 10 page loads every 10 minutes? Startup and stay up for 10 minutes. It's weird to even call page loads pings rather than the actual traditional ping as well, but whatever.

The pingdom ping is every minute (http check type with a string match optional setting). The heroku scheduler is running once every ten minutes. I'm not sure how often new relic runs.

Heroku scheduler runs in a separate dyno so that wouldn't impact idling of the web dyno.

In my humble opinion, there must be some other process going on in the internals of heroku to keep my app idled. Please explain it to me if I'm wrong.

Edit: The obvious solution is to buy another dyno. This isn’t the issue, however. I wrote this post to show the unfortunate grey area in their pricing structure. It’s possible for low-traffic customers to pay a lot and still be subject to the poor performance that comes with a dyno being set to idle.

The greater underlying problem is there are some customers who only need one dyno (especially those of us who are running unicorn. My dyno can handle three times the number of requests) and we would rather spend a little extra on an upgraded database or some other addons.

Well, that's that it seems. Could it be that he's running a single dyno app (with a bunch of add-ons) and that's what explains the behavior he's seeing?

Addons have no effect on dyno idling behavior.

Reply on news.ycombinator.com