There are random times throughout the day that my app can have pretty extreme increases in load based on various factors.
At those times, I'd like to automatically increase the number of dynos.
I'd like to base the increase on the load time. So if it's taking X amount of time for pages to load, increase dynos. Otherwise, go back down.
Anything like that exist?
HireFire is able to auto-scale both your web- and worker dynos based on various metrics. We currently support the following metric sources/types:
HireFire (Response Time) | Web Dynos
HireFire (Job Queue) | Worker Dynos
Heroku Logplex (Response Time) | Web Dynos
Heroku Logplex (Requests Per Minute) | Web Dynos
Heroku Logplex (Dyno CPU Load) | Web Dynos
NewRelic (Apdex) | Web Dynos
NewRelic (Response Time) | Web Dynos
NewRelic (Requests Per Minute) | Web Dynos
HireFire (Response Time) performs a basic HTTP request to measure response times.
HireFire (Job Queue) allows you to auto-scale your worker dynos based on their queue-sizes. You'll setup a very simple endpoint on your end (we have a RubyGem for this, but it can be done in any language with any library very easily). We'll periodically perform checkups and scale your worker dyno formation accordingly.
New Relic allows you to integrate with New Relic. It'll periodically fetch up-to-date metric data such as Average Response Time, Requests Per Minute and Apdex to determine your web dyno formation.
Heroku Logplex is our latest addition. This approach relies on your (and Heroku's) logs. Your logs will be streamed from Heroku's Logplex to HireFire's Logdrain, where it will be parsed for metric data. This allows you to auto-scale your web dynos in a more reliable way than with HireFire/ResponseTime as it grabs data directly from Heroku's Router. This approach doesn't require any external dependencies such as New Relic either.
Get in touch if you have any questions!
There is a new plug and play addon that just launched for this: https://addons.heroku.com/adept-scale
Seems like heroku-autoscale is a good bet.
Related
I'm trying to understand the Dyno Load section of my metrics of my app. My particular app has five worker dynos. Given that information, if I see a Load Max or Load Avg of 2 or 2.5 then I should be ok, right? With this setup my goal would be to keep the load under five (1 for each dyno)? Is that the correct way to view this?
The load you see in Heroku Metrics is per dyno. Each dyno sends its own load, the max being the maximum value.
So expecting 5 to be a good value because you have 5 dynos isn't right.
You need to evaluate that value based on the type of dynos you have, as each of them will have more CPU shares and be able to handle more load.
Heroku recommends (here) keeping Free, Hobby and Standard dynos between 0.5 and 1.0 load.
Performance-M dynos can go to 3.0 or 4.0, and PL can go up to 16.0.
See also dyno sizes and their CPU share: https://devcenter.heroku.com/articles/dyno-types
I have deployed my node app on heroku free web dyno plan.I want to know how much free hours are remaining and how much are left so for that I am using
heroku ps -a <AppName>
After running above command I got something like this below:
As per the result everything is clear but what does Web(Free) mean written in green color. Someone please let me know any help would be appreciated.
THANKS
It means your app is running on a single web dyno and free dyno type.
Dyno configurations
Every dyno belongs to one of the three following configurations:
Web: Web dynos are dynos of the “web” process type that is defined in your Procfile. Only web dynos receive HTTP traffic from the routers.
Worker: Worker dynos can be of any process type declared in your Procfile, other than “web”. Worker dynos are typically used for background jobs, queueing systems, and timed jobs. You can have multiple kinds of worker dynos in your application. For example, one for urgent jobs and another for long-running jobs. For more information, see Worker Dynos, Background Jobs and Queueing.
One-off: One-off dynos are temporary dynos that can run detached, or with their input/output attached to your local terminal. They’re loaded with your latest release. They can be used to handle administrative tasks, such as database migrations and console sessions. They can also be used to run occasional background work, as with Heroku Scheduler. For more information, see One-Off Dynos.
Once a web or worker dyno is started, the dyno formation of your app will change (the number of running dynos of each process type) - and subject to dyno lifecycle, Heroku will continue to maintain that dyno formation until you change it. One-off dynos, on the other hand, are only expected to run a short-lived command and then exit, not affecting your dyno formation.
Dyno Types
Heroku provides a number of different dyno types each with a set of unique properties and performance characteristics. Free, Hobby, Standard and Performance dynos are available in the Common Runtime to all Heroku customers. Private Dynos only run in Private Spaces and are available in Heroku Enterprise.
I am experiencing a once per 60-90 minute spike in traffic that's causing my Heroku app to slow to a crawl for the duration of the spike - NewRelic is reporting response times of 20-50 seconds per request, with 99% of that down to the Heroku router queuing requests up. The request count goes from an average of around 50-100rpm up to 400-500rpm
Looking at the logs, it looks to me like a scraping bot or spider trying to access a lot of content pages on the site. However it's not all coming from a single IP.
What can I do about it?
My sysadmin / devops skills are pretty minimal.
Guy
Have your host based firewall throttle those requests. Depending on your setup, you can also add Nginx in to the mix, which can throttle requests too.
I am using New Relic standard and Rails 3 on Heroku to build a web site. But not sure what indicators shown on New Relic should I keep an eye on to scale up the web dyno when certain criteria are met?
Say, indicator A comes to X level, I should add one Dyno to put it down.
Thank you!
Primarily you want to be looking at your logs and at the queue attribute on the heroku[router] - if this starts going up (and importantly staying up) then you have too many requests that are being queued and can't be processed fast enough.
If you're seeing long queue-wait times in the New Relic dashboard and there are no other good explanations (i.e. high variability in response times, use of Thin web server instead of Unicorn, etc.), that's generally a good indication requests are waiting in queue to be processed by a dyno.
I have a Sinatra app I plan on hosting on Heroku.
This application, in part, scrapes a lot of information from other pages around the net and stores the information to a database. These scrapping operations are a slow process, so I need them to run in another thread/process separate from my Sinatra app.
My plan is just to have a button for each process that I can click and the scrapping will take place in the background.
I'm unsure what's the best way to do this, complicated by what Heroku will allow.
There's a gem called hirefire specifically for that:
HireFire automatically "hires" and "fires" (aka "scales") Delayed Job
and Resque workers on Heroku. When there are no queue jobs, HireFire
will fire (shut down) all workers. If there are queued jobs, then
it'll hire (spin up) workers. The amount of workers that get hired
depends on the amount of queued jobs (the ratio can be configured by
you). HireFire is great for both high, mid and low traffic
applications. It can save you a lot of money by only hiring workers
when there are pending jobs, and then firing them again once all the
jobs have been processed. It's also capable to dramatically reducing
processing time by automatically hiring more workers when the queue
size increases.