品味性能之道<二>：性能工程师可以具备的专业素养

 

 

 

性能工程师可以具备的专业素养

• 程序语言原理，包括：C、C++、java及jvm、ASP，因为建站大部分外围应用和中间件都是JAVA编写，大部分的电商平台采用的ASP编写，底层核心系统是C/C++编写；
• 数据库管理和性能优化，数据库永远的性能要点，包括：传统的关系型数据库oracle、db2、mysql、sql server等，更有对象型新贵数据库mongodb、hadoop、Cassandra等；
• kernel的实现（比如内存管理、文件系统、系统调用、线程与进程管理），如果不熟悉kernel，确实很难在底层系统的性能测试上有所建树；
• 前端html、css、javascript、flash等技术，懂得浏览器加载原理以及优化策略；
• 主要硬件知识，特别是存储相关，这块主要是受国外Percona公司的Peter和Vadim影响，他们能成为世界公认的mysql性能专家，他们熟悉mysql源码当然很重要，但也与他们那非常渊博的底层硬件知识是分不开的；
• linux管理和shell编程，shell的熟练决定了工作效率；
• 至少一种性能测试工具，不止使用，更包括原理与如何改造扩展；
• 一种脚本语言ruby、perl、python，快捷构建各种性能所需小工具有利于提升工作效率；

        以上所述都不重要，对于公司而言出钱请相关领域专家就完事。对于个人而言，要在某一个领域有所建树都是需要极长时间的积累。由深专不同领域的人员组成团队协同作战，这样做起来更靠谱些，啥都懂只会啥都不精。当然为了团队协同交流的需要，谈到相应技术话题时，能够及时产生大脑响应这是必要滴。不然鸡同鸭讲，那就没法团队协作。

---

 

看懂程序的性能

        对于客户端程序而言，拙劣的性能会严重影响用户体验。界面停顿、抖动、响应迟钝等问题都会遭到用户不停的抱怨。最典型的例子就是Eclipse工具在Full GC时出现程序假死现象，相信一定不少同学在抱怨其性能诟病。

        对于服务器程序来说，性能问题则更为重要，相信不少后台服务器软件都有各自的性能目标。以Web服务器为例，服务器的响应时间、吞吐量则是两大重要的性能指标。当服务器承受巨大的访问压力时，可能出现响应时间变长、吞吐量下降，甚至是抛出内存溢出异常，然后崩溃，甚至宕机。

        前面提到的问题，都是性能调优需要解决的。一般来说，程序性能通过以下几个方面来表现：

• 执行速度：程序的反应是否迅速，响应时间是否足够短；
• 内存分配：内存分配是否合理，在一般应用场景中是否过多地占用内存或者存在泄漏，在批处理应用场景中是否尽可能的占用内存或者存在泄漏；
• 启动时间：程序从运行到可以正常处理业务需要花费多长时间；
• 负载承受能力：当系统压力上升时，系统的执行速度、响应时间的上升曲线是否平缓（也可叫做性能拐点）；

---

 

性能的参考指标

        为了能够科学地进行性能分析，对性能指标进行定量评测是非常重要的。以下是一些可以用于定量评测的性能指标：

• 执行时间：一段代码从开始运行到运行结束，所使用的时间；
• CPU时间：函数或者线程占用CPU的时间；
• 内存分配：程序在运行时占用的内存空间；
• 磁盘吞吐量：描述I/O的使用情况；
• 网络吞吐量：描述网络的使用情况；
• 响应时间：系统对某用户行为或者事件做出响应的时间。响应时间越短，性能越好；

---

 

 

木桶原理与性能瓶颈

        一只木桶能盛多少水，并不取决于最长的那块木板，而是取决于最短的那块。同样这个理论应用到软件性能上，最短的那块木板便是性能瓶颈。

        根据应用场景的不同，任何计算机资源都有可能成为系统瓶颈。其中最有可能成为系统瓶颈的计算资源如下：

• 磁盘I/O：由于磁盘I/O读写的速度要比内存慢很多，程序在运行过程中，如果需要等待磁盘I/O完成，那么抵消的I/O操作会拖累整个系统；
• 网络带宽：对网络数据进行读写的情况与磁盘I/O类似。由于网络环境的不确定性，尤其是对互联网上远端数据的读写，网络速度可能比本地磁盘I/O更慢。因此，如不加特殊处理，也极有可能成为系统瓶颈；
• CPU：对计算资源要求较高的应用，由于其长时间、不间断地大量占用CPU资源，那么对CPU的争夺将导致性能问题。如科学计算、3D渲染等对CPU需求旺盛的应用；
• 异常处理：对Java应用来说，异常的捕获和处理时非常消耗资源的。如果程序高频率地进行异常处理，则整体性能便会有明显下降；
• 数据库：大部分应用程序都离不开数据库，而海量数据的读写操作可能是相当费时的。而应用程序可能需要等待数据库操作完成或者返回请求的结果集，那么缓慢的同步操作将成为系统瓶颈。
• 锁竞争：对高并发程序来说，如果存在激烈的锁竞争，无疑是对性能极大的打击。锁竞争将会明显增加线程上下文切换的开销。而且，这些开销都是与应用需求无关的系统开销，白白占用宝贵的CPU资源，却不带来任何好处。
• 内存：一般来说，只要应用程序设计合理，内存读写速度上不太可能成为性能瓶颈。除非应用程序进行了高频率的内存变换和扫描，但这些情况比较少见。使内存制约系统性能的最可能的情况是内存大小不足。与磁盘相比，内存的大小似乎小的可怜，这意味着应用软件只能尽可能将常用核心数据读入内存，这在一定程度上降低了系统性能。

