项目性能优化参数配置汇总

nginx（在nginx.conf配置文件里面）

1. worker_processes：启动进程，跟CPU核数相同。
2. worker_connections：单个进程的最大并发数，所以nginx的最大并发数即worker_processes*worker_connections。

tomcat（server.xml）

1. protocol：服务器协议，目前我们使用的是Http11AprProtocol协议，经测试会比tomcat自带的bio和nio性能都要好。
2. minProcessors：服务器启动时创建的处理请求的线程数量。
3. maxProcessors：最大可以创建的处理请求的线程数量。
4. acceptCount：当没有空闲的请求线程时可以放到处理队列中的请求数量。

redis（redis.windows.conf）

1. 如果要查看redis现在的连接数，内存使用等信息，可以到redis的文件夹下面的redis-cli.exe，双击，然后输入info即可看到redis目前的使用情况，便于做监控。
2. timeout：客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能。
3. maxclients：最大连接数，尽量貌似不要超过30000,不过如果设置为0，就不做任何限制，不过一般不这么设置，容易把服务器搞挂。
4. maxmemory：可使用的最大内存容量，一般不作设置。

数据源（jtconfig-datasources.xml）：目前我们使用的是阿里巴巴的Druid

1. initialSize：初始化时建立物理连接的个数。
2. maxActive：最大并发连接数。
3. minIdle：最小连接池数量 。
4. maxWait：获取连接时最大等待时间，单位毫秒。配置了maxWait之后， 缺省启用公平锁，并发效率会有所下降， 如果需要可以通过配置useUnfairLock属性为true使用非公平锁。
5. poolPreparedStatements：是否缓存preparedStatement，也就是PSCache。 PSCache对支持游标的数据库性能提升巨大。
6. maxOpenPreparedStatements：要启用PSCache，必须配置大于0，当大于0时，poolPreparedStatements自动触发修改为true。在Druid中，不会存在PSCache占用内存过多的问题， 可以把这个数值配置大一些，比如说100。
7. validationQuery：用来检测连接是否有效的sql，要求是一个查询语句，如select 1。
8. testOnBorrow：申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
9. testOnReturn：归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
10. testWhileIdle：建议配置为true，不影响性能，并且保证安全性。 申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis， 执行validationQuery检测连接是否有效。
11. timeBetweenEvictionRunsMillis：配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒
12. minEvictableIdleTimeMillis：配置一个连接在池中最小生存的时间，单位是毫秒。

mysql（windows是my.ini）

1. 查询缓存相关参数
   
   • show status like ‘Qcache’，可以计算查询缓存命中率=Qcache_hits/(Qcache_hits + Qcache_inserts)。
   • query_cache_type=1：缓存类型，0表示关闭QC；1表示正常缓存；2表示SQL_CACHE才缓存。
   • query_cache_size=2024M：cache的大小，设置成0不缓存。
   • query_cache_limit=16M：不缓存查询大于该值的结果，默认1MB。
   • query_cache_min_res_unit=2K：查询缓存分配的最小块大小，默认2K。
2. 连接数
   
   • max_conecctions=800：最大并发数，网上建议设置500~800之间。
   • back_log=200：在MySQL的连接请求等待队列中允许存放的最大连接请求数。
3. 网络传输
   
   • net_buffer_length=16384：主要可能影响的是网络传输的效率，由于该参数所设置的只是消息缓冲区的初始化大小，所以造成的影响主要是当每次的消息都很大时，MySQL总是须要多次申请扩展该缓冲区的大小。
   • max_allowed_packet=64M：在网络传输中，一次消息传输量的最大值。
4. 线程池
   
   • show variables like ‘thread%’，查看线程池的配置。
   • show status like ‘%thread%’。
   • show status like ‘connections’，查看启动到目前接收的客户端连接。
   • Thread Cache命中率 = (Connections - Threads_created) / Connections * 100%，一般需要保持在90%以上才算正常。
   • thread_cache_size=64：线程池大小，一般建议50~100，根据物理内存设置规则：1G=8；2G=16；3G=32；大于3G=64。
   • thread_stack=192K：每个线程的堆栈大小，一般用默认即可，默认192K。
   • thread_concurrency=8：同时运行的线程的数据 此处最好为CPU个数两倍。
5. Table Cache
   
   • show variables like ‘table_open_cache’。
   • show status like ‘open_tables’。
   • table_open_cache=2000：所有线程打开的表的数目。增大该值可以增加mysqld需要的文件描述符的数量。
