qileilove

谈到软件产品的性能调优，我认为可以从狭义和广义两个范围来理解。从狭义的范畴来看，性能调优主要是指通过修改软件程序逻辑、结构等技术手段提升软件产品的各项性能指标，如响应时间等等；而从广义的层面来看，就不仅限于程序内部了，因为造成系统性能问题的瓶颈很可能来源于方方面面，而这种情况往往是性能调优很普遍的情况，下面就从广义的范围细分成几个角度来进行阐述。

　　一、软件层面

　　a）首先要谈到的肯定是我们自己提供的软件产品，因为它的内部设计是我们最清楚的，用户在应用时遇到性能问题首先要质疑的也是我们的产品，因此这个层面的调优肯定是我们软件供应者的重中之重！举例来说：比较复杂的业务，通常会在程序中输出一些关键操作的执行时间，然后再分析哪些操作比较耗时，之后再找原因。具体分析原因就比较多了，比如多次循环查询数据库，复杂耗时的SQL语句，频繁的远程调用，复杂算法，等等。

　　b）数据库层面：设计数据库时应考虑到在少访问和简化、优化访问的前提下实现产品功能，多用存储过程代替完整SQL，尽量用连接池使用户和服务的连接实现可复用，尽量不使用游标结构等，对基本表的设计进行优化如第三范式、引入“中间表”的技术思路，控制用户实际数据量的增长；对数据库进行索引优化，避免整表扫描；对数据库的事务处理进行调优（去除不必要的锁、将事务切分成小的粒度、适当降低隔离级别、减少访问热点等）；SQL语句调优（尽量优化那些无意义的、拙劣的、复杂的SQL）等等。这方面主要就是本着一个通过尽可能少的磁盘访问而获得所需要的数据这么一个基本原则。

　　c）中间件软件：某些软件产品为数据库、中间件、客户端的三层架构设计，此时为系统运行提供服务的中间件软件也将成为制约性能的一个瓶颈。因此在这个层面上也是有很大调优空间的，比如各种相关参数的设置优化，使用性能包、性能监控分析工具等，避免竞争线程资源，批处理，堆大小的设置，为溢出条件设置执行队列，后备缓冲，减少非重要应用的资源占用，使用集群等。举个简单的实例，我曾经遇到一个产品的性能问题，当查询数据大到一定程度时，系统一直灰屏死机状态，结果只是通过把JVM内存参数设置从默认值的128调为256就轻松解决了，只是参数值的一个小变动，反映到具体的用户面前就是出的来和出不来数据的本质差别！

　　d）操作系统：无论是服务器还是用户终端，都脱离不了操作系统这个基础的应用平台的支持，因此这个层面的性能调优工作也千万不能遗漏。例如同厂商的不同版本（如WINDOWS各系列）、不同厂商（MS/HP/SUN等）不同的操作系统（WINDOWS/LINUX/UNIX等），这些操作系统的性能表现本身就有所差异，如内存的分配、虚拟内存的处理、数据的读写交换、兼容稳定抗压性等等方面，利用相应的调优方法和工具，可以对此环节进行优化。

　　二、硬件层面

　　a）CPU：中央处理器，决定数据处理速度的核心部件，与性能表现的相关度可想而知，硬件方面具体调优方法及工具本文中不再赘述，下同！

　　b）内存、缓存：数据交换的临时存储空间，它的大小形象的说就像是火车站候车室的面积，与性能的关系可想而知。比如有些程序设计的操作对内存回收设计有漏洞，导致频繁操作时内存泄漏越来越多，系统就会越来越慢。

　　c）硬盘、I/O：数据存储、调用的载体，如果存储器像候车室，那这些就像是车箱的大小与节数等。

　　d）网络：如果还是用坐火车为例，网络的差别就像是普通、快速、动车、磁浮等各种等级的差别，如果一个“系统”频繁需要通过火运完成，那它的性能表现和网络的相关性就不言而喻了。比如某些软件功能设计时没有考虑网络流量方面的风险，导致每次操作时网络连接次数很多，频繁调用或是数据包过大，这些都会导致在一定网络条件下产生性能问题。

