Optimization Heroku静态资产服务问题与Sinatra？

我们有一个非常大的应用程序，在我们的代码库中有大量的主干代码。。。显然，加载大约100个js文件对来自Heroku的HTTP请求是一个很大的压力，我们决定对它们进行打包以加快速度。我们决定使用gem对它们进行压缩和打包，以减少总体大小和HTTP请求。令人惊讶的是，尽管我们节省了相当多的空间并减少了近100个HTTP请求，但我们在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在deploy上构建压缩版本，然后从内存中提供服务。。。也许这会产生影响？

编辑： 我想我明白了。当你有一个正在休眠的heroku应用程序时——所有免费应用程序都会休眠，除非正在使用——heroku大约需要一秒钟左右的时间来启动应用程序。这就是为什么要启动860毫秒。然后，当您添加资产管理器时，它有很多事情要做，因此需要更多的时间。你需要连续点击10次才能看到速度的变化

例如，对我的应用程序的第一次点击需要860毫秒，但第二次、第三次等呼叫大约需要5毫秒

老思想： “在部署时构建压缩版本”-即使它工作正常，您将为运行的应用程序的每个版本（每个dyno）或更多版本进行部署-如果应用程序因其他原因（如崩溃等）需要重新启动

---

另一个想法是：医生说“heroku支持”，不管这意味着什么。但他们也谈到了“破坏缓存”——如果你的应用程序中的每个dyno对破坏缓存的特殊数字有不同的想法——那么dyno#1说特殊的是892094.js，而dyno#2说的是928449.js，而且由于dyno是随机分配的——那么你就有麻烦了。

这听起来像是Heroku的问题，而不是程序员的问题。这个数字会是平均请求时间吗？当然，每个文件发送大文件的时间会比（许多）小文件稍长一些？真的吗？一秒钟就可以处理一个30k长的javascript文件？