关乎性能的思考

        现在工程师们越发的喜欢谈性能(CPU, memery, IO, container, middleware等)，性能调优似乎也成为软件行业基础架构师越来越倚重的技艺之一。通常情况下，性能shooting也无外乎分为几个过程。其一，performance diagnostic amp; bottleneck positioning，这一步往往是关键，当然手法也是千奇百怪，这
        现在工程师们越发的喜欢谈性能(CPU, memery, IO, container, middleware等)，性能调优似乎也成为软件行业基础架构师越来越倚重的技艺之一。通常情况下，性能shooting也无外乎分为几个过程。其一，performance diagnostic bottleneck positioning，这一步往往是关键，当然手法也是千奇百怪，这里不做赘述。第二，performance tuning，真正的调优过程是一个很Galileo，很Continuous的事情，当然也有一些模型，规则可以遵守。正如大伙疾呼：编码是一种艺术。在这，允许我呐喊一下：调优更是一门艺术。不过这门艺术要求还是有点高的，你不仅要有扎实的硬件基本知识，还要对诸多软件工作模式有一探到底的精气神。这里我们不谈性能调优如何艺术，更多的是想和大家分享一些性能调优后的思考（试图去完善一本性能调优沉思录）。思考过后，我们可以尝试着问问自己能不能做到性能架构，性能编码？注意，这里的性能架构，性能编码是自己发明的一个词汇，说的直白点，就是将性能更早的引入软件生命周期中来，别忘了，银行家算法是避免死锁的有效策略~
        那么，现在步入正题。首先我想分享的是使用Jmeter做DBCP的调优。调优的初衷很简单，提高TPS，同时减少数据库灾难带来的连接池exhaust（提高可用性）。第一个调优目标，是个很业务的事情，需要根据你的业务场景进行调整，策略上最值得注意的是maxIdle和minIdle两个参数，类似Java的-Xmx和-Xms的设置。剩下的一些参数调整，个人觉得没什么借鉴意义，所以就不赘述了，毕竟这是一件很业务的事情。再看另一个目标，这里我主要想说的是removeAbandoned和removeAbandonedTimeout。从软件的健壮性来讲，边界值问题尤为重要。在资源获取型编码过程中，最好的体现就是超时时间的设置，这是个很经验，很统计概率的事情。对样本空间进行充分取样，一定可以得出该样本空间样本点的均值，当然还有均方差。后者更多的在关注样本点与平均值的偏离程度。仔细体会一下Jmeter的90% Line性能指标（这只是一个很简单的数学场景，后面有机会和大家分享一篇性能调优中的数学之美的博文）。好了，话题收敛一下，我来解释一下removeAbandonedTimeout的重要性：当connection idle时间超越这个数值时, AbandonedObjectPool会在borrowObject和returnObject时会先进行连接的有效性判断。很好理解,在借出对象时，需要判断该对象是否处于活跃状态（不满足removeAbandoned条件则归还，满足需要看超时时间，然后…）；归还时的判断原则大致类同，这个很容易想到。代码如下：

