Web网站性能测试分析及调优实例

　1、背景

　　前段时刻，团队阅历了一个规划较大的门户网站的功用优化作业，该网站的开发和协作触及多个安排和有些，而且网站的首要性清楚明了，一同上线时刻十分急迫，重视度也很高，所以关于悉数团队的压力也十分大。

　　在此，把悉数阅历进程给大家共享一下，包含了首要包含了怎么运用功用测验的压测东西，压测前的功用疑问评价，以及压测履行后的功用疑问剖析、瓶颈定位。

　　该门户网站的效劳器是放在华通和阿里云的渠道上的，所以对华通和阿里共建的云渠道安全及应急办法方面恳求十分高，需求团队给予全力的确保和合作。

　　功用测验（Performance Testing）是集测验机办理、测验脚本办理、测验场景办理、测验使命办理、测验成果办理为一体的功用云测验渠道，能够协助您全方位的评价云上体系功用。

　　本次优化首要是运用了该测验渠道效劳对客户搭建在ECS上的效劳器进行多种类型（功用测验、负载测验、压力测验、安稳性测验、混合场景测验、反常测验等）的功用压测、调试和剖析，终究到达满意希望预估的功用方针值，且上线后在高峰期满意实践的功用和安稳恳求。

　　2、术语界说

　　在介绍项目阅历之前，再清晰一下测验傍边用到的专业方针术语界说，包含但不仅限于以下：

　　PV: 即PageView, 即页面浏览量或点击量，用户每次改写即被核算一次。咱们能够以为，用户的一次改写，给效劳器形成了一次恳求。

　　UV: 即UniqueVisitor,拜访您网站的一台电脑客户端为一个访客。00:00-24:00内一样的客户端只被核算一次。

　　TPS:TPS(Transaction Per Second)每秒钟体系能够处理的买卖或事务的数量，它是衡量体系处理才干的首要方针。

　　呼应时刻: 呼应时刻是指从客户端发一个恳求开端计时，到客户端接收到从效劳器端返回的呼应成果结束所阅历的时刻，呼应时刻由恳求发送时刻、网络传输时刻和效劳器处理时刻三有些构成。

　　VU: Virtual user，模仿真实事务逻辑进程的虚拟用户，虚拟用户模仿的操作进程都被记载在虚拟用户脚本里。通常功用测验进程中，通俗称之为并发用户数。

　　TPS动摇: 体系功用依赖于特定的硬件、软件代码、运用效劳、网络资本等，所以在功用场景履行时期，TPS可能会表现为安稳，或许动摇，抑或遵从必定的上升或降低趋势。咱们用TPS动摇系数来记载这个方针值。

　　CPU: CPU资本是指功用测验场景运转的这个时刻段内，运用效劳体系的CPU资本占用率。CPU资本是判别体系处理才干以及运用运转是不是安稳的首要参数。

　　Load: 体系正在干活的多少的衡量，行列长度。体系均匀负载，被界说为在特定时刻间隔（1m，5m，15m）内运转行列中的均匀进程数。

　　I/O: I/O可分为磁盘IO和网卡IO。

　　JVM: 即java虚拟机，它拥有自个的处理器、仓库、寄存器等，还有自个相应的指令体系。Java运用运转在JVM上面。

　　GC: GC是一种主动内存办理程序，它首要的责任是分配内存、确保被引证的方针始终在内存中、把不被运用的方针从内存中开释。FGC会引起JVM挂起。

　　网速: 网络中的数据传输速率，通常以Byte/s为单位。通过ping延时来反映网速。

　　流量: 功用测验中，通常指单位时刻内流经网卡的总流量。分为inbound和outbound，通常以KB为单位。

　　3、评价

　　本次功用测验进程的参与人包含了阿里云应急确保小组等多有些人员，网站为外部供应商开发，阿里云供给云主机和技术支撑。

　　该网站之前前期也由别的有些做了检验作业，进行了完好的功用测验，陈述显现，功用较差，第一次测验，网站并发数没有超越35个，第2次测验，网站上做了优化后，静态页面减小后，并发用户数100内 5s ，200内 90%呼应在15s以上，跟着并发用户数的添加，页面呼应最高可到20多秒，而且拜访显着感受较慢，所以联系了阿里云的技术支撑，希望能够协助确诊功用疑问，给出优化主张。

　　通过会议讨论后，评价出终究的测验方针：带页面的一切静态资本一同，呼应时刻有必要小于5秒，一同并发拜访用户数最低500，TPS依据实践的成果来得出。

　　4、功用测验方针

　　· 并发用户数：>=500

　　· 事务呼应时刻：<5秒

　　5、剖析

　　通过功用测验前端剖析东西(未敞开)剖析，页面的呼应时刻88%摆布都是耗费在前端资本加载上，效劳器端耗费只占到了页面呼应的12%摆布;

　　一个网站的呼应通常由四有些时刻构成，前端、网络、效劳器和数据库，前端首要是减小页面大小，减小页面恳求数，优化页面js等，网络首要是运用CDN，优化衔接数等，效劳器首要是优化Apache，优化Tomcat，优化java代码等，数据库是优化sql句子，优化索引，优化数据存储等。

　　6、测验和优化

　　6.1、页面前端剖析及优化

　　咱们对页面的优化依然从前端开端，首要通过功用测验的前端测验东西（未敞开）进行扫描，咱们发现以下疑问并优化：

　　· Js较大，无紧缩，一同存在重复恳求，最多一个js加载4次，已做紧缩和削减。

　　· Js方位不合理，阻止页面加载。

　　· 外部css 考虑本地完结，削减调用

　　· Banner 背景图像较多，无紧缩，主张兼并

　　· 页面1的后台.do有4个，削减为3个

　　· 页面2的后台do有 2个，削减为1个

　　· 存在加载失利衔接，404失利，一同次数十分多，更换为cnzz

　　· 页面加载外部资本失利 (qq等)，且不安稳

　　· 共享功用对比慢

　　· 外部资本主张异步完结，现在悉数是jquery烘托，iframe嵌套，时刻资本约束，后期优化

　　· 尽量削减或许不运用iframe

　　页面恳求数太多，首要是js和css重复加载疑问和图像较小致使的。 通过以上修正及装备效劳器静态资本缓存后，功用进步25%，首页呼应从1.5秒进步到1.1秒，而且前端优化继续进行。

　　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优化还需求继续剖析跟进，现在仅仅添加机器资本降低危险，本钱较高。

　　上线发布应当具有一致的回归验证机制，而且平时需求继续优化，防止因为后期代码的改动致使功用降低。