You'd have one account with N apps on the account. Each app is a set of 
resources (dynos, workers, dbs, add-ons). So you'd be able to scale them 
independently from each other. 

You set the number of dynos and workers you need for each app. Heroku does not 
manage your dyno needs for you. You can use the heroku gem to manage the 
scaling yourself or you can use a 3rd party service like heroscale to do it for 
you. 

So if it were me I'd have the following:

Account Mike
  App A 
  App B 
  App C
  App D

Then you would monitor those and scale them individually. If your traffic is 
spread throughout the day than 2-3 dynos should be all you need for clients A 
and B. client C you'll have to experiment with as well as D. 

I think your costs are going to come from the DB. If you need a dedicated DB 
for each app then that's $1000 a month but performance will be nice. If you 
could combine your databases then you can save some money there. 



Mike

On Nov 18, 2011, at 10:26 AM, Joe K <[email protected]> wrote:

> I searched and found similar questions to mine, so I can probably
> infer the answer, but I want to make sure before I leap.
> 
> Let's pretend I have 4 clients with pretty elaborate Rails or Django
> apps. They are currently on a traditional shared server that we host,
> along with about 150 small sites, and the performance of these 4
> clients sites is unacceptable. So, for the sake of performance and our
> sanity we are considering moving these 4 apps to Heroku (another
> option we are considering is spinning up our own EC2 instances).
> 
> Now let's pretend I want, oh, 3 web dynos for each app. And each app
> will have it's own database.
> 
> Would I have a single account, where I set up 12 dynos, and a single
> dedicated database that is shared among all apps? Or would I set up 4
> accounts, each with its 3 dynos and a database?
> 
> From what I have read, I believe it would be the case that I would set
> up a single account with however many dynos I think I would need and
> it would be shared among as many apps as I wish to deploy, and the
> first dyno for each app would be free (not just the first dyno for the
> account). Is this correct?
> 
> Let's get a little less abstract for a moment...
> 
> Client A - Small-ish database (about 40 tables, none of them with more
> than 100 or so records), a fair amount of static content, and perhaps
> 1000 hits a day.
> Client B - Almost identical to Client A
> Client C - Medium-sized database (about 20 tables with about 1500
> records each, fairly high traffic), lots of static content (thousands
> of images)
> Client D - Very dynamic, mostly user-generated content, lots of static
> content (uploaded images, PDFs, etc.)
> 
> Given this type of configuration, I believe I read that I can
> basically give Heroku a dyno budget, it it will use what it needs to
> for each client, as it needs to, though I can also tell it how I would
> prefer those dynos is distributed. Is that correct?
> 
> Finally, it is my understanding that if dynos aren't being used, they
> are killed off, so we won't get charged for 12 dynos just because we
> had a 12 dyno budget. Heroku will use what is needed when needed, so
> costs could be less than budgeted. Correct?
> 
> Sorry for all of the questions. The boss-man is asking me to make a
> pretty important decision here, so I want to make sure I have the
> facts straight.
> 
> Thanks in advance for your help.
> 
> Joe K.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Heroku" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/heroku?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Heroku" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/heroku?hl=en.

Reply via email to