LoadTest for Backend service

明天要去跟BOSS show 这东东，先拿出来跟大家聊聊。

大家都知道做一个产品的loadTest,是比较麻烦也是比较困难的事，
对于一个系统我们所需要关注的指标有哪些？

无非就这几个问题？
 

How many orders the system can process within fixed time?

How much time the system processed one order?

What is the biggest Capability of the system?

Where is the bottle-neck of system?

而现在哪个系统能很准确的回答这几个问题的，我看很少。
但我们在即将发布的一个backend service  中，很清晰的回答了这几个问题.

我们是怎么做到的呢？

一般来说，一个backend service 可以分为三部分 Application,Input, Output. 我们在做loadtest的时候是把application看成是个box,或者几个小box组合起来的big box.所以我们所需要做的就是三方面的事。

当然即使把applicatiion当成是个box，但在loadtest前，先把这个box拆开来瞧瞧，里面是个什么东西，到底需要些什么样的input,还有output。

input 这部分工作量是很大的，想想在整个系统集成测试完后，整个项目的function算是比较完善的了，刚好，input 这些数据可以拿集成测试的数据，因为这些数据都是production上的数据，虽然可以这样稍微偷懒下，但这些数据要能覆盖所有use case，也没那么简单的哦，还有要自动产生一大把的sequence ordernum，然后根据production 的场景把这些数据模拟出来，

放到实际中去，这些工作量是在很早前就要整理出来的，不然别想测完。
output这部分那也很复杂，怎么样做才能真实的获取business counter来说话，还有硬件的使用情况。 还有硬件使用情况vsts loadtest可以帮你，但business counter怎么办，得清楚系统的output是什么后，有两种方法可以帮你收集：
batch scripts
performance counter

记住在收集数据尽量减少loadtest跟production的碰撞，不然怎么知道你收集的有包括多少是因为run loadtest 导致的，那不就没意义了。

两边都准备好了，这个black box 可以关了吧，可以啦，关之前可能还得把这big box 拆成 small box 再关起来吧， 因为这big box 里面一些数据可能会分成好几个service  跑，哪个service 有瓶颈你不知道。

好了， loadtest可以跑了吧，万事具备，什么风也不欠了，

整个loadtest run 起来是很费时的，跑吧，跑吧，自动跑吧，跑完收集数据，turning些thread ，再继续，再turning,
瞧瞧哪些小孩跑的慢，抓出来教训教训，用那个vsts 下code profiler测试下 代码性能，往往抓到的都是那个db index没建的。