　　e）显卡等特殊硬件：不同软件产品应用的业务可能用到不同的专用硬件或外设，比如一个很炫的游戏对显卡的要求就会很高，当显示成为短板时死机、跳帧等异常；一个收款台的扫描、信用卡POS机如果质量或兼容性、稳定性不佳时，也可能会造成性能表现的不理想，等待诸如此类问题。

　　三、业务层面

　　a）业务流程重组：项目甲方在购买软件产品或系统服务前，一般会找相关专家、售前人员作一些相关的评估或“体检”，找出现有运作模式下的一些存在优化空间的错误环节或繁冗流程、制度体系等。因此在这个阶段是否对项目应用方作了足够的优化，也对未来产品上线后的应用性能表现在宏观上起着决定作用。取例来说：如果一个系统设计前没有作过这方面的优化，最后应用时需要100人操作10个步骤才能完成，通过流程重组后，从业务上只需要40个人干5个步骤就搞定了，那么没上软件前我们就能从理论上把性能表现优化80%！

　　b）需求定位：与上一条阐述的类似，只是介入的阶段和角色有所区别。需求人员有时是从项目乙方发起的，主动地、有策略性的去选择一些有代表性的单位去调研软件产品的概要或详细需求，为后续的产品开发设计提供依据。在这一阶段是否有效的考虑了未来产品的性能表现，对其提出相关的设计目标，也对后续的性能表现有一定的影响。

　　c）实施方案：一般当大型一些的项目合同签订完毕后，就会分期安排实施人员负现场牵头并组织双方成立实施小组团队，共同制订系统的上线、操作培训、应用方案等，并执行方案直至系统正常上线运行，项目交付。因此，这个方案制定的是否精简、高效，也直接关系了用户应用系统的性能表现。

1、使用分布式的版本管理系统

　　如果你觉得不需要使用版本管理系统，那我们沟通会有代沟，如果你是cvs、svn的粉丝，或者由于某种原因没有使用过分布式版本管理系统，比如git，那强烈建议你去看一下“why git is better than x”。

　　2、一键式发布

　　这里发布的目标位置，既可以是开发机，做本地测试；也可以是测试机，为QA准备好捉虫游戏的森林；还可以是生产环境（或者beta环境），供用户直接访问。

　　如深度xp一键恢复系统一样，一键式发布需要自动完成很多工作：代码自动化测试（开发阶段），打包压缩，编译（测试阶段），数据同步（外网）。也许还有很多工作要加入进来，但核心是是否能通过一个脚本的执行就全部完成所有流程，这点至关重要。如果中间多出几个环境，那将来一定会引入发布的灾难。

　　3、TDD / BDD 请对你自己写的代码负责

　　不要为了TDD/BDD而TDD/BDD，只要能及时获得自己写的代码运行情况的反馈就行，也无需一次把test case都覆盖全。对于没有任何单元测试的代码，将来想引入单位测试，将举步维艰！如果，你认为测试完全是QA的事情，那你就花大笔的钱去招聘一个规模庞大的QA集团吧，期望他们能让你偷懒。

　　4、使用靠谱的bug记录工具

　　人脑的潜力虽然无限，但大脑皮层只会对进入缓存区的数据做高效的反应。记忆再好的开发，也可能被各种牛魔鬼怪折磨的忘记了昨日的痛（曾经产生的bug）。所以，从团队第一次提测，就应该使用靠谱的bug记录工作。所谓好记性不如烂笔头就是这个道理。

　　那一个靠谱的bug记录工具应该要记录这些数据：

　　● bug复现的整个操作流程
　　● 产品需求中的正常情况
　　● 出现bug后，变成为什么情况
　　● 谁将负责修复这个bug
　　● bug最后修复没有

　　至于怎么修复的bug，是重新设计还是漏提交了代码，我觉得无关紧要。如果一个bug修复的经验值得分享，可以单独做一次团队的技术分享，而这往往是由于对现有产品的（技术或者其他的）信息获取不够导致的。

　　5、尽快修复bug

　　我的开发经验告诉我，一个bug越晚修复，被修复的可能性越小，将来产生危害的可能性越大。试想，你刚提测或者发布的代码，出现的bug，往往你能最快得到解决它需求的时间，而时间在项目管理上是非常重要的。反之，如果积累了很多bug，且有一定时间了，那修复它就需要对所有相关的系统进行了解，这将花费大量你可以用来度假，娱乐的美好时光。所以，从团队一开始就贯彻这点，可以释放成员修复bug的压力。

