Here's a little tough love: stop using Twilo. They don't provide the features that you need. Requiring you to make multiple hacks to your code and bringing the code through your server to fix headers means it isn't worth the price you are paying. Put the files on S3 and be done with it.
I don't know what Twilo is, or if I am spelling it right for that matter, but if you need to get them to fix their service or leave. On 4/6/10, 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? > > -- > 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.
