性能优化

一. 摘要 首先声明这篇服务器缓存篇是我平时工作中的一些经验心得，对没有用过，或者不知道如何使用服务器缓存的朋友们提供一个简单的认识与实现思路，本文只是抛 砖引玉，还请各位多多提出宝贵意见，希望能够在大家的指导下写出更好的经验总结，为更多的不会使用或者不知道如何下手的朋友们提供帮助。 闲话，之前写的部分文章可能条理性也不是特别清楚，特别参考博客园部分大牛的组织形式来书写，通过清晰的文章结构，不但能让自己写文章的时候思路清晰， 更能为看到这篇文章的朋友理解我讲解的目的，这就是最好的结果啦。 本人主要讲解的内容：通过程序代码来实现ASP.NET网站的缓存功能。 二. 本文提纲 · 1.摘要 · 2.本文提纲 · 3.服务器缓存简介 · 4.准备工作 · 5.第一个简单程序 · 6.程序配置与部署 · 7.本文总结 三. 服务器缓存简介 缓存的优势： 缓存是一种无需大量时间和分析就可以获得"足够良好的"性能的方法。这里再次强调，内存现在非常便宜，因此，如果您能通过将输出缓存 30 秒， 而不是花上一整天甚至一周的时间尝试优化代码或数据库就可以获得所需的性能，您肯定会选择缓存解决方案（假设可以接受 30 秒的旧数据）。 缓存正是那些利用 20% 付出获得 80% 回报的特性之一，因此，要提高性能，应该首先想到缓存。不过，如果设计很糟糕， 最终却有可能带来不良的后果，因此

0. 浏览器渲染原理： 输入网址 -> dns查询 -> dns缓存 -> 三次握手建立连接 -> 浏览器发送请求到服务器 -> 服务器返回html -> 浏览器渲染页面； 浏览器渲染过程（webkit为例）： ① 首先进行dom解析，css解析，构建dom树；（display:none的元素在dom树） ② css解析完成css rules加到dom树上，生成render tree（回流reflow阶段，应尽量避免）；（display:none的元素不在dom树） ③ 经过层叠上下文处理，生成render layer（重绘repaint阶段），可以直接去paint页面，或者去④； ④ 层合并后生成graphics layer，然后GPU绘制。 1. 浏览器宿主环境层面： 由于单线程解析阻塞限制，可以用script defer属性异步加载，样式放头部，脚本放底部； 结合dns-prefetch、dns-preload、preload预加载资源； 利用事件冒泡机制，采用事件委托方法绑定事件； 浏览器渲染时，开启硬件加速可以生成复合层，复合层交给GPU渲染，但不能滥用； 2. 网络层面： 减少http请求数量：css、js合并，css sprites，font-icon，base64编码图片，图片懒加载； 减轻http数据请求大小：静态资源压缩，tinypng压缩图片，webp格式

图片 你知道吗？加载网页时，平均 60% 以上的流量都来加载图片。 简单的图形，可以直接用 css 实现，代替使用图片 CDN 服务器提供多种尺寸的图片，按屏幕宽度和像素密度去请求对应的图片（详细看我 另外一篇博文 ） 小图用base64 多个小图合成一张雪碧图 选择正确的图片格式（能用webp尽量用，不能的话，小图用png，大图用jpg） 预请求（ 预 解析DNS、 预渲染 页面、 预加载） <link rel="dns-prefetch" href="//yuchengkai.cn"> <link rel="preload" href="http://example.com" as="xxx"> <link rel="prerender" href="http://example.com"> 懒执行、懒加载 　 首屏不需要的逻辑延迟执行，不在首批的图片延时加载 去抖、节流 　　避免短时间内发出多次请求 CDN 　 尽可能的在各个地方分布机房缓存数据 来源： https://www.cnblogs.com/amiezhang/p/11487976.html