　　6、给团队成员一个安静的环境

　　最近很多同学告诉我，白天基本上没有什么效率，总是受到各种骚扰。我们做一个假设：假如A同学进入最佳状态需要30分钟，那么如果他比较惨，在30分钟间隔内，他总是被打断，那么他一天都无法最高效的工作。又或者同学B google查询一个技术问，花费2分钟可以解决，但问同学A只要20秒钟（好吧，同学A表达很清晰）。这样同学B节省了100秒钟，而同学A至少损失了30分钟。

　　从这个假设，我们不难发现，如果能避免团队成员受到外来信息的骚扰，他就有可能更加高效的工作，从而写出更好的产品。而常识告诉我们，人不可能一直高效的工作，所以，我们应该利用好无法集中精力的时间去进行一些沟通。但分出这个界限显然十分困难，所以我觉得不妨这样：规定每天的安静时间段，在这个时间段，其他人都不能来打扰这位同学，而在非安静时间段，可以随意访问，从而让这位同学形成一个新的生物钟（人体的自我调节能力是非常强悍的）。

　　7、给员工最好的工具

　　做同样一件事情，如果使用工具A，消耗的时间为5分钟，而使用工具B，消耗的时间为1分钟，那我一定给员工提供B工具，即使B工具的价格是A工具的5倍。因为，假如人在连续高效工作中的抵抗干扰时间为1分钟，那么意味着B工具能保证高效工作的时间连续，而A将可能分散了用户精力，导致需要更多的时间才进入最佳状态。事实上，之所以要更好的cpu，更大的内存，更好的编译器，更好的编辑器，多显示器，都是让程序员尽快能回到核心业务上来，而在等待上花费更少的时间。

　　同时，别忘了，一把好的椅子也是维持更长高效工作时间的保证，所以，别吝啬，给员工更好的椅子吧，他们会感到你的温怀。

软件测试时候发现根本没有需求，一问开发和需求，发现原来是我们的项目经理口口相传，告诉开发要怎么怎么做。

　　可想而之，这个过程是没有设计的，开发过程当中遇到问题，就会问，项目经理即时马上给出答复。

　　而到了测试，测试人员在完全不了解状况的时候，在界面上点了点，也不知道要点多少东西，反正一会告诉我说版本测试完了。我心里没底，想着版本上提到改了这么多东西，怎么马上就测试完了呢？

　　于是我抱着怀疑的态度去做测试，结果一看发现我们的系统已经大变样了。以前一个流程的三种状态变成了现在的未知种数。我傻眼了，这样怎么可能做测试呢？没有需求，无法预估到测试场景。怎样才是测试完成了？更可恨地是部门经理说测试完了没问题就上线，我的问题是怎样是测试完了，怎样是没问题呢？

　　我告诉部门经理，我无法决定是否上线，因为我不知道如何设计测试场景了，而通过我的测试，我发现了一些开发人员也无法回答的问题，于是我把所有我知道范围之内的可能造成状态不同的条件全部列出来了，要求项目经理可我填写，如果是这样的输入条件，输出是怎样的？经我这么发问，项目经理也无法填写我的结果，又推给需求去确认。当然事情暂时没有结论，现在的状态是版本暂时没有上线，我的测试我认为是没有做完的。

　　针对以上的问题，我觉得好险。测试是项目最后的一道关，如果我不能发现这些问题，上线后，客户发现了，我们如何解释呢，我们的项目经理会挺身而出帮你说话，说是因为没有需求吗？

　　如果出了问题，我对项目经理没有这样的信心。但是我越发觉得测试是多么的重要了，每次上线都是对我个人能力的考验。而这种混乱状态下，如果我不能够发问，我这个测试组的地位只会越来越低，成为别人推卸责任的那个背着黑锅的家伙。

　　这次我也发现自己在进入这个部门两个月以后的第一次反抗，前期由于不了解项目的情况，所以出这种问题也是无法察觉的。需求和开发没有文档，需求分析和设计没有做好，我的测试也只能定位比较低。但是通过这次的考验，我自己越来越多的相信，我能够做好项目的测试管理，我的测试组能够在项目过程中充当着不可或缺的角色。

