《大型网站技术架构》网站的高性能架构及优化

一、网站性能测试

(1)性能测试指标:①响应时间;②并发数;③吞吐量;④性能计数器;

(2)性能测试方法:①性能测试;②负载测试;③压力测试;④稳定性测试;

(3)性能优化策略:

  ①性能分析:检查请求处理各个环节的日志,分析哪个环节响应时间不合理,检查监控数据分析影响性能的因素;

  ②性能优化:Web前端优化,应用服务器优化,存储服务器优化;

二、Web前端性能优化

(1)浏览器访问优化:

  ①减少http请求:因为http是无状态的,每次请求的开销都比较昂贵(需要建立通信链路、进行数据传输,而服务器端对于每个http请求都需要启动独立的线程去处理);减少http的主要手段是合并CSS、合并JS、合并图片(CSS精灵,利用偏移定位image);

  ②使用浏览器缓存:设置http头中Cache-Control和Expires属性;

  ③启用压缩:可以对html、css、js文件启用Gzip压缩,可以达到较高的压缩效率,但是压缩会对服务器及浏览器产生一定的压力;

  ④CSS放页面最上面,JS放页面最下面:浏览器会在下载完全部CSS之后才开始对整个页面进行渲染,因此最好将CSS放在页面最上面;而浏览器在加载JS后会立即执行,有可能会阻塞整个页面,造成页面显示缓慢,因此最好将JS放在页面最下面;

  ⑤减少Cookie传输:一方面,太大的Cookie会严重影响数据传输;另一方面,对于某些静态资源的访问(如CSS、JS等)发送Cookie没有意义;

(2)CDN加速:

  CDN(内容分发网络)仍然是一个缓存,它将数据缓存在离用户最近的地方,便于用户以最快速度获取数据。即所谓的“网络访问第一跳”,如下图所示:

  CDN只将访问频度很高的热点内容(例如:图片、视频、CSS、JS脚本等访问频度很高的内容)进行缓存,可以极大地加快用户访问速度,减少数据中心负载。

(3)反向代理:

  反向代理服务器位于网站机房,代理网站Web服务器接收Http请求,对请求进行转发,如下图所示:

  反向代理服务器具有以下功能:

  ①保护网站安全:任何来自Internet的请求都必须先经过代理服务器;

  ②通过配置缓存功能加速Web请求:减轻真实Web服务器的负载压力;

  ③实现负载均衡:均衡地分发请求,平衡集群中各个服务器的负载压力;

三、应用服务器性能优化

(1)分布式缓存:

PS:网站性能优化第一定律:优先考虑使用缓存优化性能。缓存是指将数据存储在相对较高访问速度的存储介质中(如内存),以供系统进行快速处理响应用户请求。

  ①缓存本质是一个内存Hash表,数据以(Key,Value)形式存储在内存中。

  ②缓存主要用来存放那些读写比很高、很少变化的数据,如商品的类目信息、热门商品信息等。这样,应用程序读取数据时,先到缓存中取,如缓存中没有或失效,再到数据库中取出,重新写入缓存以供下一次访问。因此,可以很好地改善系统性能,提高数据读取速度,降低存储访问压力

  ③分布式缓存架构:一方面是以以JBoss Cache为代表的互相通信派;另一方面是以Memcached为代表的互不通信派;

  JBoss Cache需要将缓存信息同步到集群中的所有机器,代价比较大;而Memcached采用一种集中式的缓存集群管理,缓存与应用分离部署,应用程序通过一致性Hash算法选择缓存服务器远程访问缓存数据,缓存服务器之间互不通信,因而集群规模可以轻易地扩容,具有良好的伸缩性。

  Memcached由两个核心组件组成:服务端(ms)和客户端(mc),在一个memcached的查询中,mc先通过计算key的hash值来确定kv对所处在的ms位置。当ms确定后,客户端就会发送一个查询请求给对应的ms,让它来查找确切的数据。因为这之间没有交互以及多播协议,所以 memcached交互带给网络的影响是最小化的。

(2)异步操作:

  ①使用消息队列将调用异步化,可改善网站的扩展性,还可改善网站性能;

  ②消息队列具有削峰的作用->将短时间高并发产生的事务消息存储在消息队列中,从而削平高峰期的并发事务;

PS:任何可以晚点做的事情都应该晚点再做。前提是:这个事儿确实可以晚点再做。

(3)使用集群:

  ①在高并发场景下,使用负载均衡技术为一个应用构建多台服务器组成的服务器集群;

  ②可以避免单一服务器因负载压力过大而响应缓慢,使用户请求具有更好的响应延迟特性

  ③负载均衡可以采用硬件设备,也可以采用软件负载。商用硬件负载设备(例如出名的F5)成本通常较高(一台几十万上百万很正常),所以在条件允许的情况下我们会采用软负载,软负载解决的两个核心问题是:选谁、转发,其中最著名的是LVS(Linux Virtual Server)。

