4

概要：

写真を撮って Web アプリケーションに送信するフォトブースがあります。次に、私のWebアプリケーションはユーザーデータを保存し、写真をユーザーのfacebookプロファイル/ファンページに送信します.

私の Web アプリでは、Ruby on Rails @ Heroku Cedar スタックを実行しています。

フロー：

  1. 私の webapp は、web フォームのように、POST を介してフォトブースから写真を受け取ります。
  2. ブースはサーバーの応答を待ちます。アップロードに失敗した場合は、画像が再度送信されます。
  3. Facebook のアップロードが完了した後、webapp からの応答のみが発生します。

問題:

Webapp は、すべての処理が完了した後にのみ、フォトブースにデータを送信します。多くの場合、これは 30 秒後に発生します。これにより、Heroku で H12 - タイムアウトが発生します。

ソリューション？

ファイルがアップロードされている間、リクエストを維持します (heroku が H12 を起動するのを防ぐために、いくつかの応答データを返します - https://devcenter.heroku.com/articles/http-routing#timeouts )。- 出来ますか？Rubyでこれを達成する方法は?

Unicorn + Nginx に変更し、アップロード モジュールを有効にします (この方法では、dyno はアップロードが完了した後にのみリクエストを受け取ります - Unicorn + Rails + Large Uploads )。それは本当に可能ですか？

rack-timeout gem を使用します。これにより、多くのパススルー アップロードが失敗するため、写真が Facebook に投稿されることはありませんよね?

アーキテクチャを変更します。アップロードを S3 に直接行い、ワーカーをスピンして S3 バケットにアップロードされた新しい写真を確認し、それらをダウンロードして Facebook に送信します。-これが一番いいかもしれませんが、かなりの時間と労力がかかります。長期的にはそうするかもしれませんが、今は迅速な解決策を探しています。

他の...

4

2 に答える 2

1

この問題の詳細。

Rapgenius から: http://rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

10 日前、コンパイル済みの JavaScript の小さな問題に拍車がかかり、多くの ab ベンチマークの実行を開始しました。私たちが得た数値は、Heroku とその分析パートナーである New Relic から報告された数値よりも一貫して悪いことに気付きました。たとえば、静的な著作権ページの場合、Heroku の平均応答時間は 40 ミリ秒でした。私たちのツールは6330ミリ秒でした。このような大きな違いの原因は何でしょうか?

「リクエストは dyno レベルのキューで待機しています」と、Heroku のエンジニアは私たちに語っています。 p>

dyno レベルのキューで待機していますか? 何？

Heroku から: https://blog.heroku.com/archives/2013/2/16/routing_performance_update

ここ数年、Heroku のお客様から、Heroku での原因不明の遅延が時折報告されてきました。遅延には多くの原因があり、その中には Heroku とは関係のないものもありますが、今週まで、これらのレポートに共通点は見られませんでした。Bamboo および Cedar スタックでのルーティングおよびロード バランシング メカニズムが、Rails のお客様にレイテンシの問題を引き起こしたことがわかりました。

  • 一部のリクエストで、説明のつかない長いレイテンシが発生する
  • 報告された待ち行列とサービス時間の指標と観察された現実との不一致
  • 記録された行動と観察された行動の不一致

Bamboo スタックで実行されているアプリケーションの場合、これらの問題の根本的な原因は、Bamboo スタックでのルーティングの性質と、ルーティング クラスターの段階的な水平拡張が組み合わされていることです。Cedar スタックの根本的な原因は、Cedar が同時リクエスト ルーティング用に最適化されているのに対し、Rails などの一部のフレームワークはデフォルト設定で同時実行に対応していないという事実です。

私たちは、Heroku が Web およびモバイル アプリケーションの構築、デプロイ、スケーリングに最適な場所であることを望んでいます。この場合、私たちはその約束を果たせませんでした。失敗しました:

  • Bamboo スタックでルーティングがどのように機能するかを適切に文書化する
  • お客様が経験しているサービスの低下を理解し、是正措置を講じる
  • ルーティング レイヤーから報告され、サード パーティ ツールによって表示される紛らわしいメトリックを特定して修正する
  • ルーティング サービスの製品戦略を明確に伝える
  • Bamboo の非並行アプリから Cedar の並行 Rails アプリへのアップグレード パスを顧客に提供する
  • インフラストラクチャについて心配している間、アプリの開発に集中できるという Heroku の約束を実現します

直ちに次の措置を講じます。

  • Bamboo スタックと Cedar スタックの両方でサービスがどのように機能するかを正確に反映するようにドキュメントを改善する
  • Heroku または New Relic などのパートナー サービスによって報告された、不正確で紛らわしいメトリクスを削除する
  • アプリケーションの応答時間に対するキューイングの影響を顧客が判断できるようにするメトリックの追加
  • 開発者がレイテンシとキューイングの指標を強化するために使用できる追加のツールを提供する
  • Cedar でのコンカレント リクエスト Rails アプリのサポートを改善するための作業
  • このブログ投稿の残りの部分では、ルーティング インフラストラクチャの技術的な詳細と歴史、途中で下した決定の背後にある意図、犯した過ち、今後の道筋について説明します。
于 2013-03-12T16:11:12.090 に答える
0

1)アプリケーション サーバーとしてUnicornを使用し、ユニコーン マスターがワーカーを強制終了するまでのタイムアウトを、要求に必要な秒数よりも長く設定できます。30 秒のタイムアウトを確認できるセットアップの例を次に示します。

Nginx は heroku では動作しないため、これはオプションではありません。

2) アーキテクチャの変更もうまく機能しますが、 TransloadItなど、アップロード トラフィックが自分のサーバーをブロックしないオプションを選択します。ファイルのアップロードによってプロセスがブロックされているため、追加のdynoを追加することなく、例として写真をS3に取得し、カスタム変換、トリミングなどを行うのに役立ちます.

追加: 3) アーキテクチャのもう 1 つの変更は、受信部分のみを 1 つのアクションで処理し、Facebook タスクへのアップロードをバックグラウンド ワーカー(たとえばSidekiqを使用) に与えることです。

于 2012-09-24T16:21:46.860 に答える