　　没有需求的测试，很危险，但是我绝不是每次都要用这种方法来对付这个问题，我要告诉部门，你们前期的需求分析是否可以做得更全面一点，开发设计可以多考虑一些，不要每次把问题丢给测试，提高项目的间接成本。

　MySQL字符串的限制长度看似重要性不要，其实和整个MySQL数据库的安全性是息息相关的，很值得我们去深入研究分析。

　　SQL注入攻击一直都在被广泛的讨论，然而人们却忽略了今天我将要介绍的这两个安全隐患，那就是超长SQL查询和单列SQL字符长度限制可能会带来的问题。

　　首先我们来谈论一下超长SQL查询

　　max_packet_size

　　这个东西是用来限制mysql客户端和服务器通信数据包的长度的，比如一个查询为“select * from user where 1”，那么这个长度仅仅几十个字节，所以不会超标。在绝大多情况下，我们很难会超过mysql的默认限制1M（可以想象一下，1M的SQL语句还是很长的）。这里插一句，看到这篇文章之后，我终于清楚我当初用PEAR DB 的INSERT插入数据失败的原因了，很可能就是数据长度超标。对于MySQL来说，如果查询MySQL字符串的大小超过了这个限制，mysql将不会执行任何查询操作

　　如果访问者有可能控制你的sql长度，那么你的程序可能会受到攻击。哪些情况访问者可能控制sql的长度呢，比如不限制关键字长度的搜索。还有可能就是你的程序如果要将用户的登录作为日志启用，总之凡是涉及到超长sql查询的地方，一定得小心检查自己的sql，防止超长而查询失效。不过说实在的，本人认为这个问题倒不是多大，数据库管理员也可以自行设置MySQL的max_packet_size的长度，或者在处理可能超长的SQL查询的时候做一个长度判断。

　　MySQL列长度限制

　　这个是本文的重点。MySQL对于插入的字符串，如果长度超过了数据表限制的长度，MySQL将会截取前面部分MySQL字符串插入数据库中，而不会将错误报给web程序。对于粗心的程序员，这个问题可能会导致程序的漏洞，其实目前的wordpress有很多限制，通过这个漏洞攻击应该没有任何作用。下面是原作者的几个假设，如果同时满足这几个条件，获取一个站点的用户名是相当容易的事情，幸运的是目前的wordpress并不太可能会同时满足下面的条件：

　　该web应用允许用户注册（开放注册的wordpress满足此条件）；

　　超级管理员的用户名已知的，比如admin，这样方便攻击者寻找目标（可怜wordpress也满足）

　　MySQL使用的是默认的配置（估计大多数都满足）

　　注册新用户的时候，程序没有对用户名的长度给予限制（我测试过，wordpress也满足）

　　用户名被限制在16个字符（这个和上面的没有关系，仅仅是方便举例）

　　下面我们来看看攻击者是怎么攻击的：

　　首先攻击者用已知的超级管理员id如admin注册，那么这个时候程序就会用

　　来检查该ID是否已经存在，如果存在，这不允许注册，当然，攻击者尝试注册admin肯定会失败；

　　但是如果攻击者用 admin　X（admin和x之间有11个或以上的空格）来注册呢，按照上面的判断，由于admin x不存在数据库中，所以当然就能注册成功了，事实上wordpress2.6.1之前的版本确实可以这样，由于列长度的限制在16个字符内，所以末尾的x就被截掉了，那么现在数据库中就存在两个一模一样的用户admin了。（旁白：糟糕，那我的程序不是都要去修改。其实没有必要，你只要把ID设置为UNIQUE就可以了，于是乎，下面的问题就和你没有关系了）

　　攻击者继续，这个时候攻击者就顺利的注册了admin这个用户名，然后攻击者用admin和自己的密码登录进入账户管理（wordpress即使注册了也无法登陆），由于真正的admin的帐号先于攻击者admin注册，所以在账户信息页面，显示的信息非常有可能就是真正admin的信息，包括密码提示和email等，这个时候攻击者就可以对admin的信息进行任意修改，包括密码和密码找回。

　　所以，写web程序的你，是不是该去检查一下自己的程序是否有此类的漏洞呢。

