正文
跟踪web服务器业务日志，发现在数据库更新层报请求不到新的数据库连接或者数据库连接已经用完，认为是数据库的最大连接数太小，于是调整mysql数据库最大连接数为以往的3倍；下次抢标的时候继续观察业务日志，发现已经不报数据库链接的相关错误了，但还是很多用户反馈抢标时候打不开页面。
继续跟踪web服务器，在抢标时使用命令（ps -ef|grep httpd|wc -l）查看httpd得连接数有1千左右，随机查看apache配置文件中设置的最大连接数为1024（apache默认的最大连接数为256），原来抢标期间连接数已经到达最大连接数，很多用户在抢标的过程中已经获取不到http连接导致页面无响应或者app一直在等待中。于是调整apache配置文件中的最大连接数为1024*3。
在抢标过程中继续观察，apache的连接数在抢标的时候仍然可以飙到2600-2800之间，根据客服反馈，仍然有很多用户反馈抢标的问题，但比之前稍微好一点，但是有零星的用户反馈已经抢到标的，最后又给回退了。然后继续观察数据库服务器，使用top命令和MySQLWorkbench查看mysql主库和从库的各项负载吓一跳（如下图），mysql服务器主库的各项指标均已经达到峰值，而从库几乎没有太大压力。
跟踪代码发现，三端的业务代码全部连接主库，从库只有后台的查询业务在使用，于是立刻启动改造；将除过抢标过程中的查询外，其它页面或者业务的所有查询改造为查询从库，改造之后观察，发现主库的压力明显减少，从库的压力开始上来了。如下图：
根据客服的反馈，改造之后抢到标回退的问题几乎没有了，抢标过程中页面打不开或者打开慢的问题有一定的缓解但仍有部分用户反馈此问题，根据上面各项目分析结果得出：
-
1 负载的两台服务器均已经达到处理的极限，需要配置更多的服务器来负载。
-
2 mysql主库的压力明显减少，但是从库的压力却上去了，需要将现在的一主一从已从改为一主多从的模式。
-
3 彻底解决这些问题，需要综合考虑平台的整体优化，如：业务优化（去掉业务中热点）、增加缓存、部分页面静态化（可以使用雅虎和谷歌的前端优化规则，网上也有很多的测试网站可以评测）等等。
当时根据这些情况写了一份优化的报告,见下文：
优化报告
1 背景
随着公司业务不断发展，业务量和用户量的激增，官网pv也从最初的xxx-xxx到现在的xxx-xxxx，APP活跃用户更是大幅增加；因此也对平台目前的技术架构有了更大的挑战。特别是近期平台标源紧张的情况下，满标的时间更是越来越短。服务器的压力也越来越大；因此需要升级目前的系统架构，以支持更大的用户量和业务量。
