目录

 

正文

在去年的一次面试中，我被问及性能优化方面的问题。对方问，“你在性能优化方面有哪些了解？”。我感到问题笼统，有些无从下手，于是简单地回答道：“找到程序性能的瓶颈位置，进行针对性的优化，比如为数据库查询效率低的地方适当添加索引等……”。对方的表情告诉我，这个答案不令他满意。

那时的我并不觉得自己说错，且面试最终通过，不过对方的一瞬间的不快表情还是给我留下了深刻印象。时至今日，在经过一些学习和工作后，我不得不承认自己当时的回答是肤浅的。今天写下这篇文章，结合最近的学习和工作，记录下自己对这个问题的的一些新的认识。本文不涉及具体的性能优化技术，只有一些思考问题的思路，以及面试方面的反思。

 

本文链接：https://www.cnblogs.com/hhelibeb/p/11985604.html

原创内容，转载请注明。

什么是性能？

本文的标题是“从系统角度考虑性能优化”，系统指的是一些模块和它们之间的关系的结合。模块的形式多种多样，可以是类、子系统、或服务等。

系统的价值在于它可以提供功能，比如一家手机公司的售后服务管理系统可以提供查询手机保修信息的功能、创建手机维修订单的功能。

性能，则是指系统执行功能的好坏程度。查询1台手机的保修信息需要花多久？它是查询功能的性能问题。

 
这是我在面试中犯的第一个错误：没有就问题中的基本概念（性能的定义）与提问者达成共识。讨论一个问题时，讨论者之间需要首先明确彼此对问题中的基本概念的认知，这是沟通中的一项基本工作，在陌生人之间尤其重要。既然要讨论“性能优化”，那么首先需要确定的，自然是性能的定义。
 

定义系统范围

在给出了性能的定义后，我们又面临着一个新的问题：谁的性能需要优化？

已知性能是功能的属性，功能来自于系统，那么要回答上面的问题，则首先要找到性能对应的功能，以及功能涉及的系统范围。

以上文提到的售后服务管理软件为例，

功能：查询手机的保修信息。

性能：查询效率。
 
那么，系统的范围是什么呢？要回答这个问题，需要对系统的结构有认识。作为一个企业信息化软件，售后服务管理系统的结构可能是这样，
图1 三层架构的售后管理系统
 

在定义了这样的系统范围之后，对于性能优化问题，我们便可以从系统的结构出发，进而思考一些问题，比如：

  • 从表示层到业务逻辑层是否存在较大网络延迟？
  • 业务逻辑层是否存在效率低下的代码？
  • 数据库服务器负载如何？
  • 数据库查询的执行计划是否正常？
  • 需要用哪些工具/手段调查以上问题？
  • 哪些相关人能负责调查系统的各个部分？
  • ……

但是，这样的系统通常是给企业内部用户使用的，如果面临查询保修信息性能问题的人是一个外部用户，性能所涉及的系统的可能已经有变化，系统可能是如下模样，

 

图2 售后管理系统、中间件和外部应用组成的新系统

如图2所示，虚线框代表一个单一系统的边界，边界间的连线代表了系统间的接口。3个单独的系统联合起来组成了了一个新的复合系统。

外部用户使用外部应用查询保修信息，外部应用通过接口连接中间件系统，中间件再通过接口连接原本的售后管理系统的业务逻辑层，以获取保修信息。

此时，系统的结构已与图1中的结构不同，如果还按照图1下的思考方式排查性能问题，就有可能无法找到正确的问题所在。

比如，如果查询效率问题来自于中间件的吞吐量不足，那么无论怎样在售后管理系统进行分析、优化，恐怕也很难解决问题。

有的问题可能已经过时，比如，

  • 从表示层到业务逻辑层是否存在较大网络延迟？（在新的系统结构下，用户并没有通过售后管理系统的表示层进行查询，因此该处网络延迟不会对性能有影响）

有些新的问题会产生，比如，

  • 中间件的吞吐能力如何，有什么限制？
  • 系统间是同步处理还是异步处理？
  • 系统间的网络延迟如何？
  • 接口的性能如何？
  • 系统间的容错机制是什么？
  • ……

所以，当我们希望做性能优化时，必须清晰地定义出相关的系统范围，对范围内的功能和结构做分析，才能可靠地完成工作。

 

这是我在面试中犯的第二个错误：没有考虑性能优化的问题背景，想当然地理解成单个程序的性能优化问题。在沟通中，不仅要理解双方对问题的具体概念的定义，也应充分理解问题的上下文。不然很容易陷入东拉西扯找不到重点的情况。在性能优化的问题中，系统范围和系统结构属于上下文。

关注系统的边界，有助于我们理解系统的价值，从而避免过于主观的判断。
 
这是我在面试中可能存在的第四个错误：只关注性能优化在技术方面的意义，没有提及系统价值方面的内容。

总结

这篇文章的标题包含【被面试官吊打】，原因正是开篇写到的面试经历。我想，被吊打并不可耻，只要不断反思、改善自己，那么被吊打的经历也会成为自己成长的助益。