　Equinox在创建Bundle的ClassLoader时，首先获取bundle的classpath，然后执行createBCLPrevileged方法，此方法最后转交由BaseData来创建ClassLoader。

　　BaseDate创建ClassLoader的关键代码片段为：

　　在Equinox中，默认的情况下adaptor.getBundleClassLoaderParent返回的为bootstrap classloader，可通过修改启动的osgi.parentClassLoader 来改变这个parent classloader，

　　osgi.parentClassLoader 的可选值有四个，分别是：

　　● boot：默认

　　● app：SystemClassLoader

　　● ext：SystemClassLoader的parent

　　● fwk：启动Equinox的ClassLoader

　　ClassLoadingHook在createClassLoader的时候都没有做动作，因此最后ClassLoader都是通过创建DefaultClassLoader对象来构建的，其中parent参数为null，delegate参数为BundleLoader实例，bundleclasspath参数为bundle的classpath。

　　经过以上步骤后，完成了ClassLoader的创建，可以开始加载class了，根据上面上述，Bundle的Class就由DefaultClassLoader来完成了。

　　查看DefaultClassLoader的loadClass代码，发现真正的加载class的过程是转为调用了delegate 的findClass来完成的，delegate参数对应的为BundleLoader实例，转为跟踪BundleLoader的findClass方法。

　　BundleLoader的findClass方法的代码片段：

　　从以上这个代码片段，可以看到，Equinox将java.开头的类转交给了parent classloader去加载，这也意味着没必要在系统中提供对外export java.开头的package。

　　如果不是java.开头的类，则交由findClassInternal方法来完成加载。

　　findClassInternal方法遵循的为OSGi规范中定义的Class的加载顺序，不过仍然稍有改动：

　　1）判断是否交由parent classloader去完成加载

　　在启动Equinox时，Equinox会读取org.osgi.framework.bootdelegation属性，该属性对应配置的为需要从parent classloader中加载的package，如值配置的为*，说明所有的都从parent classloader中加载 ，如值配置的为具体的package，那么则放入bootDelegation集合；如配置的为带通配符的package，那么则放入bootDelegationStems集合。

　　判断时Equinox首先判断是否所有的都从parent classloader中加载，如是则从parent classloader中加载；

　　如需要加载的类的package位于bootDelegation或bootDelegationStems集合中，那么同样从parent classloader中加载。

　　如不从parent classloader中加载，则进入下面的步骤。

　　测试工作头绪较多，专业性强，如何做好测试管理工作，特别是量化管理，提高测试效率、督促测试人员完成好测试工作，是很重要的。

　　我负责三位XXX测试人员对XXX进行测试。测试规程主要是按协议的各个要求编写的，测试规程的通过准则是测试人员根据对协议的理解、对系统的理解编写的。三位测试人员根据测试规程进行分工，分别编写、测试不同的规程。测试的平台是测试部自已开发的专用XXX测试环境。

　　前一段时间，对XXX测试如何进行管理没有一个头绪，使得XXX测试计划一再推迟，并且对实际的进展、测试的质量都不太清楚。为了加强对XXX测试的管理，并争取做到量化，进行一些尝试，并取得一定的成功。现在每天可以看到实际的测试进展，并能发现每位测试人员的进度、质量，也可以看到XXX测试结果的情况。

　　以下是我近期对测试管理的经验。

　　做好每日汇报工作

　　每日汇报工作可以与项目、部门的一些具体要求结合起来。比如，项目要求每天的测试应当有一份测试日报。测试部要求测试规程、测试结果要入到测试中心。还要求故障及时提交，并导入CQ。

　　除此之外，为了做好统计工作，我在CC上建立了一个execl的汇总文件，输入了所有的测试规程、通过准则。每天，测试人员有新增加的测试规程、通过准则，要加到该文件中；每天的测试结果，要填到该文件中。要填的内容，如果是测试规程、通过准则，是与测试中心的是一致的。测试结果只是一个通过或不通过，加上一个当天日期。这是一个非常简单的填表，并不会增加太多的工作量。

　　采用CC，可以保证汇总文件的一致性，还可以检查测试人员填写的情况，可以提取不同版本的汇总文件。这充分利用了CC的优点。

　　以下是汇总文件中的一部分：