PS:LVS是四层负载均衡,也就是说建立在OSI模型的第四层——传输层之上,传输层上有我们熟悉的TCP/UDP,LVS支持TCP/UDP的负载均衡。

LVS的转发主要通过修改IP地址(NAT模式,分为源地址修改SNAT和目标地址修改DNAT)、修改目标MAC(DR模式)来实现。有关LVS的详情请参考:http://www.importnew.com/11229.html

(4)代码优化:

  ①多线程:使用多线程的原因:一是IO阻塞,二是多CPU,都是为了最大限度地利用CPU资源,提高系统吞吐能力,改善系统性能;

  ②资源复用:目的是减少开销很大的系统资源的创建和销毁,主要采用两种模式实现:单例(Singleton)和对象池(Object Pool)。例如,在.NET开发中,经常使用到的线程池,数据库连接池等,本质上都是对象池。

  ③数据结构:在不同场合合理使用恰当的数据结构,可以极大优化程序的性能。

  ④垃圾回收:理解垃圾回收机制有助于程序优化和参数调优,以及编写内存安安全的代码。这里主要针对Java(JVM)和C#(CLR)一类的具有GC(垃圾回收机制)的语言。

四、存储性能优化

(1)机械硬盘 还是 固态硬盘?

  ①机械硬盘:通过马达驱动磁头臂,带动磁头到指定的磁盘位置访问数据。它能够实现快速顺序读写,慢速随机读写

  ②固态硬盘(又称SSD):无机械装置,数据存储在可持久记忆的硅晶体上,因此可以像内存一样快速随机访问

  在目前的网站应用中,大部分应用访问数据都是随机的,这种情况下SSD具有更好的性能表现,但是性价比有待提升(蛮贵的,么么嗒)。

(2)B+树 vs LSM树

  ①传统关系型数据库广泛采用B+树,B+树是对数据排好序后再存储,加快数据检索速度。

PS:目前大多数DB多采用两级索引的B+树,树的层次最多三层。因此可能需要5次磁盘访问才能更新一条记录(三次磁盘访问获得数据索引及行ID,一次数据文件读操作,一次数据文件写操作,终于知道数据库操作有多麻烦多耗时了)

  ②NoSQL(例如:HBase)产品广泛采用LSM树:

  具体思想是:将对数据的修改增量保持在内存中,达到指定的大小限制后将这些修改操作批量写入磁盘。不过读取的时候稍微麻烦,需要合并磁盘中历史数据和内存中最近的修改操作,所以写入性能大大提升,读取时可能需要先看是否命中内存,否则需要访问较多的磁盘文件。

  LSM树的原理是:把一棵大树拆分成N棵小树,它首先写入内存中,随着小树越来越大,内存中的小树会被清除并写入到磁盘中,磁盘中的树定期可以做合并操作,合并成一棵大树,以优化读性能。

  LSM树的优势在于:在LSM树上进行一次数据更新不需要磁盘访问,在内存即可完成,速度远快于B+树。

参考文献

(1)李智慧,《大型网站技术架构-核心原理与案例分析》,http://item.jd.com/11322972.html

(2)周言之,《Memcached详解》,http://blog.csdn.net/zlb824/article/details/7466943

(3)百度百科,CDN,http://baike.baidu.com/view/8689800.htm

(4)王晨纯,《Web基础架构:负载均衡和LVS》,http://www.importnew.com/11229.html

(5)辉之光,《B树、B-树、B+树》,http://www.cnblogs.com/oldhorse/archive/2009/11/16/1604009.html

(6)yanghuahui‘s blog,《LSM树由来、设计思想以及应用到HBase的索引》,http://www.cnblogs.com/yanghuahui/p/3483754.html

时间: 2024-10-15 13:41:32

《大型网站技术架构》网站的高性能架构及优化的相关文章

大型网站技术架构(2):架构要素和高性能架构

上一篇我们把整个架构演变过程大致说了一下,这次我们来说说从哪方面进行考虑设计 为了使网站的能够应对高并发访问,海量数据处理,高可靠运行等一系列问题,我们可以选择横向或纵向两个方向来入手 基本思路 首先可以对整个架构进行分层,一般可以分为 应用层,服务层,数据层:实践中,大的分层结构中还可以继续分层,比如 应用层 还可以继续分为 视图层 和 业务逻辑层,服务层也可以继续细分为 数据接口层 逻辑处理层 等 通过分层,我们把一个庞大的系统切分为不同的部分,便于分工开发和维护:各层之间相互有一定的独立性

大型网站技术架构(四)--网站的高性能架构

