百万记录级MySQL数据库及Discuz!论坛优化

最近，帮一个朋友优化一个拥有20万主题，100万帖子，3万多会员，平均在线人数2000人的Discuz!论坛，采用 Linux2.6+Apache2+mod_php5+MySQL5，服务器配置为双至强+4G内存，优化前，系统平均负载（load average）基本维持在10以上，MySQL的CPU占用率基本在90%以上，优化后，系统平均负载降到0.5以下，MySQL的CPU占用率很少有 超过10%的时候。优化前YSlow得分只有35分，优化后YSlow得分86分。现将优化的过程和经验做一个记录： 首先，对Apache进行优化，编辑httpd.conf，设置 HostnameLookups、KeepAlive、MaxKeepAliveRequests以及KeepAliveTimeout四个参数，调整 MaxSpareServers、ServerLimit、MaxClients以及MaxRequestsPerChild参数，还可以考虑弃用 prefork而采用worker MPM。设置mod_deflate及mod_expires模块，不过注意Discuz!不能对PHP文件开启Expires，否则会出现问题。另外还 可以考虑开启mod_cache和mod_mem_cache模块。另外利用cronolog按天对日志进行轮循截断，如果日志特别大，也可以按小时截 断。另外再加上Awstats对日志进行分析，并用gzip对日志进行压缩，自动删除1个月前的日志。 其次，对PHP进行优化，编辑php.ini，调整output_buffering、zlib.output_compression及 max_execution_time、max_input_time、memory_limit等参数，并安装Xcache和Zend Optimizer。 然后对MySQL进行优化。首先重新静态编译MySQL，使其只支持MyISAM和Memory两种引擎，并按Discuz!编码选择只支持 UTF-8或者GBK字符集。编辑my.cnf，设置skip-locking、skip-external-locking、skip- networking和skip-name-resolve，根据内存和数据库状态具体调整key_buffer_size、 query_cache_size、query_cache_limit、max_allowed_packet、table_cache、 thread_cache_size、sort_buffer_size、read_buffer_size、 read_rnd_buffer_size、join_buffer_size、tmp_table_size、max_tmp_tables、 back_log、max_connections、wait_timeout的参数。 对数据库进行优化，将threads和posts表中部分未索引的字段增加索引，并将supersite数据库表从bbs数据库独立出去。修改discuz!配置文件，设置开启pconnect。 对Discuz！设置进行优化。进入Discuz!系统设置，修改页面缓存设置中的缓存有效期和缓存系数，修改服务器优化中的禁止浏览器缓冲和页面 Gzip压缩，修改防盗链设置中下载附件来路检查，用JSMin自动对js文件进行缩减（Discuz! 6.1的common.js原文件29.3k，经JSMin缩减后为24.1k，再经deflate后为7.3k），修改attachments.php 文件，将： //dheader('Cache-control: max-age=31536000'); //dheader('Expires: '.gmdate('D, d M Y H:i:s', $timestamp + 31536000).' GMT'); 前的注释去掉。修改模板目录下adv.htm，去掉与Insenz有关的代码。 通过查看MySQL的status，可以看出优化后，长时间运行的Key_read_ratio基本保持在0.05%以 下，Threads_cache_hitrate保持在99.9%以上。个人感觉，Discuz!将Session保存在数据库中，极大地降低了 Query Cache的命中率，如果需要进一步优化，可以考虑修改Discuz!源码，将Session保存到Memcache中。 优化之后用Siege做并发压力测试，在200并发下，基本没有任何错误。如果将来人数更多，可以考虑将平台迁移到Ngix+PHP FastCGI上。 下面是用Siege在300并发下的测试结果： #siege -c 300 -b -r 35 -f bbs.url ** SIEGE 2.67 ** Preparing 300 concurrent users for battle. The server is now under siege.. done. Transactions: 10500 hits Availability: 100.00 % Elapsed time: 52.68 secs Data transferred: 65.67 MB Response time: 1.27 secs Transaction rate: 199.32 trans/sec Throughput: 1.25 MB/sec Concurrency: 253.07 Successful transactions: 10500 Failed transactions: 0 Longest transaction: 24.88 Shortest transaction: 0.00 500并发下的测试结果： #siege -c 500 -b -r 20 -f bbs.url ** SIEGE 2.67 ** Preparing 300 concurrent users for battle. The server is now under siege.. done. Transactions: 9979 hits Availability: 99.79 % Elapsed time: 86.52 secs Data transferred: 82.66 MB Response time: 3.30 secs Transaction rate: 115.34 trans/sec Throughput: 0.96 MB/sec Concurrency: 381.07 Successful transactions: 9979 Failed transactions: 21 Longest transaction: 34.80 Shortest transaction: 0.00 昨天，将服务器迁移到了Nginx+php-fpm，以下是迁移后测试，相差真的很明显，回头再写Nginx+php-fpm的经验： [root@bbs ~]# siege -c 300 -r 50 -f bbs.url ** SIEGE 2.67 ** Preparing 300 concurrent users for battle. The server is now under siege.. done. Transactions: 15000 hits Availability: 100.00 % Elapsed time: 64.12 secs Data transferred: 67.79 MB Response time: 0.55 secs Transaction rate: 233.94 trans/sec Throughput: 1.06 MB/sec Concurrency: 128.95 Successful transactions: 14976 Failed transactions: 0 Longest transaction: 3.96 Shortest transaction: 0.00 [root@bbs ~]# siege -c 500 -r 50 -f bbs.url ** SIEGE 2.67 ** Preparing 500 concurrent users for battle. The server is now under siege.. done. Transactions: 25000 hits Availability: 100.00 % Elapsed time: 65.52 secs Data transferred: 83.65 MB Response time: 0.57 secs Transaction rate: 381.56 trans/sec Throughput: 1.28 MB/sec Concurrency: 216.02 Successful transactions: 21707 Failed transactions: 0 Longest transaction: 5.83 Shortest transaction: 0.00