Heroku 静态资产服务与 Sinatra 存在问题？
我们有一个非常大的应用程序，在我们的代码库中包含大量的主干代码...显然，加载 100 个左右的 js 文件对 Heroku 的 HTTP 请求来说是一个很大的压力，我们决定将它们打包以加快速度。我们决定使用 sinatra-assetpack gem 来压缩和打包它们，以减少总体大小和 HTTP 请求。令人惊讶的是，尽管我们节省了大量空间并将 HTTP 请求数量减少了近 100 个，但 Heroku 中的日志显示 GET 请求的服务器时间有所增加！
我很难理解为什么会发生这种情况，但这里有一个快速打印输出：
Before assetpack:
heroku[router]: GET xxxx dyno=web.5 queue=0 wait=0ms service=888ms status=200 bytes=35726
After assetpack:
heroku[router]: GET xxxx dyno=web.6 queue=0 wait=0ms service=1862ms status=200 bytes=30103
请求的大小下降了 15%，而服务时间增加了一倍多。这是怎么回事？
编辑：我应该提到 assetpack 在部署时构建压缩版本，然后从内存中提供服务......也许这会产生影响？
We have a very large app with TONS of backbone code throughout our codebase... Obviously loading 100 or so js files is a big strain on HTTP requests from Heroku and we decided to package them up to speed things up. We decided to use the sinatra-assetpack gem to compress and package them to reduce overall size and HTTP requests. Surprisingly, even though we saved a decent amount of space and reduced the number of HTTP requests by nearly 100, our logs in Heroku show an INCREASE in server time on the GET requests!
I'm struggling to understand why this may be happening but here's a quick printout:
Before assetpack:
heroku[router]: GET xxxx dyno=web.5 queue=0 wait=0ms service=888ms status=200 bytes=35726
After assetpack:
heroku[router]: GET xxxx dyno=web.6 queue=0 wait=0ms service=1862ms status=200 bytes=30103
The size of the request goes down by 15% while the service time more than doubles. What is going on here??
edit: I should mention that assetpack builds the compressed versions on deploy and then serves then from memory... Perhaps that could have an impact?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编辑：
我想我已经明白了。当您有一个处于睡眠状态的 Heroku 应用程序时（所有免费应用程序都会睡眠，除非正在使用），Heroku 需要大约一秒钟左右的时间来启动该应用程序。这就是为什么启动时间为 860 毫秒。然后当你添加资源管理器时，它有很多事情要做，所以需要更多的时间。您需要连续敲击 10 次才能看到速度的变化。
例如，我的应用程序的首次调用需要 860 毫秒，但第二次、第三次等调用大约需要 5 毫秒。
较旧的想法：
“在部署时构建压缩版本” - 即使它工作正常，您也会为运行的应用程序的每个版本（每个dyno）进行部署，或者更多 - 如果应用程序因其他原因需要重新启动，例如崩溃， 。
另一个想法：文档说“heroku 支持”，无论这意味着什么 但他们也谈论“缓存破坏” - 如果应用程序的每个测功机对缓存破坏特殊数字是什么有不同的想法，那么 dyno #1 说特殊 # 是 892094.js，而 dyno #2 说 928449。 Node.js，并且由于测功机是随机分配的 - 你会遇到抖动。
Edited:
I think I figured it out. When you have a heroku app that is sleeping - all free apps sleep unless in use - it takes Heroku about a second or so to boot the app. That's why you get 860 ms to boot. Then when you add in the asset manager, it has a lot to do, so takes more time. You need to hit it 10x in a row to see changes to the speed.
For instance, the initial hit to my app takes 860ms, but the second, third, etc call takes about 5ms.
Older thoughts:
'Builds the compressed versions on deploy' - Even if its working right you will deploy for each version of your app that runs (each dyno), or more - if the app needs a reboot for other reasons, like a crash, etc.
Another thought: The docs say 'heroku support' whatever that means. But they also talk about 'cache busting' - what if each dyno of your app has a different idea of what the cache busting special number is - so dyno #1 says the special # is 892094.js, while dyno #2 says 928449.js, and since dynos are assigned at random - you have thrashing.