项目性能调优

web容器调优

JVM 参数调优
1：使用64位JDK 1.6+ & Tomcat 6+。
2：jvm内存优化
编辑tomcat/bin/目录下catalina.bat（linux为catalina.sh，配置类似，请自行百度），在文件开头加上以下代码(注意先搜索一下，不要重复设置)
set JAVA_OPTS=-Xms512m -Xmx4096m -XX:PermSize=128m -XX:MaxPermSize=256m
以上配置相对简陋，含义为：
堆内存最小512M，最大4G，非堆内存最小128M，最大256M，对于系统规模小、访问量不大的项目可酌情将-Xmx4096m设置为-Xmx2048m(2G)；
内存参数的设置没有定论，要根据自己项目的运行环境、访问量、代码逻辑等做个性化调整。
官方文档及jvm系列中文博客link奉上，望君细细品。

3：深度优化
对于访问量较大，集成比较复杂的系统，需要利用JDK中的内存分析工具，分析内存的变化情况（一般是在生产环境中分析实际内存使用情况）,并酌情修改内存参数，
如将堆内存的最大值设置为-Xmx8000m，一般最大值不超过系统内存的2/3；调整新生代、老年代的比例等
常用的分析工具有JDK bin目录中的jconsole.exe 或 jvisualvm.exe，如不会使用请自行百度

HTTP 连接数调优

编辑tomcat/conf/目录下server.xml，在访问端口对应的中增加和连接数相关的属性：
minSpareThreads：最小空闲连接线程数，默认值10
maxSpareThreads（Tomcat6之前的版本有一个maxSpareThreads参数，但是在7中已经移除了）:最大空闲连接线程数，
maxThreads：最大连接线程数，并发处理的最大请求数，默认值200
acceptCount：等待队列，指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值为100
connectionTimeout:请求超时时间，默认是20秒
推荐配置tomcat7：

注1：并发能力问题涉及整个系统物理环境、架构和业务逻辑，要根据情况动态调整，web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右
注2：可以启用http连接线程池Executor ，但使用Executor是否会提升tomcat压测性能，笔者尚持保留态度。
其他属性配置参考官方文档

数据库调优

1：连接数调优
对于Oracle数据库，默认最大连接数为150，可通过下面的SQL来查询和修改（DB2 9.7+、MS SQL SERVER 2008+默认不限制连接数）

2：索引
索引是什么？请百度
索引的性能提高测试，请点这里.
建立索引的一般规则：

2.1为查询条件中的字段建立索引，通常这些字段应该为状态值等字典字段或日期字段
2.2仅左like（‘xx%’）查询会使用索引，其他like(’%xx%‘或’%xx’)查询不会使用索引
2.3索引并不是越多越好，索引会降低插入和更新的速度，因为当insert或Update的时候要更新索引
2.4巧用唯一索引，确保数据的唯一性
3.分区分表
什么是分区、分表，请自行百度。

3.1：只有针对大表，分区分表才有意义；一般大表是指记录数在百万级的，至少也是几十万；否则请考虑其他优化方式
3.2：相对而言，优先考虑分区，因为分表需要修改代码逻辑
3.3：常用的分区一般为范围分区和列表分区
4.连接池调优
无论是JNDI数据源，还是DBCP连接池，都有一些链接池参数，这些参数的设置参考如下：

*

功能优化

从功能设计上，避免一次性加载大量数据。遇到一次性加载大量数据的，通过以下问题寻找功能优化方式：

1:设置默认查询条件，仅加载部分数据。如对于监测数据的查询分析，可默认仅查询当天或当月的数据；
2:将数据展示使用类似TAB的元素分开，根据用户操作，采用AJAX分步加载数据
3:实时性要求不高的数据，不要实时查询，可使用缓存或者放到Session中

代码调优

SQL优化
尽量使用join，不要使用子查询
可能的情况下，尽量使用UNION ALL来代替UNION
请补充。。
小窍门：
可使用PL/SQL 或者 SQL Server Management Studio查看SQL的执行计划，进而对SQL进行优化。
缓存的使用
关于EhCache的使用，请移步这里
耗时操作的处理
需求：对某事项进行审批，审批通过后发邮件给提交人。
发邮件即为一个耗时操作，如果审批通过后，在当前线程中执行发邮件的操作，则会阻塞当前线程，直到邮件发送结束。

经验分享:

耗时操作可以启动一个新的线程执行，避免阻塞当前线程(request)。
或者将耗时操作仅仅设置一个未执行的状态，后台跑一个QZ任务,定时批量执行。
代码逻辑调优
1：避免for 多层嵌套
2：避免对大数组的迭代对比，考虑使用Arrays.binarySearch()

静态资源优化

文件大小
静态文件优化主要是指对文件大小的优化。
文件大小往往被很多开发人员忽略，但对于带宽有限（公网项目）或者硬件设备（主要是交换机）老旧的环境，文件大小往往是性能的最大瓶颈。
试想一个index.action，所有文件通过浏览器另存之后大小为3M，则100并发，就需要3*100 = 300M的瞬时流量，需要300 * 8 = 2.4Gbps的带宽才能在1秒内下载完毕(粗算，不科学)。

1：不要引用重复的、没必要的js、css文件
2：对于js、css文件较大的，需要压缩
3：不要使用>100K的图片
启用GZIP压缩
Tomcat 和 Nginx 都可以启用GZIP压缩，配置方式请自行百度，很简单。
需要强调的一点是，体量过小的文件不要压缩，压缩之后有可能变大，笔者一般设置>8k的文件再压缩，这个界限是否为最优值目前还未知
compressionMinSize=“8192”
配置静态文件缓存策略
这一点对于压力测试无任何帮助，因为压测工具会强制刷新所有静态资源。但对于生产环境实际用户使用来说，可以节省带宽，提高响应速度。
Tomcat目前未找到此项配置，Nginx可以做静态资源缓存策略，请自行百度。

网络优化

测试环境的网络拓扑
需求：某外网系统首页要求满足100用户并发访问，响应时间<3秒，此首页所有资源文件的总大小为1.5M（浏览器另存）。
如果测试工程师在自己家里的电脑上用LoadRunner测试，或者在公司的内网环境下测试，均不能达标，为什么？
因为家庭带宽一般<20Mbps，且一般家庭都采用了一些家用路由，如TP-link xx型号等，公司内网环境同样有层层交换机(设备)，而且出口众多(分流很大)，
造成LoadRunner测试机本身的带宽不够，无法承受接收100个用户的并发流量模拟。
结论：
LoadRunner对程序本身的性能测试最好将测试客户机同服务器直接连接在一个企业级交换机上，排除网络因素。

带宽问题

参见上述静态文件大小、测试环境的网络拓扑，得出结论：
带宽很重要。要做压力测试，首选将测试机同服务器直连到同一个企业级交换机（千兆以上）上。
带宽测试工具iPerf,此为软件工具，测量有偏差，但对我们来说应该足够了。

服务器性能

CPU占用过高问题排查
1：因为程序问题造成的CPU占用率居高不下。（由于文件无法上传，如有需要CPU居高不下排查方法及工具，可以私信找我要文档工具）
2：排查cpu占用过高造成的原因，可定位到方法级别，工具：visualvm

防抓取过滤器

程序代码可以私信找我

js压缩小工具

项目中有时候为了优化性能，就可能需要对引用的js进行压缩处理，这里介绍一个js压缩小工具grunt。无法上传文档，使用还请自行百度。