生日猜猜猜_猜猜，不要测量

生日猜猜猜

我错失了多少次我建议通过设置目标和测量基准而不是在源代码中调整随机位来启动所有性能调整活动的机会。 在当前文章中，我将为您提供一个有关刚刚发生的事情的反例。

我们一直在改进我们自己的内部监视工具，以确保我们的生产部署快速且无错误。 为此，我们重建了日志记录解决方案和监视工具，其中包括将日志聚合到中央日志管理解决方案的一堆Logstash服务以及使日志有意义的Grafana – Kibana组合。

上周，我们终于准备好将新的监视解决方案交付生产。 我们立即开始接收有关一些公共服务表现（严重）行为的数据。 例如，获取Plumbr正在监视的JVM列表是其性能令我们不满意的操作之一：

从上面可以看出，对/ jvms URL的查询中有10％需要花费几秒钟才能完成。 这显然违反了我们为此特定操作设置的SLA。

与从我们的监视解决方案中获取数据完全并行的同时，我们的产品所有者在问题跟踪器中输入了一个错误，抱怨一个特定客户的JVM列表，其中有25个不同的JVM需要“永远”渲染。 永远是现实中的七秒，但重要的是该问题实际上已对真实用户产生影响，并且也由真实用户报告。

接下来的并行活动是，一位工程师在实现完全不相关的功能时偶然发现了设计不良的查询。 确切的细节并不是太相关，但是随着时间的流逝，过去的简单查询已演变为现在的N + 1查询问题的另一个实例。 他向我介绍了这个问题，并获得了重写设计的许可。 偶然地，所讨论的查询与获取JVM列表的查询完全相同。

今天，在我们的常规监控审查中，我们发现此操作的执行时间突然减少，如下图所示。 过去看起来像是几秒钟的操作现在减少到几百毫秒：

对这些数据的第一React是“出色，我们的工程师所做的优化工作很明显，可以将响应时间降低10倍”。 为此感到自豪，我们召集有问题的工程师参加会议，向他提供反馈并轻拍他的背，向他展示他的工作的影响。

当我们向工程师解释图表时，他只是坐在那里，沉默而困惑。 过了五分钟的困惑和尴尬，很明显，他将优化过程所包含的更改尚未合并到生产部门，并且这种性能提升与他的工作没有任何关系。

现在，这在许多方面都非常尴尬。 我们有明显的性能改善迹象，却不知道为什么会发生。 怀疑程度达到了我们怀疑必须中断功能的程度，但是对服务的大量检查表明其行为与预期的完全相同。

然后它打击了我。 昨天我正在处理一些数据完整性问题，并发现存储中缺少外键。 我已经添加了密钥和索引。 检查连续集成日志后发现，此更改已在性能改进出现时准确地传播到了生产环境中。 因此，我们找到了响应时间发生这种变化的真正原因。

仍然，我站在这里，感到惊讶和尴尬。 一方面–非常棒的是，我们设法在性能影响尚未完全显现之前就对性能问题进行了修补。 另一方面，整体情况与我的核心信念相矛盾，我一直说“要衡量，不要猜测”。 考虑到行动胜于雄辩，我现在有一些思考的地方。

翻译自: https://www.javacodegeeks.com/2014/11/guess-dont-measure.html

生日猜猜猜