3

この質問は少し主観的かもしれませんが、herokuへのプロキシとレイテンシーの問題のデバッグに対するいくつかの貴重な具体的な情報と解決策を提供すると思います。

api.example.comでRESTAPIを公開するSinatra/Mongoを使用して構築されたアプリがあります。HerokuCedarにあります。通常、私はwwwでnginxを介して静的ファイルを提供し、/ apiへのプロキシリクエストをapiサブドメインに提供して、クロスドメインブラウザの苦情を回避します。ラックスペースクラウドインスタンスがあるので、フロントエンドを一時的にnginxに配置し、プロキシをセットアップします。現在、プロキシの場合のレイテンシはひどいものです。3または4リクエストごとに、1分以上かかります。それ以外の場合は、約150ミリ秒かかります。API（ブラウザからapi.example.com）に直接アクセスする場合、平均遅延は約40ミリ秒です。セットアップが理想的ではないことはわかっていますが、それほど悪いとは思っていませんでした。

これは、ラックスペース（サーバーは西海岸にある可能性があります）からAmazonec2eastのherokuへのプロキシが原因の1つだと思います。現時点での私の考えは、amazon ec2インスタンスを取得し、それをherokuアプリにプロキシすることで問題が軽減されると考えていますが、盲目的に推測するのではなく、何らかの方法でこれを検証したいと思います（これもより高価です）。長い遅延がどこから来ているのかを判断するための合理的な方法はありますか？また、このアプリケーションを構成する方法に関する他の提案はありますか？Herokuで静的ファイルを提供できることは知っていますが、APIがフロントエンドにサービスを提供するという考えは好きではありません。むしろ、これらが互いに独立してスケーリングできることを望んでいます。

4

1 に答える 1

3

Heroku を使用して API を実行しているため、静的ファイルを「myapp-static」という名前のAmazon S3バケットに入れ、 Amazon Cloudfrontを使用して DNS CNAME レコードを介して静的ファイルをプロキシすることをお勧めします。 (static.myapp.com)。

Rackspace で S3 を使用する利点は次のとおりです。

  • アプリとストレージの両方が同じネットワーク (AWS) 上にあるため、Heroku からファイルをアップロードする方が高速になります。
  • S3 は、独自のサーバー プロキシ リクエストを実行するオーバーヘッドなしで、静的ファイルを直接提供するように構築されています。

Cloudfront を使用することの良い点は、必要な限り静的ファイルをキャッシュし (複数の HTTP 要求を減らす)、ユーザーに最も近いエンドポイントからファイルを提供することです。EG: カリフォルニアのユーザーが API リクエストを行い、静的ファイルを取得した場合、東海岸の Heroku インスタンスではなく、AWS カリフォルニア サーバーから提供されます。

最後に、アプリケーション側で行うことは、REST API で静的アセット (例: http://static.myapp.com/images/background.png ) へのリンクをユーザーに送信することです。このようにして、クライアントはコンテンツを直接ダウンロードする責任があり、できるだけ早くアセットをダウンロードできます。

于 2012-08-15T20:23:42.120 に答える