6.2、服务端优化
一般核心页面都要求在300毫秒以下，非核心页面要求在500毫秒以下，同时重点关注并发时的负载和稳定，服务器端代码和响应的快速稳定是整个页面性能的重点。
6.2.1、脚本编写及场景构造
根据前期需求评估的内容，客户是一个门户网站，主要由不同功能页面组成的，各个功能页面当中又包含了静态内容和异步动态请求，所以，性能测试的脚本的编写主要涵盖了各页面的请求和相关静态资源的请求，这里存在一个串行和并行的概念：
串行：请求的页面和页面当中的静态资源、异步动态请求组成一个同步请求，每一个内容都作为一个事务（也可以共同组成一个事务，分开事务的好处是可以统计各部分的响应时间），这样压测任务执行时，线程就会根据事物的顺序分布调用执行，相当于一个页面的顺序加载，弊端是无法模拟实际IE的小范围并发，但这样测试的结果是最严格的。
并行：各个页面之前可以使用不同的任务，采用并行的混合场景执行，同时设置一定的比例（并发用户数），保证服务器承受的压力与实际用户访问相似。
场景并发用户数：经常会遇到“设置多大并发用户数合适？”的问题，因为在没有任何思考时间的时候，我们有一个简单的公式：
VU（并发压测用户数） = TPS（每秒执行事务数） × RT（响应时间）
所以，在寻找合适的并发用户数上，建议使用性能测试的“梯度模式”，逐渐增加并发用户数，这个时候压力也会越来越大，当TPS的增长率小于响应时间的增长率时，这就是性能的拐点，也就是最合理的并发用户数；当TPS不再增长或者下降时，这个时候的压力就是最大的压力，所使用的并发用户数就是最大的并发用户数。如果此时的TPS不满足你的要求，那么就需要寻找瓶颈来优化。如下图演示的一个性能曲线：
· a点：性能期望值
· b点：高于期望，系统安全
· c点：高于期望，拐点
· d点：超过负载，系统崩溃
注意：使用外网地址压测可能会造成瞬时流量较大，造成流量计费，从而产生费用，建议可以使用内网地址压测，避免损失。
6.2.2、第一阶段
在按照客户提供的4个URL请求构造场景压测以后，同时根据实际情况和客户要求，使用性能测试，构造相应的场景和脚本后，模拟用户实际访问情况，并且脚本中加上了img、js、css等各一个的最大静态资源：
· 条件：5台ECS机器，200并发用户数，一个后台页面加3个静态页面（共150K）
· 结果：静态4000TPS，动态1500TPS，服务器资源：CPU 98%
分析和优化：
服务器资源消耗较高，超过75%，存在瓶颈，分析平台显示：
· 分析发现原来是apache到tomcat的连接等待导致，现象是100个并发压测，就有100个tomcat的java线程，而且全部是runnable的状态，轮询很耗时间。
· 同时发现用户使用的是http协议，非ajp协议，不过这个改动较大，需要使用mod_jk模块，时间原因，暂缓。
解决方法：修改了Apache和tomcat的连接协议 为nio协议，同时去除ssl 协议。Tomcat连接数据库池由30初始调整为300，减少开销
<Connectorport="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443" />
性能对比：
· 再进行1轮压测含动态含静态文件，TPS能够从1w达到2.7W，性能提高将近3倍，并且tomcat的线程从原来的200跑满，降到100附近并且线程没有持续跑满，2.6W TPS时候CPU在80%附近
· 发现机器的核数都是2核，8G内存，对于CPU达到98%的情况，CPU是瓶颈，而对于应用来说比较浪费，所以将2核统一升级为4核。
· 扩展机器资源，从目前的4台扩到6台，同时准备4台备份，以应对访问量较大的情况。
思考和风险：
· 异步请求处理:客户所提供的url都是html静态，虽然页面当中含动态数据，但分析后发现动态数据都是通过jquery执行然后iframe嵌套的，所以不会随着html文件的加载而自动加载，需要分析所有的动态页面，同时压测，这是页面存在异步请求需要关注的地方。
· Iframe:Iframe嵌套页面的方式优点是静态资源调用方便、页面和程序可以分离，但是它的缺点也显而易见，包括样式、脚本额外注入，增加请求等等；还有搜索引擎搜素不到内容；iframe创建比其他元素慢1~2个数量级；资源重复加载；iframe会阻塞页面加载，阻塞onload事件；占用主页连接池；html5不再支持。所以建议尽量不要使用或者少使用。
· [font='Times New Roman']: 脚本录制和模拟实际用户访问。当用户的图片、javascript、CSS等静态资源和后端代码在同一台服务器上时，需要模拟用户的实际访问请求，压测脚本涵盖所有链接和资源。那么使用脚本录制功能就可以采集更全更完整的脚本。
6.2.3、第二阶段
找到几个页面的所有动态资源后，整合成为一个事务，串行访问，同时并发压测，从而对纯服务器端进行压测，测试结果如下图：
性能分析：页面一和页面二的响应时间分别达到了5秒和2秒，性能较差，整体TPS只有11
性能分析：
分析发现响应时间高的原因主要在RDS数据库上，数据库此时的CPU已经达到100%，处理较慢，怀疑跟sql有关，分析慢sql。
优化方法：
数据库第一批优化完毕，优化了6条sql语句之前5s左右，优化后在150ms左右，数据库的QPS 从1k上升到6k。
RDS优化内容包括：
优化点主要是调整慢sql的索引，部分sql需要调整表结构和sql写法，需要应用配合才能完成优化，优化前QPS在1000左右，优化后QPS到达6000
前端响应时间从5秒降低到150毫秒，前台TPS由150提升到1500.总的TPS可以达到2000。
6.2.4、第三阶段
通过性能测试模拟用户实际访问情况，包括所有静态资源，评估出当响应时间小于5秒的时候，最大支撑的并发用户数。
测试结果：
可以看到，所有的事务RT加起来小于5秒的情况下，并发用户数可以达到3000(6个事务，6个脚本，每个脚本500)，远远满足项目500个并发用户的目标。
总结：
6.2.5、第四阶段
评估其他非主站应用的性能以及含静态页面的其他5个页面内容，包括：
· 搜索压测
· 操作压测
· 登录压测
· 证书登入
· 针对5个常用场景进行混合压测
测试结果:
发现的风险和问题：
· 测试发现，流量存在非常明显的波动，不经过某模块就无此问题，发现有大量的reset连接，会诊后总结：端口复用导致的问题。FULL NAT模式和LVS存在兼容性问题。最终结果: 由于存在兼容性问题，影响到网站的稳定性和性能，暂时加载该模块，待问题解决后再加。先使用另外一个模块代替
· 凌晨2点，针对单点用户登入进行了压测，发现100并发，该业务接口已宕机，分析结果:Cache缓存设置太小，1G内存容量导致内存溢出，已建议修改为4G。使用http协议性能不佳，早上4点30进行少量代码优化后，业务直接不可用，环境出现宕机无法修复，我们快速进行快照恢复，5分钟内恢复3台业务机，云产品的优势尽显。用户log日志撑满系统盘，并且一直不知这台云主机还有数据盘，产品上我们要做反思。帮助用户已进行挂盘及日志迁移至数据盘，减少单盘的IO压力。
· Web服务器数据同步，发现服务器io和cpu压力过大。加入inotify机制，由文件增量同步，变更为文件系统的变化通知机制。将冷备及4台备用web机器使用该方式同步，目前，查看内容分发主机IO和CPU使用率已回复正常范围同步推送时间，根据服务器的负载，进行调整同步时间。今天已修改为2分钟。 由于备份量大，晚上进行全量同步。新增4台备用机，已关闭apache 端口 自动从slb去除，作为冷备
· 由于目前单点用户登入入口存在架构单点宕机风险，进行登入和未登入风险验证，确认，如用户已登入后，登入业务系统出现宕机，进行简单的页面点击切换，不受影响
· 内存优化
按照JVM内存管理模式，调整系统启动参数，如果一台ECS部署一台服务器，建议不要选择默认的JVM配置，应该设置内存为物理内存的一半，同时设置相应的YTC和FGC策略，观察Old区变化，避免大量Full GC，建议Full GC频率大于1小时，同时GC时间小于1秒钟。
6.3、架构优化
单点登录服务修改为SLB
检索 修改为 SLB
内容管理云平台云服务器实现行文件差异同步，同时冷备
新增4台web机器
7、总结
备注：服务器的CPU达到100% 这其实是一个好的现象，说明我们的逻辑全部已经走到了资源消耗上，而不是由外部其他逻辑限制或blocked，这种现象带来的好处就是，首先我们可以集中精力从减少代码的资源消耗上解决问题，带来性能的改善，其次，实在无法优化我们也可以增加机器台数，横向扩展来让性能成倍的提高，这也是用成本换性能的方法。当然，前提是架构上支持负载均衡的分布式架构。
总的来说就是，这种情况要不选择从纵向优化，或者选择从横向扩展，都可以增加。
8、遗留问题
时间原因，测试页面有限，有些页面没有测试覆盖到，比如后台页面。
登录系统存在内存风险，由于用户的缓存信息仍然存在单点问题，所以风险较大，同时系统压力不满足要求，并发较高存在crash风险，未来得及发现瓶颈所在。彻底解决必须使用OCS等缓存系统改造，同时优化数据库。
Iframe框架造成用户体验不好，需要改掉，换成异步js接口方式。
后台同步系统，对于资源消耗影响较大，需要持续优化。
平台应该提供开发和测试进行自主压测、分析、评估，同时提供统一的测试报告，保证各部分模块的性能，整合起来才能保障整个门户网站的性能。
CPU优化还需要继续分析跟进，目前只是增加机器资源降低风险，成本较高。
上线发布应该具备统一的回归验证机制，并且日常需要持续优化，避免由于后期代码的改动导致性能下降。
