3

这个问题可能有点主观，但我认为会提供一些有价值的具体信息和解决方案来代理 Heroku 和调试延迟问题。

我有一个使用 Sinatra/Mongo 构建的应用程序，它在 api.example.com 上公开了一个 REST API。它在 Heroku Cedar 上。通常，我通过 www 的 nginx 提供静态文件，并将 /api 的请求代理到 api 子域，以避免跨域浏览器投诉。我有一个机架空间云实例，所以我将前端暂时放在 nginx 上并设置代理。现在代理时延迟很可怕，每 3 或 4 个请求需要超过 1 分钟，否则约 150 毫秒。直接访问 API（浏览器访问 api.example.com）时，平均延迟约为 40 毫秒。虽然我知道设置并不理想，但我没想到它会那么糟糕。

我认为这部分是由于从机架空间代理 - 服务器很可能在西海岸 - 到亚马逊 ec2 东部的 heroku。我目前的想法是获取一个亚马逊 ec2 实例并将其代理到我的 heroku 应用程序会缓解这个问题，但我想以某种方式验证这一点，而不是盲目猜测（它也更昂贵）。是否有任何合理的方法来确定长延迟的来源？此外，关于如何构建此应用程序的任何其他建议？我知道我可以在 Heroku 上提供静态文件，但我不喜欢我的 API 服务于我的前端的想法，我宁愿这些能够相互独立地扩展。

4

1 回答 1

3

由于您使用 Heroku 来运行您的 API，我建议将您的静态文件放入一个名为“myapp-static”的Amazon S3存储桶中，然后使用Amazon Cloudfront通过 DNS CNAME 记录代理您的静态文件(static.myapp.com)。

在 Rackspace 上使用 S3 的好处在于：

  • 您从 Heroku 上传文件会更快，因为您的应用程序和存储都在同一个网络 (AWS) 上。
  • S3 是为直接提供静态文件而构建的，无需运行您自己的服务器代理请求的开销。

使用 Cloudfront 的好处在于，它会根据需要缓存您的静态文件（减少多个 HTTP 请求），并从离用户最近的端点提供文件。EG：如果加利福尼亚的用户发出 API 请求并从您那里获取静态文件，则该文件将从 AWS 加利福尼亚服务器而不是您的东海岸 Heroku 实例从他们那里获得。

最后，您将在应用程序端做的是在您的 REST API 中向用户发送一个指向您的静态资产的链接（例如：http ://static.myapp.com/images/background.png ），这样客户端就是负责直接下载内容，并将能够尽快下载资产。

于 2012-08-15T20:23:42.120 回答