关乎性能的思考
2012-11-27 19:22
239 查看
现在工程师们越发的喜欢谈性能(CPU, memery, IO, container, middleware等)，性能调优似乎也成为软件行业基础架构师越来越倚重的技艺之一。通常情况下，性能shooting也无外乎分为几个过程。其一，performance 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条件则归还，满足需要看超时时间，然后…）；归还时的判断原则大致类同，这个很容易想到。代码如下：
[java] view
plaincopy
/**
* 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设置的不具备“包容性”。Hmm，具体来说，在Tomcat的AJP connector和apache的mod_jk connector pipe对接时，处于数据流向的AJP connector的timout是不是可以大于等于mod_Jk counterpart呢？试想一下，倘若前者过小，当连接数大于connection_pool_minsize，并且connection_pool_timeout 超时，mod_jk会断开连接。而Tomcat 这边只要到了connectionTimeout超时时间，就会立即放弃连接。这就导致了mod_jk
继续持有连接，而Tomcat这边却放弃了这条连接。后果很严重吧？为了更形象点，我还是把关键配置项摘录下来吧：
workers.properties:
[html] view
plaincopy
worker.node1.connection_pool_minsize=25
worker.node1.connection_pool_timeout=600
server.xml :
[html] view
plaincopy
<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参数（具体可参看：/article/8925472.html），那么在设计，编码阶段就可以解决大部分性能问题，剩下的就是根据业务场景稍作调优即可。
小结:
通过这篇博客，我想说的是，作为职业架构师，我们不仅要读的通源码，玩得起perf tool（分析问题，解决问题），更需要的是将你的优化意识尽可能早的引入到软件的研发周期中，即架构设计，甚至是基础代码的编写过程中。尽可能的运用数学模型去验证你的性能参数选择。请牢牢记住：意识永远比技术更重要。
tuning，真正的调优过程是一个很Galileo，很Continuous的事情，当然也有一些模型，规则可以遵守。正如大伙疾呼：编码是一种艺术。在这，允许我呐喊一下：调优更是一门艺术。不过这门艺术要求还是有点高的，你不仅要有扎实的硬件基本知识，还要对诸多软件工作模式有一探到底的精气神。这里我们不谈性能调优如何艺术，更多的是想和大家分享一些性能调优后的思考（试图去完善一本性能调优沉思录）。思考过后，我们可以尝试着问问自己能不能做到性能架构，性能编码？注意，这里的性能架构，性能编码是自己发明的一个词汇，说的直白点，就是将性能更早的引入软件生命周期中来，别忘了，银行家算法是避免死锁的有效策略~
那么，现在步入正题。首先我想分享的是使用Jmeter做DBCP的调优。调优的初衷很简单，提高TPS，同时减少数据库灾难带来的连接池exhaust（提高可用性）。第一个调优目标，是个很业务的事情，需要根据你的业务场景进行调整，策略上最值得注意的是maxIdle和minIdle两个参数，类似Java的-Xmx和-Xms的设置。剩下的一些参数调整，个人觉得没什么借鉴意义，所以就不赘述了，毕竟这是一件很业务的事情。再看另一个目标，这里我主要想说的是removeAbandoned和removeAbandonedTimeout。从软件的健壮性来讲，边界值问题尤为重要。在资源获取型编码过程中，最好的体现就是超时时间的设置，这是个很经验，很统计概率的事情。对样本空间进行充分取样，一定可以得出该样本空间样本点的均值，当然还有均方差。后者更多的在关注样本点与平均值的偏离程度。仔细体会一下Jmeter的90%
Line性能指标（这只是一个很简单的数学场景，后面有机会和大家分享一篇性能调优中的数学之美的博文）。好了，话题收敛一下，我来解释一下removeAbandonedTimeout的重要性：当connection idle时间超越这个数值时, AbandonedObjectPool会在borrowObject和returnObject时会先进行连接的有效性判断。很好理解,在借出对象时，需要判断该对象是否处于活跃状态（不满足removeAbandoned条件则归还，满足需要看超时时间，然后…）；归还时的判断原则大致类同，这个很容易想到。代码如下：
[java] view
plaincopy
/**
* 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设置的不具备“包容性”。Hmm，具体来说，在Tomcat的AJP connector和apache的mod_jk connector pipe对接时，处于数据流向的AJP connector的timout是不是可以大于等于mod_Jk counterpart呢？试想一下，倘若前者过小，当连接数大于connection_pool_minsize，并且connection_pool_timeout 超时，mod_jk会断开连接。而Tomcat 这边只要到了connectionTimeout超时时间，就会立即放弃连接。这就导致了mod_jk
继续持有连接，而Tomcat这边却放弃了这条连接。后果很严重吧？为了更形象点，我还是把关键配置项摘录下来吧：
workers.properties:
[html] view
plaincopy
worker.node1.connection_pool_minsize=25
worker.node1.connection_pool_timeout=600
server.xml :
[html] view
plaincopy
<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参数（具体可参看：/article/8925472.html），那么在设计，编码阶段就可以解决大部分性能问题，剩下的就是根据业务场景稍作调优即可。
小结:
通过这篇博客，我想说的是，作为职业架构师，我们不仅要读的通源码，玩得起perf tool（分析问题，解决问题），更需要的是将你的优化意识尽可能早的引入到软件的研发周期中，即架构设计，甚至是基础代码的编写过程中。尽可能的运用数学模型去验证你的性能参数选择。请牢牢记住：意识永远比技术更重要。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 关乎性能的思考
- 密码学 性能的一些思考
- 对提高HBase写性能的一些思考
- Linux服务器程序性能测试的一些思考
- 对提高HBase写性能的一些思考
- 关于ssdb性能方面的一些思考
- Android APP 性能优化的一些思考
- 系统的思考性能问题
- 关于NoSQL的思考：为什么我们要优化存储的写性能
- [转]关于NoSQL的思考：为什么我们要优化存储的写性能
- 游戏服务器程序的性能思考
- 腾讯高级工程师：一道面试题引发的高并发性能调试思考
- 关于NoSQL的思考-为什么我们要优化存储的写性能？
- 腾讯高级工程师：一道面试题引发的高并发性能调试思考
- 【分享】（性能优化）思考数据列表中“特殊的列”
- 按分类统计商品总数的性能优化思考
- 系统的思考性能问题
- [置顶] 关于web性能的思考与分享［06］——【原创】fis3构建工具使用教程（01）
- live555库的性能思考粗略（一）
- 关于NoSQL的思考：为什么我们要优化存储的写性能 .