/**

 * Get a db connection from the pool.

 * If removeAbandoned=true, recovers db connections which

 * have been idle removeAbandonedTimeout and

 * getNumActive() getMaxActive() - 3 and

 * getNumIdle() 2

 * @return Object jdbc Connection

 * @throws Exception if an exception occurs retrieving a 

 * connection from the pool

 public Object borrowObject() throws Exception {

 if (config != null

 config.getRemoveAbandoned()

 (getNumIdle() 2)

 (getNumActive() getMaxActive() - 3) ) {

 removeAbandoned();

 Object obj = super.borrowObject();

 if (obj instanceof AbandonedTrace) {

 ((AbandonedTrace) obj).setStackTrace();

 if (obj != null config != null config.getRemoveAbandoned()) {

 synchronized (trace) {

 trace.add(obj);

 return obj;

 * Return a db connection to the pool.

 * @param obj db Connection to return

 * @throws Exception if an exception occurs returning the connection

 * to the pool

 public void returnObject(Object obj) throws Exception {

 if (config != null config.getRemoveAbandoned()) {

 synchronized (trace) {

 boolean foundObject = trace.remove(obj);

 if (!foundObject) {

 return; // This connection has already been invalidated. Stop now.

 super.returnObject(obj);

 }

        通过分析，压测，调整参数验证，我们达到了优化目标（主要是基于以上参数的调整）。而后，我们需要认真反思一下：在拿到一款开源软件并成功run起来，进入到production环境前，是不是需要做点啥？每依赖一个新Jar包，就压测一通，是不是很没章法，显得？能不能理论指导实践一下呢？我的回答是当然可以，但需要仔细研读一下关乎性能的相关参数说明。当然，哪些会成为你着重关注的性能参数，这又是一个很经验的事情。再举个例子，之前做过几个Connection调优的事情，问题定位到最后，发现两边的Connection timeout设置的不具备“包容性”。具体来说，在Tomcat的AJP connector和apache的mod_jk connector pipe对接时，处于请求响应数据流向的AJP connector端的timeout是不是可以大于等于mod_Jk counterpart呢？试想一下，倘若前者过小，当连接数大于connection_pool_minsize，并且connection_pool_timeout 超时，mod_jk会主动断开连接。而Tomcat 这边只要到了connectionTimeout超时时间，就会立即放弃连接。这就导致了mod_jk 继续持有连接，而Tomcat这边却放弃了这条连接。后果很严重吧（不作不死的Timewait问题）？为了更形象点，我还是把关键配置项摘录下来吧：
workers.properties:

worker.node1.connection_pool_minsize=25

worker.node1.connection_pool_timeout=600

server.xml :

 Connector port="8009" address="${jboss.bind.address}" protocol="AJP/1.3" emptySessionPath="true" enableLookups="false" redirectPort="8443" URIEncoding="UTF-8" backlog="256" maxThreads="250" connectionTimeout="600000"/ 

         Hmm，既然已经注意到了这点，我们就可以把Tomcat的connectionTimeout调得比较大，让它完全包容mod_Jk counterpart，又或者把mod_jk的connection_pool_minsize 设成0，再或者在mod_jk中设置worker.node1.prepost_timeout=10000 ，通过断开死连接的方式，都是可以解决这个问题的。写到这，忽然想起之前封装的那个高性能的HttpClient。为什么我敢“吹牛”它是高性能呢？原因很简单，Apache的性能参数之前我们已经进行了调优(通过分析日志统计出连续HTTP请求出现的次数、间隔时间、访问量， 以确定 MaxKeepAliveRequests 和 KeepAliveTimeout 的值。说到这里，我有必要提醒大家注意一下Timeout和KeepAliveTimeout的区别，用两段官方的解释说明一下吧，个人觉得很贴切：

The TimeOut directive currently defines the amount of time Apache will wait for three things: 

1. The total amount of time it takes to receive a GET request. 
2. The amount of time between receipt of TCP packets on a POST or PUT request. 
3. The amount of time between ACKs on transmissions of TCP packets in responses. 

The number of seconds Apache will wait for a subsequent request before closing the connection.Once a request has been received, the timeout value specified by the Timeout directive applies. 

)，那么我封装HttpClient的时候，只需要对接apache的MPM参数（具体可参看：http://blog.csdn.net/fengjia10/article/details/7315279），那么在设计，编码阶段就可以解决大部分性能问题，剩下的就是根据业务场景稍作调优即可。

小结: 

通过这篇博客，我想说的是，作为职业架构师，我们不仅要读的通源码，玩得起perf tool（分析问题，解决问题），更需要的是将你的优化意识尽可能早的引入到软件的研发周期中（根据以往的经验，过早考虑性能，也可能会导致代码晦涩难懂。建议在设计中作为非功能需求考量，并在代码的优化阶段（也可能是提测后）实施性能调优），即架构设计，甚至是基础代码的编写过程中。尽可能的运用数学模型去验证你的性能参数选择。请牢牢记住：意识永远比技术更重要。

参考资料：

1. http://commons.apache.org/dbcp/configuration.html

2. http://software.intel.com/zh-cn/articles/book-Multicore-Multithread-Technology_tuning_cycle/

认清性能问题 首先专注于业务上最需要优先修正的程序，而不是从全局调优来改善性能。要重视全局的性能表现，但解决问题要从细节和业务最需要的环节入手。
网站运营中最为基本的因素是哪些？要注意什么？ 网站运营是一个贯穿网站始末的过程中，对于运营站长而言，运营的开始并非是从网站正式上线，开始使用为起点，而是从最初网站策划就已经开始。网站前期的策划，定位，布局对于网站后期运营起到决定性的作用，其中任何一个环节出现错误，后期采用再完美的运营手段都无法补救，注定运营以失败结束。 在网站运营时，除了上述 span "feed-item-img" target="_blank" href="https://developer.aliyun.com/article/747552">
优秀程序员是如何突破瓶颈的？ 程序员是一群，智商极高，人品善良，思维逻辑缜密，收入挺高，交友不多，生活圈子比较小而且单纯，都是一批可爱的人，但是他们不善言谈，不善交际。到了一定的年龄和级别后，都很难突破自己的瓶颈。
三叉戟核武系统扛不住网络攻击 解决之道在于投入成本 本文讲的是 三叉戟核武系统扛不住网络攻击 解决之道在于投入成本，英国首相大卫·卡梅伦曾表示，三叉戟核武是英国作为一个主权国家的终极保险策略。但有人对此不以为然。