---

 

 

JAVA performance把应用中代码引起的性能问题分为以下几类

• 低效的算法、数据结构
• 锁竞争
• 低效的代码

---

 

Amahl定律

        Amahl定律是计算机科学中非常重要的定律，它定义了串行系统并行优化后加速比的计算公式和理论上限。

        加速比定义：加速比=优化前系统耗时/优化后系统耗时

        所谓加速比，就是优化前的耗时与优化后耗时的比值。加速比越高，表明优化效果越明显。

        Amahl定律给出了加速比与系统并行度和处理器数量的关系。设加速比为Speedup，系统内必须串行化的程序比重为F，CPU处理器数量为N，则有：

        

        根据此公式，如果CPU处理器数量趋近于无穷，那么加速比与系统的串行化率成反比，如果系统中必须有50%的代码串行执行，那么系统的最大加速比为2。

        假设有一程序分为以下步骤执行，每个执行步骤花费100个时间单位。其中只有步骤2和步骤5可以进行并行，步骤1、2、3必须串行。在全串行的情况下系统合计耗时500个时间单位，如下图：

        

        若将Step4和Step5并行化，假设在双核处理上，则有下图所示的处理流程：

        

        在这种情况下，Step4和Step5的耗时将为50个时间单位。故系统整体耗时为400个时间单位。根据加速比的定义有：

       

        或者前文中给出的加速比公式，由于5个步骤中，3个步骤必须串行，因此其串行化比重为3/5=0.6，即F=0.6，且双核处理器的处理器个数N为2。代入公式得：

        

        在极端情况下，假设并行处理器个数为无穷大。Step4和Step5的处理时间趋近于0。即使这样，系统整体耗时依然大于300个时间单位。即加速比的极限为500/300=1.67。土豪老板财大气粗，不顾技术实现，仅增加CPU处理器的数量并不一定能起到有效的作用，并且大量的增加CPU处理器的办法，同时也会增加各个进程间通信成本。需要从根本上修改程序的串行行为，提高系统内可并行化的模块比重。

---

 

 

浅析CPU资源

 

 

系统态cpu资源消耗过高cpu消耗中有两项主要的消耗分别是：

• 用户态
• 系统态资源消耗

系统态cpu消耗：指内核对系统资源进行调度时消耗的cpu资源；

用户态：应用程序进程消耗的cpu资源；

比如我们的java应用代码运行的cpu消耗就是用户态消耗。当系统态资源消耗高时，用户态能够能够使用的cpu资源自然就变少了。所以当系统态资源消耗过高时，应用就需要考虑进行性能调优了。java应用满负载运行时建议用户态和系统态的比例为65%~70%/30%~35%。

在linux下使用top命令查看cpu消耗，top命令使用的一些tips：

 

第一行

给出当前服务器时间，启动时间，当前登录用户，以及系统负载情况。需要注意的是linux的系统负载是以1分钟、5分钟和15分钟内的平均值 来衡量的。

第二行

列出系统进程任务情况分别如下：

• total指的是系统总共250个进程；
• running指的是1个进程处于运行状态；
• sleeping指的是249个空闲进程；
• stopped指的是0个停止进程；
• zombie指的是0个僵尸进程。僵尸进程指的是子进程退出后父进程并没有处理子进程的退出信号，导致子进程变为僵尸进程。

第三行

给当前CPU的工作情况分别如下：

• %us(user)指的是cpu用在用户态程序上的时间；
• %sy(sys)指的是cpu用在内核态程序上的时间；
• %ni(nice)指的是用在nice优先级调整过的用户态程序上的时间；
• %id(idle)指的是cpu空闲时间；
• %wa(iowait)指的是cpu等待系统io的时间；
• %hi指的是cpu处理硬件中断的时间；
• %si指的是cpu处理软中断的时间；
• %st(steal)用于有虚拟cpu的情况，用来指示被虚拟机偷掉的cpu时间；通常idle值可以反映一个系统cpu的闲忙程度。

 

 

系列博客：

品味性能之道<一>：性能测试思维与误区

品味性能之道<二>：性能工程师可以具备的专业素养

品味性能之道<三>：方法论

品味性能之道<四>：管理重于技术

品味性能之道<五>：SQL分析工具

品味性能之道<六>：图形化SQL分析工具

品味性能之道<七>：索引基础

品味性能之道<八>：Loadrunner关联技巧与字符处理

品味性能之道<九>：利用Loadrunner编写socket性能测试脚本简述

品味性能之道<十>：Oracle Hint

品味性能之道<十一>：JAVA中switch和if性能比较

深入理解Loadrunner中的Browser Emulation

使用Loadrunner对IBM MQ进行性能测试

怎么做性能测试--响应时间