最新消息:58同城UBU事业部,急需Java后端工程师,欢迎各位牛人联系,欢迎您的加入!!!鼓掌vvvv神奇的网站,神奇的平台,欢迎您的来信。

浅谈Web性能优化

技术经验 goomoon 650浏览 0评论
Web性能优化包括哪些??
负载均衡??分布式??CDN??缓存??
web性能包含很多方面,不仅仅是以上几种。我们先看一张图:

clipboard

从上图看可以总结出,页面的加载时间包括dom结构加载和页面的渲染。
用户响应时间分布:
10%~20%——从服务器端获取HTML文档上(后端数据)
80%~90%——下载页面中的所有组件上(页面渲染)
在web项目有一个性能测试原则:“二八原则”,也就是说:前端为八,后端为二。
所以性能优化,不仅仅在后端,前端的优化往往能起到立竿见影的效果。下面根据我的一些经验分两块说一下一些优化点。

前端性能优化

  一、尽量减少前端HTTP请求
    浏览器并发线程数有限,所以针对资源文件的优化,一般有:
1、 合并脚本文件和CSS文件
2、 CSS Sprites利用CSS background相关元素进行背景图绝对定位,把多个图片合成一个图片。

  二、浏览器缓存

在用户浏览网站的不同页面时,很多内容是重复的,比如相同的JS、CSS、图片等。如果我们能够建议甚至强制浏览器在本地缓存这些文件,将大大降低页面产生的流量,从而降低页面载入时间。
1、添加Expires头和Cache-Control
    Expires头,浏览器端根据过期时间选择是否加载最新的版本。缺点是:需要服务器和客户端时间的严格同步,
    HTTP1.1引入了Cache-Control头来克服Expires头的限制。Cache-Control使用max-age制定组件被缓存多久,使用秒为单位,例如Cache-Control:max-age=3600;表示组件将被缓存60分钟。如果max-age和Expires同时出现,则max-age有更高的优先级,浏览器会根据max-age的时间来确认缓存过期时间。
2、Last-Modified
    在上次传输中,服务器给浏览器发送了Last-Modified或Etag数据,再次浏览时浏览器将提交这些数据到服务器,验证本地版本是否最新的,如果为最新的则服务器返回304代码,告诉浏览器直接使用本地版本,否则下载新版本。一般来说,有且只有静态文件,服务器端才会给出这些数据。

  三、页面压缩

  • 1、GZIP
    • IE和Firefox浏览器都支持GZIP解码。后端服务器容器对数据GZIP压缩之后在传输到客户端,浏览器拿到数据后根据 Content-Encoding:gzip    进行解压,这样虽然稍微占用了一些服务器和客户端的CPU,但是换来的是更高的带宽利用率。对于纯文本来讲,压缩率是相当可观的。
  • 2,HTML压缩
  • 3,JS压缩 混淆
  • 4,CSS压缩
  • 5,图片压缩,展示尺寸和图片尺寸吻合

  四、HTML代码结构优化

1,正确布置行内脚本
  • 尽可能使用外部脚本和样式文件
  • 脚本尽可能移到底部
  • 脚本放在顶部带来的问题,
    1) 使用脚本时,对于位于脚本以下的内容,逐步呈现将被阻塞
    2)  在下载脚本时会阻塞并行下载
    放在底部可能会出现JS错误问题,当脚本没加载进来,用户就触发脚本事件。所以要综合考虑情况。
  • Script延迟加载  defer属性(IE & FF3.1+)、setTimeout
  •     风险:行内(内联)脚本在样式表后面。
        所有主流浏览器都会保持CSS和JavaScript的顺序。在样式表完全下载、解析及应用之后,内联脚本才能执行。同时,必须在内联脚本执行后,剩余资源才能下载。
        CSS的下载解析可以和其他资源并发执行。
 2,少用iframe

优点:可以和主页面并行加载
缺点: iframe会阻塞onload事件  解决:onload事件后设置iframe的src,或者JS创建iframe节点
和主页面使用同一个连接池
避免src为空—为空默认为主页面地址

clipboard

 

3,减少DOM结构的层级
    DOM层级越深会增加 CSS rule Tree 和 Dom Tree 匹配构造的性能
4,减少Cookie的大小
5,尽量用div取代table,或者将table打破成嵌套层次深的结构
    table会影响页面呈现的速度,只有table里的内容全部加载完才会显示。

  五、组件分成多个域

