Re: Do you pay for multiple apps, or only multiple dynos per app?
On Mon, May 17, 2010 at 3:44 PM, Brian bburr...@gmail.com wrote: I currently have one app running with one dyno in production env. I'd like to create a staging one too, but am not sure if I can do that, with one dyno and its still free, or if I'll now have to pay for a 2nd dyno. No, you only pay for multiple dynos on the same app. You can have plenty of 1-dyno apps for free. thanks, Brian -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. 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 her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Simple staging process -- please check
On Wed, Apr 14, 2010 at 9:06 AM, steven_noble ste...@snoble.net wrote: Hi all, I'm about to set up a staging server on Heroku and I'm hoping you can check my logic before I do anything stupid. At present, I have a production app on Heroku: drominay-production http://drominay-production.heroku.com http://www.drominay.com I am the sole developer. The latest version of the code is on my Mac, which backs up continuously to TimeCapsule and to Dropbox. I also push the entire code-base to Heroku whenever I'm happy with the state of the code: git add . git commit -a -m here's what's new git push heroku master So far, I haven't had a reason to teach myself how to branch the code in git. I just build one feature at a time, commit regularly, and push the entire code base when it's ready. My goals are: 1. Continue to store the latest version of the code locally 2. Whenever I'm happy with the state of the code, push to a new app, drominay-staging, for a final check 3. Copy the database from drominay-production to drominay-staging to ensure the final check is robust 4. Prevent the public from accessing drominay-staging, while creating a separate code base 5. Minimize complications Here's what I propose to do: 1. Create drominay-staging A. heroku create B. heroku rename drominay-staging --app 77-green-bears-or-whatever- heroku-names-it-originally 2. Lock drominay-staging without creating two code bases A. heroku config:add RACK_ENV=staging --app drominay-staging B. Surround most of declarative_authorization's rules for the guest role with conditions like 'unless RACK_ENV == staging' 3. Test the current code and live database on drominay-staging A. git push heroku master --app drominay-staging You would have a different remote for the staging app, so you'd actually just do `git push heroku-staging` or something like that. --app is not a valid git switch :) B. heroku rake db:migrate -app drominay-staging C. heroku db:pull sqlite://backup.db -app drominay-production D. heroku db:push sqlite://backup.db -app drominay-staging You should first push production's database to staging, and then run the migrations on staging (so step B should come after step D), or else whatever changes you do to existing tables will be overwritten by the db:push. Also, after doing a rake db:migrate you need to run `heroku restart`. Cheers 4. Backup live database and then push code base to live app A. heroku db:pull sqlite://backup.db -app drominay-production B. git push heroku master --app drominay-production C. heroku rake db:migrate -app drominay-production If I do this, am I in for any nasty surprises? There looks like lot's of opportunities for nasty surprises, so I guess the next step is for me to turn this into a few trusty rake tasks. Many thanks in advance, Steven. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. 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 her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Streaming files without locking up dynos
On Tue, Apr 6, 2010 at 1:04 AM, Eric Anderson e...@pixelwareinc.com wrote: I am having some difficulty trying to figure out how to stream out files from Heroku without locking up my dynos. The basic setup I am making an app that combines Heroku and Twilio. Part of this app involves presenting users with the recordings that have been made on Twilio. Twilio provides a URL to these recordings but they don't really set the headers right (for the MP3 they don't provide the content length messing up some clients and they don't set the content disposition to attachment causing some clients to play the file inline and not do a very good job at that). In addition to these headers issues I would ideally like to not give out the URL to the recording as it is not protected by any authentication. Attempt One --- So my first thought was to simply proxy the download through Heroku. I figured this would allow me to adjust the headers and hide the Twilio URL. The problem with this is that while proxying the file it prevents the dyno from handing other requests. I had hoped if I streamed the content out (in rails render a block that chunks it out) or by using some sort of sendfile header. None of those options worked. I contacted support about this hoping there would be a decent solution but they said a dyno gets locked up until the file is downloaded. There is no way around this. This means that if I get a user on a slow modem downloading a file it takes down the dyno. If I get a multiple slow people downloading files and don't have enough dynos it basically will take down my site. :( Attempt Two -- So my next thought was to allow them to download from a location other than Heroku but still one where I have control over the HTTP headers. S3 seemed like an ideal candidate as Heroku runs on Amazon as well. So I wrote the code to copy the file from Twilio to S3 through Heroku when a download is requested then redirect to S3. This works but not well. It still locks up my dyno for about 20 seconds (for a 30 min conversation) while copying (most of the time is spent downloading from Twilio although some still spent uploading from Heroku to S3). Longer conversations would lock up my dynos even longer. I am trying to avoid pre-sending all conversations up to S3 as I want to avoid paying S3 to store the conversations when I am already paying Twilio to store them. I don't mind sending them up to S3 for temp storage but I need to do it on demand and it looks like they can't be downloaded fast enough to make that happen. So I am looking for suggestions of ways to deliver these files while not locking up the dynos. Is there any way to send a file from a URL to S3 without having it go through Heroku. Any suggestions in general? When a user requests a file, put a delayed job to get the file and upload it to S3, then poll with ajax every 1 or 2s (Your file is being prepared…) and then give them the download link to S3 once the upload is complete. That is relatively easy to do with the heroku stack and shouldn't lock anything for you. If you get multiple simultaneous users asking for files, just increase the number of workers so it speeds up the site for everyone—but again, nothing is locked, it just takes more time until the file is ready. Cheers -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. 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 her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Healthy Habbits for Huge DataSet
On Fri, Mar 12, 2010 at 12:42 AM, schapirama schapir...@gmail.com wrote: Hi Tobin, Another solution is to create a dedicated Heroku app that holds this data, and presents a service that our app can use. This means setting up another app, telling the developers about it, managing it, backups etc. A bit of a pain really, but it would work in the short term. That's definitely the solution I'd pick if I were you: a separate component with a RESTful API to do the lookups. It will certainly add the extra latency in the HTTP requests that you have to make, but I think that the cost is well covered by the extra simplicity, as long as the interface from this service to the outside world remains stable. It'd make your deployment and DB migration easier and faster (as you mention), and simplify development and debugging of your main app. And you can use memcached to hold the info on the client app to reduce the latency for repeated requests (if it makes sense), so then you pay the nice folks at heroku some money, too ;) In fact, if this lookup service is generic enough, you may offer it as a service for other apps running on Heroku that may need it... - A -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. 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 her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: app keep winding down
On Mon, Feb 15, 2010 at 2:15 PM, sslguy buttysquir...@gmail.com wrote: Any idea why my app ssltools.com keeps winding down. When I visit the site, I at first get an error code 500. Upon immediate refresh, the app comes up. However, wait a period of time, and Heroku shuts the app down. Then the cycle repeats itself. Any idea would be appreciated. Free app? Free apps act like that, if you pay for it then it shouldn't do that, AFAIK. Cheers -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. 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 her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
