这个问题可能有点主观,但我认为它将为代理heroku和调试延迟问题提供一些有价值的具体信息和@R_301_463@案.
我有一个使用Sinatra / Mongo构建的应用程序,该应用程序在api.example.com上公开了REST API.在Heroku Cedar上.通常,我通过位于www的Nginx提供静态文件,并通过/ api代理请求到api子域,以避免跨域浏览器投诉.我有一个机架云实例,所以我将前端临时放在了Nginx上并设置了代理.现在,代理时延迟非常可怕,每3或4个请求花费的时间超过1分钟,否则约为150ms.直接访问API(浏览器访问api.example.com)时,平均延迟约为40毫秒.虽然我知道设置不是理想的,但我没想到它会那么糟糕.
我认为这部分是由于来自机架空间的代理-服务器很可能在西海岸-到Amazon EC2东面的heroku.目前,我的想法是获得一个amazon ec2实例并将其代理到我的heroku应用程序将缓解该问题,但我想以某种方式验证这一点,而不是盲目猜测(它也更昂贵).有什么合理的方法可以确定长时间延迟来自何处？另外,关于如何构建此应用程序还有其他建议吗？我知道我可以在Heroku上提供静态文件,但是我不喜欢API为前端提供服务的想法,而是希望它们能够彼此独立地扩展.
在Rackspace上使用S3的好处是：
>因为您的应用程序和存储都在同一网络(AWS)上,所以文件从Heroku上传的速度更快.
> S3是为直接提供静态文件而构建的,而没有运行您自己的服务器代理请求的开销.
使用Cloudfront的好处是,它将在需要时缓存您的静态文件(减少多个HTTP请求),并从距离用户最近的端点提供文件. EG：如果加利福尼亚的用户发出API请求并从您那里获取静态文件,则将通过AWS California服务器(而不是您的East Coast Heroku实例)从他们那里获取静态文件.
最后,您将在应用程序端执行的操作是通过REST API向用户发送指向您静态资产的LINK(例如：http://static.myapp.com/images/background.png),这样,客户端负责直接下载内容,并能够下载内容.尽快资产.