主要的目的是提高页面组件并行下载能力。但不要跨太多域名,建议采用2个子域名。

  六、图片懒加载


  七、图片,脚本,数据 预加载

 

  八、图片base64


  九、根据业务实际情况优化,保证首屏加载时间。

        前端优化可以避免我们造成无谓的服务器和带宽资源浪费,但随着网站访问量的增加,仅靠前端优化已经不能解决所有问题了,后端程序处理并发请求的能力、程序运行的效率、硬件性能以及系统的可扩展性,将成为影响网站性能和稳定的关键瓶颈所在。

后端性能优化 

评价指标:
一般有下面几个:
  • 吞吐率:单位时间内服务器处理的请求次数(requests per second)
  • 用户平均请求等待时间:每个用户发起一次请求->得到回应的耗时
  • 服务器平均请求处理时间:服务器处理一条请求的耗时
  • 系统负载:一般包括CPU使用率、CPU Load、内存使用情况、磁盘I/O、网络I/O等
 
优化建议和方法:
  一、程序环境的优化
    1、Tomcat,jvm,apache,mysql等软件环境安装配置参数的优化
    2、应用程序预编译

  二、web访问的负载均衡
    比较流行用Nginx做代理服务器实现负载均衡

  三、数据库的优化

索引优化,sql优化,分库分表,读写分离。
mysql的并发和性能依赖缓存和磁盘IO。磁盘io限制比较大,目前主流的SD硬盘读写速度约500MB/s

  四、计算外包

        为了保证较高的请求吞吐率以及处理单次请求的效率,业务逻辑代码中不适合出现特别耗时的操作(比如图像处理、群发邮件、推荐算法等),所以把这些耗时的计算过程从业务代码中外包出去,交给独立的计算模块完成。计算外包(也就是分布式计算)可以有2种策略:异步计算、并行计算。

  五、缓存

        页面缓存,服务端数据缓存,客户端数据缓存,数据库查询缓存等;
        本地内存,本地文件,分布式缓存(分布式共享内存缓存memcache,可持久化redis);

  六、算法优化


  七、服务模块化、服务拆分、动静分离

        1、将服务按功能、实现逻辑等 分成若干个低耦合甚至不耦合的模块,拆分到不同的节点(服务器)。
        2、页面 动态部分和静态部分分离,动态的程序采用apache,tomcat等后端服务容器,静态的部分如js,css,图片可以用轻量级的web server。也可以使用业内比较热门的CDN缓存技术

  八、多个模块的优化

        1、模块的分级。优先保证重要模块的执行和数据。
        2、对各个模块根据不同的模块场景,可以选择异步执行(比如:日志上报,Log输出,等不影响业务流程的模块)或者 多线程并发执行(多个低耦合的模块)。

  九、后端策略优化

        以更优雅的交互策略达到用户一致的体验。
        最常用的一种策略:用户操作触发时候处理,将集中处理改为分散处理。其他:懒加载,预加载。
借用一下JavaEye中别人讨论过的例子:某个系统要求在某个时间将用户积分清零的需求。
最直接的方案: 定时将系统中所有的用户积分清零。其弊端在于:如果系统用户量特别大,则在一小段时间内用户将不可进行积分操作。
优化后的策略:用户进行积分操作是分散的,同一时间进行积分操作的压力是很小。因此可以考虑在用户进行积分操作时才考虑是否进行积分清零。
  十、日志输出的规范化

        日志格式的规范、日志等级的问题、减少无用日志的输出、合理控制单次请求的日志条数。
        首先规范化,没什么可说的,利人利己。
        其次,日志输出太多,反而会影响性能。因为日志的输出会对日志文件加锁,如果日志并发大的太多,并发量高了反而会消耗cpu资源。所以应该颗粒控制日志的输出,减少不必要的日志输出。

  十一、页面静态化

        用一些模板组件,将不经常更新的页面内容静态化。例如58同城pc首页、大类页等。

  十二、资源的复用(后端)

        1、一次请求里,某一数据不要重复取
        2、连接池(Http连接池,数据库连接池等等)

  十三、编码优化

        再牛X的策略也挡不住白菜一样的代码

性能优化,没有最好只有更好,它好,我也好。

任何一种优化都要以实际业务场景来适配,脱离业务场景谈优化真的是耍流氓。

除了做好这些优化点之外,各种性能监控也是必不可少的,包括:前端页面加载时间监控,首屏监控,页面语义监控,日志监控,后端响应时间监控,后端程序处理模块化时间监控等等。做好监控,也能辅助我们对系统更好的优化。
有道云笔记URL:http://note.youdao.com/yws/public/redirect/share?id=16bc8d107e64274fc95be4c7a95b0a2e&type=false

转载请注明:刘召考的博客 » 浅谈Web性能优化