有一天,测试 MM 告诉你,现在产品有很严重的性能问题,你刚好负责这个模块,所以性能优化的问题就交给你了。于是你虎躯一震,大脑飞速地转动起来。。。
也许是你底层代码写得太烂,导致我上层服务性能差,难道你不应该好好检查你的代码吗?
为了自己的头发少掉点,将锅甩给别人不失为明智的选择。
一天晚上,一个警察看到醉汉在路灯下找东西,于是警察问:“你在找什么?” 醉汉回答:“我的钥匙丢了!” 可是,警察扫视四周也没看到钥匙,就问他:“你确定钥匙就是在这里丢的,就在路灯下?” 醉汉说:“不,但是这里的光是最亮的。”
当一个程序猿碰到一个性能问题却无从下手的时候,top 命令看看 cpu,看看内存占用,期待能发现什么异常。也许真的能发现异常,但是未必是导致你那个问题的原因。
虽然我不知道怎么解决问题,但是我可以改参数啊!
这个方法可能有效,但是你不知道原理,在生产环境中遇到新的问题,还是没有头绪。此外,盲目的改动还会导致不可预知的风险。
不过比上面两种,在态度上好多了。
(以上方法均有不同程度的失业风险,请勿轻易尝试!)