11月
16
2013

如何真实压测一个Web浏览型应用的性能

对于应用压测大家应该都有一些自己的方式,通常都是构造一些请求,不过构造请求学问就大了。

构造什么样的请求?构造的请求是否真实?构造的请求各种业务场景的配比?读写比例?

对于一个Web浏览型应用来说,相比对纯DB的压测,会更复杂一些,主要因为涉及缓存。

之前采用过很多压测方式,包括ab、httpload等等,这些压测方式的缺点在于无法真实反映一个浏览型系统的性能指标。和其它对DB的查询或是调用外部服务的应用不同,浏览型系统在大量采用Cache和存在命中率的前提下,命中Cache和不命中的性能差距非常大。

如果按悲观的角度,从完全不命中的角度考虑,那么单机的能力会很低,相应的需要增加非常多的机器,而如果把命中率估得很高,又显得太乐观。还有另外一个比较头疼的问题是,即使你知道自己的命中率是多少,你也无法仅仅按百分比去计算你的QPS能力,因为有可能你的命中以外还有额外的开销,并不是内存直接返回的,例如各种ESI。你还需要准确地计算出这些消耗的类型以及它们各自的占比、耗时,最后会被围困在一个存在各种不确定性因素的牢笼中。

最悲催的情况就是你用一个URL去压测,压出来一个非常好的性能,然后上线时发现单机根本达不到这个性能指标,只能临时去加机器缓解。

于是我就在思考,如何摆脱之前那些不确定性因素,我们不去猜测命中率、QPS这些指标,能否通过更真实的线上请求来做?

事实是当然可以,我们随机选取一些机器,通过tcp包拷贝的方式直接将真实请求转发到一台机器处理,做到了真实场景下的压测。

这种压测的效果还是不错的,没再压出不靠谱的那么虚高的指标,回归大地,回归真实。

事实上当我们把单机QPS压到之前出问题的量级时,确实复现了当时的情况,这也进一步证实了这种压测方式是靠谱、真实的。

需要注意的是你需要注意自己的Cache范围,本机Cache还好,如果是分布式Cache,所有机器共享的,那么需要保证被压测机器访问的Cache和其它机器要分开,否则被压机器的Cache永远是命中的。

Written by Hesey Wang in: 分布式,技术,架构 |

2 Comments »

RSS feed for comments on this post. TrackBack URL

Leave a comment

©2006 - 2016 Hesey (舒)