在程序员面试中，有一个非常经典的问题，你们的系统性能怎么样?你是怎么得到这个结果的。不知道你有没有遇到过。可能很多人都已经知道如何去衡量自己系统的性能，但却敌不住面试官的第二个问题，如何得到这个结果。很多人都会说压测，那么在压测过程中，有我们会遇到哪些问题呢，有没有一些问题会造成我们测试结果错误。
首先是压测的时候的数据样本问题。很多人在压测，为了寻求方便，喜欢使用同一账号，或者请求相同的数据。这个是不对的，即便是你的业务代码没有做缓存，当是你使用到的很多组件，例如数据库等，都有一定的缓存，所以，这样测试的结果，数据往往是偏好的。而有的人，往往走向了另外一个极端，虽然说用户的访问情况我们无法控制，但是，大部分的互联网请求都满足28原则，即20%的用户占了80%的流量，有些人在压测的时候，往往没有注意到这样的情况，这样容易造成热点数据丢失，系统的大部分缓存无法生效，导致测试数据错误。
所以，当我们做系统压测的时候，尽量去构造更多的数据样本，避免压测数据与线上数据失真太严重，一般在大公司，这些测试数据都有专门的工程师进行维护，例如在阿里，会把现网用户的数据，然后把脱敏后的数据变成后期压测的数据。
不知道你有没有这样的经历，压测的时候到了一定的压力的时候，系统看起来已经达到了一定的瓶颈。这个时候直接大幅提升流量，发现系统的吞吐也猛增上去，看起来很不科学。之前我们已经提到过，不谈准确率的压测是毫无意义的。如果一个系统的错误率过高，这个时候多大的吞吐量意义并不是很大。在上述例子中，很有可能是因为触发了系统过载保护，直接对请求进行快速拒绝，从而给我们系统的吞吐大大提升的错觉。我们在压测的时候，一定要对系统返回数据的准确性进行校验，只有正确的返回才有意义。
另外一个重要的事情则是压测的时间不宜过短，有些同学害怕压测的时候影响下游系统，每次都是偷偷摸摸地开启一会就立马关闭，这个时候得到的压测数据意义并不是很大，我以前在阿里参加双十一全链路压测的时候，几乎每一轮最少都要持续30分钟。有些系统是需要预热的，例如一些缓存，只有达到阈值才会进入缓存，有些系统则是可能存在一些内存泄露问题，可能需要随着时间的进行才会逐渐暴露出来，有些是要到FullGC等出现才会有严重的性能问题，一般来说，我们压测的时候，要等到数据平稳之后，再持续观察一段时间，少则半个小时，像一些底层组件的基础测试，甚至需要1,2天。
好了，今天我们就分享到这里，不知道你对自己的系统是否有一些反思呢，希望对你有所帮助。