大型网站技术架构(一)--大型网站架构演化 大型网站技术架构(二)--架构模式 大型网站技术架构(三)--架构核心要素 网站性能是客观的指标,可以具体体现到响应时间.吞吐量.并发数.性能计数器等技术指标. 1.性能测试指标 1.1 响应时间 指应用执行一个操作需要的时间,指从发出请求到最后收到响应数据所需要的时间.如下列出了系统常用的操作响应时间表. 操作 响应时间 打开一个网站 几秒 数据库查询一条记录(有索引) 十几毫秒 机械磁盘一次寻址定位 4毫秒 从机械磁盘顺序读取1M数据 2毫秒 从S

《大型网站技术架构》读书笔记四:瞬时响应之网站的高性能架构

一.网站性能测试 (1)性能测试指标:①响应时间:②并发数:③吞吐量:④性能计数器: (2)性能测试方法:①性能测试:②负载测试:③压力测试:④稳定性测试: (3)性能优化策略: ①性能分析:检查请求处理各个环节的日志,分析哪个环节响应时间不合理,检查监控数据分析影响性能的因素: ②性能优化:Web前端优化,应用服务器优化,存储服务器优化: 二.Web前端性能优化 (1)浏览器访问优化: ①减少http请求:因为http是无状态的,每次请求的开销都比较昂贵(需要建立通信链路.进行数据传输,而服务

大型网站技术架构(四)--网站的高性能架构(转)

http://blog.csdn.net/chaofanwei/article/details/27168603 网站性能是客观的指标,可以具体体现到响应时间.吞吐量.并发数.性能计数器等技术指标. 1.性能测试指标 1.1 响应时间 指应用执行一个操作需要的时间,指从发出请求到最后收到响应数据所需要的时间.如下列出了系统常用的操作响应时间表. 操作 响应时间 打开一个网站 几秒 数据库查询一条记录(有索引) 十几毫秒 机械磁盘一次寻址定位 4毫秒 从机械磁盘顺序读取1M数据 2毫秒 从SSD磁

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. 首先,所谓网站的伸缩性,指不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力.在整个互联网行业的发展渐进演化中,最重要的技术就是服务器集群,通过不断地向集群中添加服务器来增强整个集群的处理能力. 一.网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 (1)纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性: (2)横向分离:将不同的业务模块分离部署

《大型网站技术架构》读书笔记之八:固若金汤之网站的安全性架构

此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. 一.网站应用攻击与防御 二.信息加密技术与密钥安全 三.信息过滤与反垃圾 四.电子商务风险控制 五.学习总结 转眼之间,<大型网站技术架构>的读书笔记到此就结束了.最近时间非常紧,因此本篇没有详细对笔记进行介绍(本篇涉及太多内容,而且都是安全相关的).通过本书的学习,我们从高性能.高可用.伸缩性.可扩展性.安全性五个方面的架构学习了每个方面经典的技术方案,虽然以理论偏多,但还是可以从中管中窥豹,一览

大型网站技术架构(一):大型网站架构演化

第一章:大型网站架构演化 九层之台,始于垒土:千里之行,始于足下. 对于网站的发展,亦是如此,从上世纪90年代开始,互联网经历了20多年的发展,发生了翻天覆地的变化,今天,全球有一半的人使用互联网,从信息检索到实时通信,从电子购物到文化娱乐,互联网渗透到了生活的每一个角落.但是,构建一个高性能的网站,绝非一朝一夕可以完成,我们来看下,作为一个大型网站系统应有的特点: 1.大型网站系统应有的特点 高并发,大流量:需要面对高并发用户,大流量访问.举个例子,去往迪拜的飞机有200张票,但是有100w人

大型网站技术架构(七)--网站的可扩展性架构

大型网站技术架构(一)--大型网站架构演化 大型网站技术架构(二)--架构模式 大型网站技术架构(三)--架构核心要素 大型网站技术架构(四)--网站的高性能架构 大型网站技术架构(五)--网站高可用架构 大型网站技术架构(六)--网站的伸缩性架构 扩展性是指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力. 设计网站可扩展架构的核心思想是模块化,并在此基础上,降低模块间的耦合性,提供模块的复用性.模块通过分布式部署,独立的模块部署在独立的服务器上(集群)从物理上分离模块之间的耦合关系

【大型网站技术实践】初级篇:搭建MySQL主从复制经典架构 一、业务发展驱动数据发展

一.业务发展驱动数据发展 随着网站业务的不断发展,用户量的不断增加,数据量成倍地增长,数据库的访问量也呈线性地增长.特别是在用户访问高峰期间,并发访问量突然增大,数据库的负载压力也会增大,如果架构方案不够健壮,那么数据库服务器很有可能在高并发访问负载压力下宕机,造成数据访问服务的失效,从而导致网站的业务中断,给公司和用户造成双重损失.那么,有木有一种方案能够解决此问题,使得数据库不再因为负载压力过高而成为网站的瓶颈呢?答案肯定是有的. 目前,大部分的主流关系型数据库都提供了主从热备功能,通过配置