Rack::Cache性能差

Question

我已经将Rack::Cache设置为我的堆栈中最顶层(最后)的中间件。我的应用程序托管在heroku雪松上，所以Rack::Cache也负责静态资产。

它由heroku memcached产品支持，配置如下：

config.action_dispatch.rack_cache = {
  :metastore    => Dalli::Client.new,
  :entitystore  => 'file:tmp/cache/rack/body',
  :allow_reload => false
}
config.static_cache_control = "public, max-age=2592000"

它的速度很慢。

我正在使用ab测试图像文件的性能。

ab -n100 -c10 https://example.com/foo.jpg

在我的日志中，所有的请求都是缓存命中(“新鲜”)。但是性能很差，只有大约6个请求/秒。我知道Rack::Cache不会像一个专用的http代理那样执行得那么好，但我当然期望比这更高的吞吐量。

更新我不知道我以前怎么没想过这个问题，但是我的基准确实正在使我的互联网连接变得最大。如果我用robots.txt (而不是jpg )做同样的测试，我会得到20个请求/秒(并且仍然是最大的下游请求)。

Answer 1

我注意到您的帖子中的URL是HTTPS。我在基于主机名的SSL雪松堆栈上遇到了一个问题，在这个问题上，某些请求(包括静态资产和其他请求)将经历很高的延迟，尽管日志上说队列时间为0ms，服务时间为5-10 0ms。以下是Heroku的支持响应(他没有提到清漆不缓存来自雪松应用程序的资源，尽管它在运行基于主机名的SSL时存在于堆栈中)：

我们还不完全确定是什么导致了这一切，但我们怀疑应该归咎于瓦尼什。通常，与雪松堆栈，清漆是不存在的。但是，当使用外接程序时，Varnish将被添加回响应过程中。没有必要同时使用Rack::Cache和Varnish。

我建议把这幅画上的清漆去掉看看是否有帮助。这样做的方法是将SSL移动到新的SSL外接程序SSL终结点。soon在技术上仍然处于测试阶段，但它很快就会面世，它的成本将与same相同。这是Heroku上SSL的未来，在各个方面都会更好。

http://devcenter.heroku.com/articles/ssl-endpoint-beta2

用户: beta通行证：****

移动的缺点是，您必须更新DNS，但一旦完成，Varnish将脱离现实，我们将能够更好地了解它是否是问题所在。

我们还考虑了您当前的SSL端点Amazon很糟糕，需要替换的可能性。但如果是这样的话，许多请求将是缓慢或失败的，而不仅仅是一个随机的慢请求。换掉当前的ELB也将涉及DNS更改。移动到新的swapping插件将使这种情况在未来变得更容易--如果交换ELB是必要的，则不需要进行DNS更改。

就目前而言，我认为迁移到SSL端点将是最好的。

当然，我看到的潜伏期有时会上升到30-60秒的范围，这显然比你看到的要差一些。当我在我的一些(HTTPS)雪松应用程序上对静态资产运行相同的apache命令时，我没有做得更好(10-15 req/s)。当我将并发性提高到50或100时，RPS高达30。然而，在清漆正面的竹HTTPS应用程序上，我可以获得超过50 req/s的静态资产。如果我的计算机能够处理更高的并发性，我怀疑它会更高。我的互联网连接是高延迟的，因为它是在蜂窝网络上。