完成一个页面请求的流程： 输入地址--> 域名解析--> 发送请求--> 后端代码运行--> 响应请求,浏览器拿到 html 代码--> 浏览器开始渲染页面,并请求页面中的资源（css、JS、img等）--> 渲染完成 每个阶段的性能优化： 传输阶段优化：代码压缩、图片压缩、建立长连接等 后台代码优化：后台逻辑优化、前后台合理分配功能等 sql查询优化：优化数据库、优化查询语句等 响应优化：缓存、CDN加速等 渲染阶段的优化：分三个模块考虑 HTML、CSS、JavaScript（前端优化重点） 　　 HTML代码优化： 　　　　 避免使用frame、iframe（页面加载阻塞、onload事件阻塞等） 　　　　避免空标签、空连接 src 、href 等（即使是空地址，浏览器也会添加默认地址发送请求） 　　　　减少节点深层次嵌套（占用内存多、节点查询费劲） 　　　　减少HTML文档大小（1、减少注释空格 2、避免table布局（节点太多） 3、使用html布局，节点少） 　　　　显示指定文档字符集（若不写，浏览器会先缓存代码，再去查询合适的解析字符集。为避免机器查询消耗，需手动明确指定好） 　　　　设置图片宽高（避免回溯重构） 　　　　避免js脚本阻塞（放底部、异步加载、延迟加载、使用模块管理插件 require.js、sea.js） 　　 CSS代码优化： 　　　　 避免使用

简要： 整个在浏览器的渲染过程中（页面初始化，用户行为改变界面样式，动画改变界面样式等）reflow(回流)和repaint(重绘) 会大大影响web性能，尤其是手机页面。因此我们在页面设计的时候要尽量减少reflow和repaint。 什么是reflow和repaint（原文链接：http://www.cnblogs.com/Peng2014/p/4687218.html） reflow：例如某个子元素样式发生改变，直接影响到了其父元素以及往上追溯很多祖先元素（包括兄弟元素），这个时候浏览器要重新去渲染这个子元素相关联的所有元素的过程称为回流。 reflow：几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显 示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲 染。通常我们都无法预估浏览器到底会 reflow 哪一部分的代码，它们都彼此相互影响着。 repaint： 如果只是改变某个元素的背景色、文 字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器 repaint（重绘）。repaint 的速度明显快于 reflow 下面情况会导致reflow发生 1：改变窗口大小 2：改变文字大小 3：内容的改变

web前端性能优化指南 web前端性能优化指南 概述 1. PC优化手段在Mobile侧同样适用 2. 在Mobile侧我们提出三秒种渲染完成首屏指标 3. 基于第二点，首屏加载3秒完成或使用Loading 4. 基于联通3G网络平均338KB/s(2.71Mb/s)，所以首屏资源不应超过1014KB 5. Mobile侧因手机配置原因，除加载外渲染速度也是优化重点 6. 基于第五点，要合理处理代码减少渲染损耗 7. 基于第二、第五点，所有影响首屏加载和渲染的代码应在处理逻辑中后置 8. 加载完成后用户交互使用时也需注意性能 优化指南 [加载优化] 加载过程是最为耗时的过程，可能会占到总耗时的80%时间，因此是优化的重点 · 减少HTTP请求 因为手机浏览器同时响应请求为4个请求（Android支持4个，iOS 5后可支持6个），所以要尽量减少页面的请求数，首次加载同时请求数不能超过4个 a) 合并CSS、JavaScript b) 合并小图片，使用雪碧图 · 缓存 使用缓存可以减少向服务器的请求数，节省加载时间，所以所有静态资源都要在服务器端设置缓存，并且尽量使用长Cache（长Cache资源的更新可使用时间戳） a) 缓存一切可缓存的资源 b) 使用长Cache（使用时间戳更新Cache） c) 使用外联式引用CSS、JavaScript · 压缩HTML、CSS

移动H5前端优化，从以下几个方面入手： 1、加载优化 2、图片优化 3、css优化 4、脚本优化 5、渲染优化 加载优化 1、合并CSS、JS 2、合并小图片，使用雪碧图 3、缓存一切可缓存的资源 4、使用长Cache 5、使用外联式引用CSS、JS 6、压缩HTML、CSS、JS 7、启用GZip 8、使用首屏加载 9、使用按需加载 10、使用滚屏加载 11、使用Media Query加载 12、增加Loading进度条 13、减少Cookie 14、避免重定向 15、异步加载第三方资源 图片优化 1、使用智图 2、使用（CSS3、SVG、IconFont）代替图片 3、使用Srcset 4、webP优于JPG 5、PNG8优于GIF 6、首次加载不大于1014KB（基于3秒联通平均网速所能达到值） 7、图片不宽于640 CSS优化 1、CSS写在头部，JS写在尾部或异步 2、避免图片和iFame等的空src 3、尽量避免重设图片大小 4、图片尽量使用DataURL 5、尽量避免在HTML标签中些style属性 6、避免css表达式 7、移除空的CSS规则 8、正确使用display属性 9、不滥用float 10、不滥用web字体 11、不声明过多的font-size 12、值为0时不需要任何单位 13、标准化各种浏览器前缀 14、避免让选择符看起来像正则表达式 脚本优化 1

