我们有一个服务，它受CPU的限制很大，它将为给定的参数进行很多计算，而且，可以将计算结果缓存起来。
例如，请求/data/{id}.png的首次花费将近2秒钟，但我们会将响应缓存给以后的用户。命中缓存后，响应时间为200毫秒（因为我们将在响应前对缓存进行一些轻量级操作）。
现在，我们希望针对该服务提供最大并发性和响应时间的性能测试报告，但是对于指定的请求（具有指定的id参数），使用和不使用缓存之间会有巨大的差异。这意味着在测试过程中，如果我们清除缓存，并使用随机生成的id参数来生成报告，则可能命中的缓存太少，从而导致报告不佳。如果我们预先缓存大多数响应并进行一些测试，则报告可能看起来不错。
所以我想知道如何反映出这种搭配的真实表现？
答案 0 :(得分：0)
为了了解实际性能，您需要产生一个实际负载。不知道如何使用服务的细节，很难提出“缓存”和“新”请求的确切分布，但是很明显：行为良好的负载测试必须代表实际的应用程序使用情况，否则就没有任何意义。
因此happy path测试将类似于：
此性能测试类型称为Load Testing。但是，在这个阶段，我不会以load testing doesn't tell the full story的身份停留。
下一步是将系统置于长期负载下（即通宵或周末）。您可能还希望将负载增加到预期值以上。这种测试类型称为Soak Testing，非常适合发现memory leaks以及随着时间的推移缺少磁盘空间等资源的问题
最后，您可以检查您的应用何时（以及如何）中断。从1个虚拟用户开始，并逐渐增加负载，直到响应时间开始超过可接受的阈值或开始发生错误（无论哪种情况都发生了）。此时，您可能还知道在负载减少时应用程序是否恢复了正常。这种测试类型称为Stress Testing，最有可能通过这种方式您将了解应用程序bottleneck