高流量网站如何做出高性能？
前一段时间接触了一个教育集团的老总，集团本身是在教育实体化阶段也就是各种教科书盛行的时候起来的，最近 10 年互联网教育越来越火，老板也瞅准商机跳了进来。
可是公司的在线教育板块一直不温不火没有什么起色，Google Analytics、百度统计、CNZZ 数据专家等各种运营软件用了个遍还是老样子。
「你说为啥？」老总总是问身边的人。
我尝试打开他公司的官网以及几个教育产品的网页，没有一个页面在 10s 内被打开。。。你说为啥？！
在时间如此精贵的当下，任何一个互联网公司如果不注重用户体验，一味的注重开发、上线、销售，其结局。。。不管你们想到没想到，我想到了。。。。
有一种声音总是在喊「我们要高性能网站！」于是各种服务器、各种 CDN、DNS 全上了之后却发现——花了不少效果不好。
那么，问题来了。。。。
一.什么叫高性能的网站？
现有两个网站性能架构设计方案：方案 A 和方案 B。方案 A 在小于100个并发用户访问时，每个请求的响应时间是1秒，当并发请求达到200的时候，请求的响应时间将骤增到10秒。方案 B 不管是100个还是200个并发访问，每个请求的响应时间都差不多是1.5秒。
哪个方案的性能好？
如果你的老板要求「我们要改善一下网站的性能」，你知道他指的是什么吗？
同类型的两个网站，X 网站服务器平均每个请求的处理时间是500毫秒，Y 网站服务器平均每个请求的处理时间是1000毫秒，为什么用户却反映 Y 网站的速度快呢？
网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标；同时也是主观的感受，而感受则是一种与具体参与者相关的微妙的东西，用户的感受和工程师的感受不同，不同的用户感受也不同。
说的再多最后都要上生产环境，所以，最直接、最真实 的就是把用户访问时的各项指标作为最终的判断依据。
打造一个高性能的网站，首先就是要了解性能，那么我们就需要一些指标来具体量化前端性能这个关键指标！
二.前端页面性能指标
1.Apdex指数
Apdex值和Apdex指数是国际通用标准，是对用户体验满意度的量化值。
基于「真实用户体验」，Apdex 定义了 3 个用户满意区间：「满意」、「可容忍」、「失望」，通过响应时间数值 “T” 来划分。T 值代表着用户满意的响应时间界限，国际上一般默认为 2s，也就是说满意区间就是 0~2s；页面响应时间超过 T 值用户就有些不满了，下一个区间「容忍」的界限值是 T 和 4T，即 4-8 秒之间为容忍区间；响应时间再长用户就开始考虑放弃了，最后一个区间「失望」的响应时间则大于 4T，即多于 8 秒。
采集一定时间内的 Apdex 值之后，经过计算可以得出 Apdex 指数，具体计算公式为:
Apdex 指数 = [ 满意数量 + （ 可容忍数量 / 2）] / 总样本数
这样，用户访问页面的响应时间被量化为一个 0 到 1 之间的「Apdex 指数」，0 代表没有满意用户，1 则代表所有用户都满意。经过统计，基于页面性能的 Apdex 评分于用户的体验紧密关联, 为管理、研发、运维人员提供了一种通过应用性能量化值来评估用户满意度的方法。
可行工具：New Relic、OneAPM Browser Insight
2.页面响应时间
说得再好，做的再多最后页面也是要上生产的，线上的页面用户最直接的感受，就是页面响应时间，也就是页面打开耗时。
很多前端性能工具对页面响应时间这个指数只是简单的在本地模拟下，也就是所谓的「拨测」；或者只是简单的通过 window.performance 接口把各个数据上传给使用者，根本无法展现用户的真实体验。
从技术的角度讲，一个页面的打开时间也是要划分为各个部分的，例如：首屏打开时间、白屏时间、dom文档打开时间、资源加载完成时间等；也要重视资源加载耗时详情，是哪些脚本或者 css 拖慢了页面的加载这些都要一目了然。只有这样，一旦页面响应时间过长，相关人员才能有针对性的去进行维护。
可行工具：New Relic、OneAPM Browser Insight、AppDynamics、Ruxit
3.页面响应时间分布
想了想还是觉得有必要把这个指标从「页面响应时间」里面拿出来单独说。
顾名思义，页面响应时分布间就是一段时间内，用户访问页面的响应时间的分布图。其实大部分情况下，一个网站的维护只需照顾到绝大多数用户就可以了，没有必要为了满足各种极端情况而耗费各种资源，中国网络环境的复杂性相信大家都深有体会，所以这种统计就显得尤为必要，
可行工具：OneAPM Browser Insight、AppDynamics、Ruxit
4.DNS、TCP耗时
浏览器和 WEB 服务器连接 TCP/IP 的消耗时间以及域名解析时间也是网站优化需要关注指标。
还是那句话————国内的网络环境极其复杂，所以导致经常有 DNS，CDN 不给力的情况，TCP 的连接也经常会不稳定。之前国内外有些工具可以通过模拟拨测的方式来计算 DNS 耗时等数据，但讲实在的，只是这种仿真数据的话 DNS 厂家才不会理你，所以，从用户真实体验的角度来收集这类耗时则显得尤为必要，而现在能做好这一点的工具确实不多，给大家推荐几个。
可行工具：OneAPM Browser Insight、AppDynamics、Ruxit
三.性能测试方法
网站上线前以及上线后，相关的性能测试也是必须要有的。性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试。
性能测试
以系统设计初期规划的性能指标为目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。
负载测试
对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值，如某种资源已经呈饱和状态，这时继续对系统施加压力，系统的处理能力不但不能提高，反而会下降。
压力测试
超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。
稳定性测试
被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。在不同生产环境、不同时间点的请求压力是不均匀的，呈波浪特性，因此为了更好地模拟生产环境，稳定性测试也应不均匀地对系统施加压力。
性能测试是一个不断对系统增加访问压力，以获得系统性能指标、最大负载能力、最大压力承受能力的过程。所谓的增加访问压力，在系统测试环境中，就是不断增加测试程序的并发请求数，一般说来，性能测试遵循如下图所示的抛物线规律。
性能测试反应的是系统在实际生产环境中使用时，随着用户并发访问数量的增加，系统的处理能力。与性能曲线相对应的是用户访问的等待时间（系统响应时间）
在日常运行区间，可以获得最好的用户响应时间，随着并发用户数的增加，响应延迟越来越大，直到系统崩溃，用户失去响应。
而从 OneAPM 提供的 Browser Insight 的定位分析功能来看，跟这个图还是很相似的，只不过是 X 坐标轴是响应时间，Y 是访问次数。
性能测试报告
测试结果报告应能够反映上述性能测试曲线的规律，阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息，下表是一个简单示例：
当这些数据得到量化的之后，我们的目标就很明确了，那么最终我们为了打造一个高性能的网站，需要做哪些工作呢？接下来我们分析性能优化的一些策略！
四.性能优化策略
如果性能测试结果不能满足设计或业务需求，那么就需要寻找系统瓶颈，分而治之，逐步优化。
1．性能分析
大型网站结构复杂，用户从浏览器发出请求直到数据库完成操作事务，中间需要经过很多环节，如果测试或者用户报告网站响应缓慢，存在性能问题，必须对请求经历的各个环节进行分析，排查可能出现性能瓶颈的地方，定位问题!
排查一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是 CPU？是代码问题还是架构设计不合理？或者系统资源确实不足？
2．性能优化
定位产生性能问题的具体原因后，就需要进行性能优化，根据网站分层架构，可分为 Web 前端性能优化、应用服务器性能优化、存储服务器性能优化 3 大类，每一类都非常重要，一款好的工具的重要性就不言而喻了。
目前，OneAPM 针对前端性能的优化产品，Browser Insight 可以让用户免费试用；同时包括针对应用服务器性能优化 Application Insight 产品以及针对存储服务器性能优化 Cloud Insight产品也都提供了免费版产品，希望能够帮助用户不断优化，做出真正意义上的高性能高流量网站！！！
