7

私はherokuを使用して、ビデオのホスティングを主な目的としたWebアプリケーションをホストしています。ビデオはvimeoproを介してホストされており、アップロードプロセスの処理を支援するためにmatthooksによるvimeogemを使用しています。アップロードは小さなファイルでは機能しますが、大きなファイル（たとえば、最大50MB）では機能しません。

herokuログを見ると、「RequestEntityTooLarge」を表すhttpエラー413が発生していることがわかります。これは、herokuがファイルのアップロードに課す制限（このWebページによると30MBを超える）に関係している可能性があると思います。ただし、問題は、この件に関して私が見つけた情報が古く、矛盾しているように見えることです（サイズ制限がないと主張するこのページのように）。また、herokuのサイトでもこれについて何も見つかりませんでした。

私はグーグルを検索し、いくつかのいくらか関連性のあるページ（1つと2つ）を見つけましたが、私のために働いた解決策はありませんでした。私が見つけたページのほとんどは、Amazon s3への大きなファイルのアップロードを扱っていますが、これは私がやろうとしていることとは異なります。

ログの関連する出力は次のとおりです。

2012-07-18T05:13:31+00:00 heroku[nginx]: 152.3.68.6 - - [18/Jul/2012:05:13:31 +0000]
  "POST /videos HTTP/1.1" 413 192 "http://neoteach.com/components/19" "Mozilla/5.0 
  (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20100101 Firefox/13.0.1" neoteach.com

ログに他のエラーはありません。これは、大きすぎるビデオをアップロードしようとしたときに表示される唯一の出力です。これは、タイムアウトエラーや、dynoごとに割り当てられたメモリを超える問題ではないことを意味します。

herokuは本当にアップロードサイズに制限を設けていますか？もしそうなら、この制限を変更する方法はありますか？ファイル自体はherokuのサーバーにまったく保存されておらず、vimeoのサーバーに渡されるだけであることに注意してください。

問題がアップロードサイズの制限ではない場合、他に何がうまくいかない可能性があるかを誰かが知っていますか？

どうもありがとう！

4

3 に答える 3

5

アップデート：

ここでOP。この特定の413エラーが発生した理由はまだ正確にはわかりませんが、s3_swf_uploadgemを使用して機能するソリューションを思い付くことができました。実装にはフラッシュが含まれますが、これは理想的とは言えませんが、（私が試した3つまたは4つの中の）唯一の解決策でした。

Neilが指摘したように（Neilに感謝します！）、私が受け取るはずだったエラーは「H12-リクエストタイムアウト」です。そして、私は何度も試行した後、このエラーに遭遇することになりました。この問題は、サーバーがPOSTリクエストに応答するのに時間がかかりすぎるため、コントローラーから（Web dynoを使用して）herokuサーバーに大きなファイルをアップロードしようとすると発生します。

適切なアプローチは、herokuを経由せずにファイルをs3に直接送信することです。

これが私のアプローチの概要です。

  1. s3_swf_upload gemを使用して、s3への直接アップロードフォームを提供します。
  2. gemで提供されているjavascriptコールバック関数を使用して、ファイルのアップロードが完了したことを検出します。
  3. javascriptを使用して、railsに投稿メッセージを送信し、ファイルのアップロードが完了したことをサーバーに通知します。
  4. javascriptの投稿に応答するコントローラーは、次の2つのことを行います。（a）s3_key属性をビデオオブジェクトに割り当てます（フォームでパラメーターとして機能します）。（b）delayed_jobgemを使用してバックグラウンドタスクを開始します。
  5. バックグラウンドタスクは、s3からファイルを取得します。これを実現するためにaws- sdkgemを使用しました。これは、すでにs3_swf_uploadに含まれているためです。これはaws-s3gemとは明らかに異なることに注意してください（実際、これらは互いに競合しています）。
  6. ファイルがs3から取得された後、vimeo gemを使用してファイルをvimeoにアップロードしました（まだバックグラウンドにあります）。

上記の実装は機能しますが、完全ではありません。サイズが500MBに近いファイルの場合でも、ワーカーdynoでR14エラーが発生します。これは、herokuがdynoごとに512MBのメモリしか割り当てないため、ファイル全体を一度にメモリにロードできないために発生します。この問題を回避する方法は、最後のステップである種のチャンクを実装することです。このステップでは、s3からファイルを取得し、それをvimeoに1つずつアップロードします。私はまだこの部分に取り組んでいます、そしてあなたが持っているかもしれないどんな提案も聞いてみたいです。

うまくいけば、これは誰かを助けるかもしれません。ご不明な点がございましたら、お気軽にお問い合わせください。私が言ったように、私の解決策は完璧ではないので、あなたがそれがより良いかもしれないと思うならば、あなた自身の答えを自由に追加してください。

于 2012-07-26T19:10:55.280 に答える
3

ここでの最良のオプションは、S3に直接アップロードすることだと思います。ユーザーが自分のサーバー（この場合はHeroku）にファイルをアップロードできるようにするよりもはるかに安価で安全です。これは、多くのビデオホスティングプラットフォームで使用されている実績のあるパターンでもあります（vzaarがこれを行うことは知っています）。

S3への直接アップロードを可能にするjQueryアップロードプラグインを確認してください：https ：//github.com/blueimp/jQuery-File-Upload

このトピックに関するRailscastもチェックしてください：＃381と＃383。

于 2012-10-30T15:53:59.813 に答える
2

最大の問題は、ここでのファイルのサイズではなく、ユーザーが大きなファイルをHerokuにアップロードしてから渡すことを期待しているという事実です。ここでの問題は、Herokuプラットフォーム上のすべてのリクエストが、30秒以内に最初のバイトを返す必要があることです。これはほとんどありません。

したがって、ユーザーがS3 / Vimeo /に直接アップロードしてから、アプリケーションデータをこれらのアップロードされたアセットに接続するようにすることを検討する必要があります。

Rubyを使用している場合、搬送波直接宝石は、それがどのように行われるかを調べる価値があるかもしれません。ページにドロップできるコードを介してこれを行うことができるサードパーティのサービスがあることに失敗しましたが、これらには付随する費用がかかります。

于 2012-07-18T10:01:02.163 に答える