一 前沿
在互联网网站百花齐放的今天，网站响应速度是用户体验的第一要素，其重要性不言而喻，这里有几个关于响应时间的重要条件：
- 用户在浏览网页时，不会注意到少于0.1秒的延迟；
- 少于1秒的延迟不会中断用户的正常思维， 但是一些延迟会被用户注意到；
- 延迟时间少于10秒，用户会继续等待响应；
- 延迟时间超过10秒后，用户将会放弃并开始其他操作；
而在京东，“消费者第一”是公司的第一价值观，为了给消费者提供更好的用户体验，京东网的技术Geeker们在性能优化的路上做了不少的工作，开发了许多工具让网站的性能监测更容易，通过各种可视化报表，工程师们只需要点点鼠标就能看到网站的性能数据，并能根据数据来预测系统的性能趋势，快速发现有价值的优化点。
二 性能指标分类
为了更好的去监控整个系统的性能，做好全流程的优化，美团将指标分为了以下3类：
- Perceived system performance:这类指标主要从工程师的角度去衡量，如后端的响应时间，当前并发的用户数，请求数，请求的错误率等等。
- Perceived user experience:这类指标用来衡量⽤户的真实体验，从用户体验的角度出发，如首屏时间，白屏时间，完全加载时间之类，即用户能实际感觉到得网页加载延迟。
- System performance:这类指标从服务器的角度出发，监测目前服务器的cpu，内存，网络带宽,流量等等物理资源。
对于上述的每一类，衡量标准可能都不一样，在数据展示方面，主要通过趋势图和汇总表格来展现，下面来对这3类指标分别细说：
Perceived system performance
这类指标主要为工程师设计，来衡量业务后端的处理速度，主要从以下几个方面去衡量：
1) 响应时间
在美团，响应时间是性能的主要kpi，对于响应时间，美团做了很多精细化的处理；
首先对每个业务的整体(集群)响应时间有个衡量：
- 95%的响应时间：将一段时间内所有请求的响应时间中取一个值，使95%的请求响应时间均小于或等于它，此值即为95%请求覆盖的响应时间。
- 90%的响应时间：将一段时间内所有请求的响应时间中取一个值，使90%的请求响应时间均小于或等于它，此值即为90%请求覆盖的响应时间。
- 50%的响应时间：将一段时间内所有请求的响应时间中取一个值，使50%的请求响应时间均小于或等于它，此值即为50%请求覆盖的响应时间。
另外为了方便工程师的优化，对具体到每个请求url都做了更精细化的统计，不光统计了上述的指标，还增加了：
- 最大响应时间：某请求的某段时间范围内响应时间的最大值。
- 最小响应时间: 某请求的某段时间范围内响应时间的最小值。
- 时间标准差：某请求某段时间范围内的波动情况，用来衡量某请求是否存在很大波动，标准差越大，波动越大。
2）请求数（按天或小时统计）
根据不同的时间维度去统计系统每天或每小时的请求数（每小时的统计情况可以见上图），并以趋势图和表格形式展示。
3）错误率
关于错误率的统计主要有以下几种：
- connection timeout:http请求中出现504的次数和比例。
- error response：http请求中出现500的次数和比例。
- 错误网关数：http请求中出现502的次数和比例。
- 异常日志统计:统计业务中出现得异常的数量和趋势。
以某内部服务的异常数量趋势为例：
Perceived user experience
这类指标从用户的角度出发，通过模拟用户请求或对真实用户抽样，来监控用户对网站的实际体验效果，主要利用js来收集不同浏览器下访问网站的加载速度和性能；对于一次完整用户请求来说，http请求可以划分为如下几个阶段：
- DNS：域名解析阶段，通常在几毫秒左右
- TCP：建立网络连接
- Requesting：发送请求
- WebServer处理
- Transferring：传输数据
- Parsing：浏览器解析。几个重要的时间点为：
a. 首屏时间 客户端第一屏资源加载完毕
b. domready时间 DOM解析完毕，可以进行动态修改
c. load时间 所有资源加载完毕
对于上述的几个阶段，我们设立了多种时间参数（每个参数又有 90% 和 50% 两种指标）来衡量，具体如下：
- 查找域名：开始查找域名到查找结束,计算公式为（domainLookupEnd - domainLookupStart）
- 建立连接：开始发出连接请求到连接成功,计算公式为（connectEnd - connectStart）
- 请求文档：开始请求文档到开始接收文档,计算公式为（responseStart - requestStart）
- 接收文档：开始接收文档到文档接收完成,计算公式为（responseEnd - responseStart）
- domready：开始解析文档到 DOMContentLoaded 事件被触发,计算公式为（domContentLoadedEventStart - domLoading）
- load事件持续：load 事件被触发到 load 事件完成,计算公式为（loadEventEnd - loadEventStart）
- 完全加载：开始解析文档到文档完全加载,计算公式为（domComplete - domLoading）
- 首屏加载：开始解析文档到首屏加载完毕,计算公式为（firstscreenready - domLoading）
- 完全加载【全过程】：此次浏览最开始时刻到完全加载完毕,计算公式为（domComplete - navigationStart）
- 首屏加载【全过程】：此次浏览最开始时刻到首屏加载完毕,计算公式为（firstscreenready - navigationStart）
为了更清楚的说明每个参数的意义，用下图说明如下：
其中不同的指标对于用户体验的影响权重不同，对于用户来说白屏时间（浏览最开始时刻到首屏加载前）和首屏时间是最重要的。
某应用的上述时间参数趋势图：
System performance
这类指标主要监测目前服务器的cpu，内存，硬盘io率，网络带宽,流量等等物理资源的使用情况，这类指标比较常见，就不细说了。
某内部服务的cpu使用率情况：
某内部服务的硬盘io情况：
某内部服务的网络io情况：
三 实践步骤(部分)
1 网站资源延迟加载，图片，文件等。
2 图片资源裁剪，缩放，压缩
3 整个页面缓存。
4 网站动静分离，cdn加速。
5 数据层面缓存。
6 网站所用语言，环境优化,例如：java jvm 调优等。
1延迟加载-简介，使用场景，原理
简介（ jQuery lazyload 插件）
延迟加载（lazy load）又可称之为懒加载，他是为了避免一些无谓的性能开销而提出来的。所谓延迟加载，就是当真正需要数据的时候，才真正执行数据加载操作。可简单理解为，只有在使用的时候，才会发出sql语句进行查询。
Lazy load是一个用JavaScript编写的插件：jquery.lazyload.js 它可以延迟加载长页面中的图片。在浏览器可是区域外的图片不会被载入，直到用户将页面滚动到他们所在的位置。与图片预加载的处理方式正好相反。
说个最典型的例子，在搜索图片是，我们需要看到大量的图片，但滚动条你会发现，它并不是一开始就全部加载出来的，而是达到一定的程度之后继续加载，即所谓的延迟加载。
使用场景
涉及到图片，falsh资源，iframe，网页编辑器(类似FCK)等占用较大带宽，且这些模块暂且不在浏览器可视区内，因此可以使用lazyload在适当的时候加载该类资源。避免网页打开时加载过多资源，让用户等待太久。
原理
A 获取可视区域（滚动条）相对于浏览器顶端位置；B 加载可视区内未被加载的资源。
延迟加载-实例性能对比
延迟加载-使用
<script src="jquery-1.11.0.min.js"></script>
<script src="jquery.lazyload.js?v=1.9.1"></script>
<script type="text/javascript" charset="utf-8">
$(function() {
$("img.lazy").lazyload({effect: "fadeIn"});
});
</script>
<img class="lazy" data-original="img/hood.jpg" />
延迟加载-参考
1、jQuery.lazyload详解 http://www.cnblogs.com/wenbo/archive/2011/07/15/2107579.html
2、张大大：http://www.zhangxinxu.com/wordpress/?p=1259
3、Jquery图片延迟加载插件jquery.lazyload. http://www.daxueit.com/article/3944.html
4、jQuery.lazyload实现延时加载详解步骤 http://www.daxueit.com/article/21.html
5、jquery lazyload延迟加载技术的实现原理分析 http://www.daxueit.com/article/3777.html
6、Lazyload 延迟加载效果http://www.cnblogs.com/cloudgamer/archive/2010/02/01/LazyLoad.html
7、图片延迟加载（lazyload）的实现原理 http://www.cnblogs.com/jxlwqq/p/4318979.html
2 图片裁缩压
裁剪缩放压缩
A 用户上传图片选定图片大小进行裁剪
B 服务器端进行自动裁剪
分三种情况 ：
第一种用户发起图片请求的时候，服务端才开始裁缩压。
第二种图片被上传的时候就进行裁缩压。
第三种改变图片格式，例如目前比较新的google开发的webp图片格式，宗旨加快图片加载速度，图片压缩采用人眼识别无差异而降低图片容量大小的算法。
3 整个页整个页面缓存-原理
http协议缓存
http缓存是基于HTTP协议的浏览器文件级缓存机制。即针对文件的重复请求情况下，
浏览器可以根据协议头判断从服务器端请求文件还是从本地读取文件，chrome控制台
下的Frames即展示的是浏览器的http文件级缓存。以下是浏览器缓存的整个机制流程。
主要是针对重复的http请求，在有缓存的情况下判断过程主要分3步：
◆判断expires，如果未过期，直接读取http缓存文件，不发http请求，否则进入下一步。
◆判断是否含有etag，有则带上if-none-match发送请求，未修改返回304，修改返回200，
否则进入下一步。
◆判断是否含有last-modified，有则带上if-modified-since发送请求，无效返回200，有效
返回304，否则直接向服务器请求。
整个页面缓存-实现形式
Jsp页面端缓存，标签配置
服务器端缓存，response 头中设置
Nginx 中配置
4 动静分离-原理
动静分离是将网站静态资源（HTML，JavaScript，CSS，img等文件）与后台应用分开部署，提高用户访问静态代码的速度，降低对后台应用访问。
静态资源服务器
Nginx，apache，Weblogic等
5 静态资源部署至CDN上
Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，
使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，
CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。
Html，JavaScript,CSS以及img文件都存放在CDN服务器上，可以将静态资源统一放置在一种服务器上，便于前端进行维护；而且用户在访问静态资源时，可以很好利用CDN的优点。
缓存系统
流量调度系统
业务系统
数据报表系统
参考
http://blog.csdn.net/yemou_blog/article/details/50292329
Caching Tutorial
服务好“最后一公里”，高效CDN架构经验
阿里云CDN高性能Cache系统架构之道
一名CDN老兵的分享
https://www.cnblogs.com/my_life/articles/6398164.html
6 Jvm优化-多处理器和主存
Jvm-优化
Jmeter+jprofile
JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat等小巧的工具
OutOfMemoryError，内存不足
栈溢出
内存泄露
线程死锁
锁争用（Lock Contention）
Java进程消耗CPU过高
Jvm-直接内存
在JDK1.4 中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）
与缓冲区（Buffer）的I/O 方式，它可以使用Native 函数库直接分配堆外内存，然
后通过一个存储在Java 堆里面的DirectByteBuffer 对象作为这块内存的引用进行
操作。这样能在一些场景中显著提高性能，因为避免了在Java 堆和Native 堆中来
回复制。
总结
俗话说“军马未动，粮草先行！”，监控->分析->优化，号称是性能优化的三部曲，为了更容易地找到性能优化的关键点，建立一个统一的精细化的性能监控平台，做到数据驱动型的性能优化，是公司的长远目标，也是值得公司投入的一个方向，性能优化，从监控开始，只有监控的性能指标体系建立好了，才能更好地去做分析和优化！
http目前使用的时1.x协议，将来升级到2.0(grpc中有用到)，2.0内部变化较大，性能会有很大提升
jdk 版本升级到1.8，使用ConcurrentHashMap，CopyOnWriteArrayList，Streams并行聚合性能和并发上会有很大改进，这里不在赘述。
技术广度和深度如同大海面积和纵深高度。
Jvm优化-备注
https://www.cnblogs.com/fubaizhaizhuren/p/4976839.html
https://www.cnblogs.com/dingyingsi/p/3760447.html
http://www.cnblogs.com/dolphin0520/p/3613043.html
http://www.cnblogs.com/sunada2005/p/3577799.html
http://blog.csdn.net/ns_code/article/details/17565503