I want to know how heroku handles incoming web traffic and distribute among dynos. How Heroku knows when to distribute. Can one dyno handle many request at same time?
You should look at Heroku's routing documentation.
Specifically, for your question about dynos handling multiple requests, yes, Heroku will route multiple requests to the same dyno. Some servers may not handle multiple ones though. For example, the default ruby server, Webrick doesn't. You'd have to use puma to have several threads, one handling each request.
Related
I am using Heroku for one of my hobby projects. I bumped into the following problem if webhook sends a request to Heroku and Java app restarts at this time, the request will be lost. Is there any native Heroku way or plugin that ensures that Heroku will get a request, at least once?
I didn't find anything so far, and the default solution is to take AWS Lambda or Google Cloud Function to ensure scalability and availability. I feel that it adds unnecessary complexity and possibly a maintenance headache.
To Summarize:
Is there any Heroku native mechanism or Heroku plugin that ensures that requests will be delivered?
Assuming your Java application restarts are related to dyno restarts or deploys:
you might want to look into the preboot feature on Heroku.
From their documentation:
Preboot changes the standard dyno start behavior for web dynos. Instead of stopping the existing set of web dynos before starting the new ones, preboot ensures that the new web dynos are started (and receive traffic) before the existing ones are terminated. This can contribute to zero downtime deployments.
#Denis Cornehl's answer helped a lot. My answer is an extension to it.
You don't have a free solution if you have free or hobby tires. You will have to follow Enterprise Integration Patterns.
My solution was to put the queue in front of the application and consume messages when the application is up. Even though there is no free queue, some cloud providers give you free quotes for big loads. I recommend considering them before deploying and maintaining your own queues.
I don't understand what the difference between an app and Dyno is.
I want to use the hobby plan so that I can use an own SSL domain and that the servers stops sleeping.
I have a backend (nodeJS) and a frontend (reactJS).
Heroku says $7/Dyno. Does that mean I have to pay $7 for one app? Or do I pay $7 and can use several apps with it, so that they don't sleep?
An App is a set of one or more different dynos. This latter can be either of the same or different type (e.g. web, workers, ...) and having a different tier (e.g. standard, hobby, performance ...). You can see here the details for your better understanding.
It is possible to execute more instances of the same dyno type (e.g. for high-availability, processing concurrency ...). You can see here and here for details.
You basically pay for the number of dynos you run.
I need monitor apps deployed to Heroku by Prometheus monitoring system.
Problem is that if you have more dynos app, you need to know all IP address of your dynost to be able to pull metrics from all dynos.
For K8s or AWS we are able to get full list of PODs/instances, So you are able to do this.
So question is, do you know, how to get IPs of all dynos from Heroku?
I'm considering exposing the $DYNO environment variable as a label to all metrics so Prometheus can have a consistent view on which dyno it's scraping. Given a short enough scraping interval, all dynos should be able to scraped within reasonable time.
Pushgateway is not a recommended way of monitoring long-standing services.
So question is, do you know, how to get IPs of all dynos from Heroku?
This is not possible on the Heroku platform. The application dynos sit behind a load balancer, you do not have direct access to them.
I need monitor apps deployed to Heroku by Prometheus monitoring system.
Perhaps this could be split into two Prometheus jobs.
Monitor the application directly (at it's load-balanced *.herokuapp.com/metrics endpoint)
and use an exporter that gathers the dynos metrics via push somehow
Consider making use of a Heroku log drain to an exporter, converting the logs into a metrics endpoint.
There is also a private API available on Heroku application stats, not the best idea, but it might work well to gather the basic application stats. Have a look at the network requests in the Heroku dashboard to see how that works.
This would have some similarities with using a pushgateway, as described at https://prometheus.io/docs/practices/pushing/.
I'm new using heroku and I will pick 4 instances of 2X dynos and I worry about AFAIK there is no share data between dynos.
So my question is, is there a way to save data in all redis(https://addons.heroku.com/rediscloud#250) instances(located on each dynos)
Your confusion stems from assuming that Redis runs locally on each dyno. When you use an add-on such as Redis Cloud, Redis is external to all dynos and is run on sperate servers that are operated by the service provider (Redis Labs in this case).
As long as all your dynos belong to the same app (which appears to be the case), all of them will share the same add-ons, Redis Cloud included. While your app will run distributed across these dynos, all of its connections will be opened to the same Redis database (defined by the `REDISCLOUD_URL' env var) and will therefore be able to share the data in it.
we want to migrate my application to Heroku acctually we have 3 applications related and we want to move to Heroku. But we don't know how many dynos we need for deploy those applications. wether 3 applications in the same dynos and make a copy in other dynos or for each application one dynos? thanks for your help.
If they are 3 separate applications you will need a minimum of 3 dynos since each Heroku application will need to run a dyno.
As to how many dynos each of your application needs to run that all depends on how busy each site is and how long requests take to process.
I can only speak for Java and an embedded server/container. In this case you actually could deploy more than one app into your container (which will be startet from your dyno), only using one dyno.