6. Buffer，基本都是线程级别，所以不宜设置过大
   
   • show variables like ‘%buffer%’，各种buffer的配置。
   • join_buffer_size=8M：join buffer大小，一般建议1~2M。
   • sort_buffer_size=4M：系统中对数据进行排序时使用的Buffer，可以提高ORDER BY或者GROUP BY的处理性能。一般建议2~4M，若数据较大，可以适当加大。
7. MyISAM存储引擎
   
   • 仅缓存索引数据，并不会缓存实际的表数据信息到内存中，会降这一工作交给OS级别的文件系统缓存。所以索引缓存的优化是关键。
   • SHOW STATUS LIKE ‘key%’; 获取索引缓存的使用状态，可以计算出索引缓存大小是否设置得合适。
   • Key_Buffer_Read_HitRatio = (Key_reads/Key_read_requests) * 100% 。
   • 一共有key_read_requests个索引请求，一共发生了key_reads次物理IO, 在0.1以下比较好，太高则很有可能是key_buffer_size设置过小。
   • key_buffer_size=256M：索引缓存大小，建议不要超过4G，所有线程共享的全局缓存。
   • read_buffer_size=2M：以全表扫描(Sequential Scan)方式扫描数据的buffer大小 ；线程级别。
   • read_rnd_buffer_size=8M：以索引扫描(Random Scan)方式扫描数据的buffer大小 ；线程级别，适当调大，对提高ORDER BY操作的性能有一定的效果。
   • concurrent_insert=2：当系统写入操作较多时，提高INSERT操作和SELECT之间的并发处理，使二者尽可能并行。
8. InnoDB存储引擎
   
   • 与MyISAM的主要区别：缓存机制、事务支持、锁定实现、数据存储方式。
   • show status like ‘Innodb_buffer_pool_%’; 获取innodb的buffer的使用情况，可以计算出buffer的使用率，read命中率，write命中率等等。
   • buffer的使用率 = Innodb_buffer_pool_pages_data/Innodb_buffer_pool_pages_total * 100。
   • read命中率 = (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100。
   • innodb_buffer_pool_size=2G：最主要的Buffer，缓存索引数据和实际的表数据的最主要缓存空间，对InnoDB整体性能影响也最大。针对专用服务器，一般设置为服务器内存的70~80%。计算公式 = 服务器物理内存 - 系统预留使用(800M) - 最大连接数 * (其他线程级别的buffer的总和，如sort_buffer_size、join_buffer_size…)。
   • InnoDB在修改数据的时候只是修改BufferPool中的数据，并不是在一个事务提交的时候就将BufferPool中被修改的数据同步到磁盘，而是通过另外一种支持事务的数据库系统常用的手段，将修改信息记录到相应的事务日志中。
   • innodb_log_buffer_size=8M：事物日志缓存，提高写Log的IO性能。与InnoDB的整体IO性能有非常大的关系。从理论上讲，日志文件越大，Buffer Pool所需的刷新动作也就越少，性能也越高。
   • innodb_flush_log_at_trx_commit=1：通知系统什么情况下该通知文件系统刷新缓存中的数据到磁盘文件。0:每隔1秒刷新一次，1:每次事务提交都刷新，默认设置，2:仅写入日志缓存，不确定什么时候刷新，效率最高。
   • innodb_thread_concurrency=16：并发线程数量
9. 每个InnoDB表都会将主键以聚簇索引的形式创建。所有的数据都以主键升序排列在物理磁盘上面，所以主键查询并且以主键排序的查询效率也会非常高。
   
   • 聚簇索引：并不是一种单独的索引类型，而是一种数据存储方式。innoddb的聚簇索引实际上在同一个结构中保存了B-Tree索引和数据行。当表有聚簇索引时，它的数据实际上存放在索引的叶子页（leaf page）中，在一个表中只能有一个聚簇索引。其他索引成为二级索引。
   • 二级索引（非聚簇索引）：二级索引定位数据时需要两次索引查找，因为二级索引叶子节点保存的是数据行的主键值，然后根据这个值去聚簇索引找到对应的行。这里做了重复的工作：两次B-Tree查找，而不是一次。对于InnoDB，自适应哈希索引能够减少这样重复工作。
   • 聚簇索引的缺点：最大问题就是索引键被更新造成的成本并不只是索引数据可能会移动，而是相关的所有记录数据都须要移动。所以，为了性能考虑，尽可能不要更新InnoDB的主键值。