如果我们正在使用Session，那么构建高性能可扩展的ASP.NET网站，就必须解决分布式Session的架构，因为单服务器的SESSION处理能力会很快出现性能瓶颈，这类问题也被称之为Session同步。微软有自己的分布式Session的解决方案，那就是SessionStateServer，我们可以参考： ASP.NET Session State Partitioning http://blog.maartenballiauw.be/post/2008/01/23/ASPNET-Session-State-Partitioning.aspx ASP.NET load balancing and ASP.NET state server http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-(aspnet_state).aspx 不过本文是要换一个方案，那就是使用Memcached来到达分布式SESSION的架构。Memcached作为分布式的缓存服务器已经被广泛应用在网站建设中。 一：Session的机制 Session是针对用户的，我们也可以理解为是针对浏览器的。在浏览器首次访问ASP.NET网页的时候（网页没有关闭session功能）

性能的目标 跑得更快吗？是用更少的资源跑得更快。如果不能兼得，我们通常选择跑得更快，这也是大多数时候性能优化的目的，也有些时候性能优化是为了减少资源消耗。 系统性能的定义 1.吞吐量，系统每s能处理的请求数、任务数 2.时延，系统处理一个请求或者任务的耗时 3.并发数，次级指标，同时接入的客户端数量有时也会成为一个考核指标，一般的后台服务会要求支持100-1000区间的并发连接数，而网站会要求支持10K甚至更大的并发数。 时延和吞吐量往往呈现某种正比关系，吞吐量越高，时延趋于越大，当请求超过系统处理能力时，时延趋于无限大。 并且根据实际经验，时延不会是一个稳定的值，而是一个波动范围，计算吞吐量需要计算区间以及百分比 提高吞吐量，时延区间从400us随之增大 更严重的是，当吞吐量达到一定程度，延迟将会剧烈抖动，出现超长时延，如上图的>50ms. 系统性能测试 收集吞吐量和时延 延迟：每个系统都是有硬性要求的，网站可能是1S-5S，后台系统比如消息队列，可能是100us-5ms之间。 测试工具：调整并发数来模拟不同的吞吐量和时延 在测量延迟的时候，既然延迟是一个区间，我们就需要用百分比来衡量，比如60%以上的时延在1-3ms区间，允许小于2%的大于3ms，一旦不满足任何一个百分比区间，都说明系统还需要优化，case是无效的。 性能测试也要经得起时间考验，一个程序只能高速运行10分钟

2014-10-04 Created By BaoXinjian 一、摘要 索引重建是一个争论不休被不断热烈讨论的议题。当然Oracle官方也有自己的观点，我们很多DBA也是遵循这一准则来重建索引，那就是Oracle建议对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20% 这2种情形下需要重建索引。近来Oracle也提出了一些与之相反的观点，就是强烈建议不要定期重建索引。本文是参考了1525787.1并进行相应描述。 1. 重建索引的理由 Oracle的B树索引随着时间的推移变得不平衡(误解) 索引碎片在不断增加 索引不断增加，删除的空间没有重复使用 索引 clustering factor （集群因子）不同步，可以通过重建修复(误解) 2. 重建索引的本质 本质：重建索引在数据库内部是先执行删除操作，再执行插入操作。 3. 反对重建索引的理由 (1). 大多数脚本都依赖 index_stats 动态表。此表使用以下命令填充： analyze index ... validate structure; 尽管这是一种有效的索引检查方法，但是它在分析索引时会获取独占表锁。对于大型索引，其影响会是巨大的，因为在此期间不允许对表执行DML 操作。 虽然该方法可以在不锁表的情况下在线运行，但是可能要消耗额外的时间。 (2). 重建索引的直接结果是 REDO 活动可能会增加