商家名称 | 信用等级 | 购买信息 | 订购本书 |
构建高性能Web站点(修订版) [平装] | |||
构建高性能Web站点(修订版) [平装] |
《构建高性能Web站点(修订版)》充分应用跨学科知识和科学分析方法,通过宽泛的视野和独特的角度,将《构建高性能Web站点(修订版)》的内容展现得更加透彻和富有趣味。此书深入分析了常见的高性能Web技术的方法和原理,内容丰富,文字生动,对比形象,对搭建高性能Web站点具备很强的可操作性。
本书是作者在Web系统领域多年工作、实践和探索的结晶。本书涉及了Web系统优化的各个方面,从浏览器、Cactle到Web、数据库和分布式文件系统等;穿插了大量的实际测试数据和很多流行开源软件的使用方法与案例;内容丰富,文字生动,对比形象。对于网络系统架构师、运维和开发人员,这是很好的参考书目;对于想了解Web性能并希望动手实践的人员,这是由浅入深的学习书籍。
——章文嵩博士,LVS作者,Linux内核作者之一
本书深入分析了常见的高性能Web技术的方法和原理,对搭建高性能Web站点具备很强的可操作性。
——张松国,腾讯网技术总监
这是一个令人兴奋的领域,这一系列准则和方法在TopN的互联网公司中都有大规模的实践和应用,作者在书中进行了详细而量化的论述。如果你正在为日益庞大的应用而手足无措,那么你唯一要做的就是拥有这本书,并且实践它。
——朱鑫,MemcacheD8作者 新浪网研发中心平台部高级工程师
互联网寄托着我们的梦想,它改变了人们的生活,从社交网站到网络游戏,从搜索引擎到电子商务,成功的秘诀在于如何构建高性能Web站点。郭欣在这本书中几乎涵盖了Webt性能优化的所有内容,并从多个角度进行了全面的阐述,你可以通过其通俗易懂的文字,深入理解高性能站点架构的真相并开拓视野,从而对性能瓶颈对症下药。本书可谓是高性能站点的必读精作。
——沈翔,GGoogle Developer Advocate,加州总部
郭欣,拥有10年以上的Web开发和架构经验,以及多年的创业经历。曾就职于腾讯公司,先后负责诸多Web产品的开发、架构和技术管理,并致力于性能研究和实践推广。在加入腾讯之前,获得国家系统分析师职称。热衷于创造简单易用的互联网产品,曾创建国内知名性能监控云服务“监控宝”,并入选年度中国最受关注初创公司。爱好广泛,喜欢摇滚音乐、赛车、旅游、电影,也曾是一名业余吉他手。
第1章 绪论
1.1 等待的真相
1.2 瓶颈在哪里
1.3 增加带宽
1.4 减少网页中的HTTP请求
1.5 加快服务器脚本计算速度
1.6 使用动态内容缓存
1.7 使用数据缓存
1.8 将动态内容静态化
1.9 更换Web服务器软件
1.10 页面组件分离
1.11 合理部署服务器
1.12 使用负载均衡
1.13 优化数据库
1.14 考虑可扩展性
1.15 减少视觉等待
第2章 数据的网络传输
2.1 分层网络模型
2.2 带宽
2.3 响应时间
2.4 互联互通
第3章 服务器并发处理能力
3.1 吞吐率
3.2 CPU并发计算
3.3 系统调用
3.4 内存分配
3.5 持久连接
3.6 I/O模型
3.7 服务器并发策略
第4章 动态内容缓存
4.1 重复的开销
4.2 缓存与速度
4.3 页面缓存
4.4 局部无缓存
4.5 静态化内容
第5章 动态脚本加速
5.1 opcode缓存
5.2 解释器扩展模块
5.3 脚本跟踪与分析
第6章 浏览器缓存
6.1 别忘了浏览器
6.2 缓存协商
6.3 彻底消灭请求
第7章 Web服务器缓存
7.1 URL映射
7.2 缓存响应内容
7.3 缓存文件描述符
第8章 反向代理缓存
8.1 传统代理
8.2 何为反向
8.3 在反向代理上创建缓存
8.4 小心穿过代理
8.5 流量分配
第9章 Web组件分离
9.1 备受争议的分离
9.2 因材施教
9.3 拥有不同的域名
9.4 浏览器并发数
9.5 发挥各自的潜力
第10章 分布式缓存
10.1 数据库的前端缓存区
10.2 使用memcached
10.3 读操作缓存
10.4 写操作缓存
10.5 监控状态
10.6 缓存扩展
第11章 数据库性能优化
11.1 友好的状态报告
11.2 正确使用索引
11.3 锁定与等待
11.4 事务性表的性能
11.5 使用查询缓存
11.6 临时表
11.7 线程池
11.8 反范式化设计
11.9 放弃关系型数据库
第12章 Web负载均衡
12.1 一些思考
12.2 HTTP重定向
12.3 DNS负载均衡
12.4 反向代理负载均衡
12.5 IP负载均衡
12.6 直接路由
12.7 IP隧道
12.8 考虑可用性
第13章 共享文件系统
13.1 网络共享
13.2 NFS
13.3 局限性
第14章 内容分发和同步
14.1 复制
14.2 SSH
14.3 WebDAV
14.4 rsync
14.5 Hash tree
14.6 分发还是同步
14.7 反向代理
第15章 分布式文件系统
15.1 文件系统
15.2 存储节点和追踪器
15.3 MogileFS
第16章 数据库扩展
16.1 复制和分离
16.2 垂直分区
16.3 水平分区
第17章 分布式计算
17.1 异步计算
17.2 并行计算
第18章 性能监控
18.1 实时监控
18.2 监控代理
18.3 系统监控
18.4 服务监控
参考文献
索引
版权页:
插图:
往往也正是因为这些请求性质的不同,Web服务器并发能力强弱的关键便在于如何针对不同的请求性质来设计最优并发策略,这在后续章节中会有详细介绍。同时也是因为有时候一台服务器要同时处理诸多不同性质的请求,在一定程度上使得Web服务器的性能无法充分发挥,这很容易理解,就像银行对不同业务设立不同的窗口一样,这些窗口的服务员分别熟悉自己的窗口业务,可以为不同的客户分别快速办理业务,但是如果让这些窗口都可以办理所有业务,也就是客户可以去任何窗口办理任何业务,那会怎么样呢?相信没有几个银行业务员会对所有的业务都轻车熟路,这样势必会影响到整体的业务办理速度。
压力测试的前提条件
如果我们要统计吞吐率,便存在一些潜在的前提,那就是压力的描述和请求性质的描述。压力的描述一般包括两部分,即并发用户数和总请求数,也就是模拟多少个用户同时向服务器发送多少个请求,随后会有关于并发用户数的详细介绍。
请求性质则是对请求的URL所代表的资源的描述,比如lKB大小的静态文件,或者包含10次数据库查询的动态内容等。
所以,吞吐率的前提包括如下几个条件:
?并发用户数
?总请求数
?请求资源描述
并发用户数
前面提到了并发用户数,在我们开始进行压力测试之前,一定要弄明白它的含义。简单地说,并发用户数就是指在某一时刻同时向服务器发送请求的用户总数。如此多的用户同时请求服务器,显然会给服务器带来不小的压力,这时你可能有一个实际的问题,假如100个用户同时向服务器分别进行10次请求,与1个用户向服务器连续进行1000次请求,效果一样吗?也就是说,给服务器带来的压力一样吗?
虽然看起来服务器都需要连续处理1000个请求,其实关键的区别就在于,是否真的“连续”。首先有一点需要明白,对于压力测试中提到的每一个用户,连续发送请求实际上是指在发送一个请求并接收到响应数据后再发送下一个请求。这样一来,从微观层面来看,1个用户向服务器连续进行1000次请求的过程中,任何时刻服务器的网卡接收缓冲区中只有来自该用户的1个请求,而100个用户同时向服务器分别进行10次请求的过程中,服务器网卡接收缓冲区中最多有100个等待处理的请求,显然,这时候服务器的压力更大。
其实,并发用户数这个词你也许经常听到,很多时候它还有一些别名,比如并发数、并发连接数等。经常会有人说某个Web服务器能支持多少并发数,除此之外,没有任何上下文,这让很多人摸不着头脑,人们常常把并发用户数和吞吐率混淆,实际上,它们并不是一回事,通过前面的介绍,我们很清楚,吞吐率是指在一定并发用户数的情况下,服务器处理请求能力的量化体现。
那么,说一个服务器最多支持多少并发用户数,这个“最多”到底是什么意思?这里我们暂且抛开技术的因素,从广义的角度来看,举个生活中的例子,比如某商城里有一个柜台,给顾客们办理业务。刚开始顾客稀少,一次只来一个顾客,柜台业务员很轻松就可以搞定,不久,有很多顾客去柜台办理业务,大家排成一个长队依次办理,每个顾客在办理业务的过程中,都需要花时间填写一些资料,这时候其他顾客就得等着,而且柜台业务员闲着无聊又不能干别的事情,所以他觉得很浪费时间,就让大家排成两队,这样在等待的时候就给另一个队办理。可是填写资料的时间有点长,另一队的顾客开始填写资料时,前一个队的顾客还没填完,业务员还是得等。最后队伍增加到了10队,10个人同时办理业务,刚好业务员不用等待任何顾客了,而且每个顾客对办理速度也很满意。
随着前来办理业务的顾客越来越多,业务员想做点有挑战性的事情,他将队伍增加到了20队,同时给20个顾客办理业务,这下20条队伍拥挤不堪,原本轻松的保安为了维持秩序累得气喘吁吁,这还不算,关键是业务员的办理速度已经赶不上大家填写资料的速度了,一些人填完资料后没人搭理,便开始抱怨,业务员也因为同时要给很多人办理业务,脑子反应不过来,导致处理原本熟悉的业务时也变得手忙脚乱,效率下降且时常伴随一些低级失误。
终于,在大家的一片声讨下,柜台崩溃了。注意,柜台的崩溃不是因为业务员无法继续工作了,虽说他忙得累死累活,但是活儿还得干啊,关键是顾客们等得不耐烦了,大部分顾客都无法忍受长时间的等待以及办理过程中出现的错误,所以投诉到了商城的管理处,商城只好暂时关闭柜台业务,商讨对策。
很快,商城又恢复了柜台业务,将柜台的队伍数调整到10队,同时根据顾客流量,临时增设一定数量的柜台,这样一来,顾客们纷纷表示满意。
我们可以说,这个柜台支持的最大并发数为10,因为恰好在这个并发数下,柜台业务开展得非常成功,顾客们都对服务时间非常满意,而且此时代表业务办理次数的柜台吞吐率也比较高,商城和顾客实现双赢。当并发数少于10的时候,柜台业务员的时间得不到充分利用,浪费了柜台的宝贵资源,这时候的吞吐率要低一些。而当并发数大于10的时候,事实证明,顾客们不乐意了。这样看来,问题的本质变得非常清晰,似乎就是商家和顾客的博弈,而且是合作型博弈,最大并发数便是博弈的结果,也是最大程度的共赢。
可见,通常所讲的最大并发数是有一定利益前提的,那就是服务器和用户双方所期待的最大收益,服务器希望支持高并发数及高吞吐率,而用户不管那么多,只希望等待较少的时间,或者得到更快的下载速度,显然,双方不可能都彻底满足,所以便存在讨价还价的余地,同时双方也都有能够忍受的最低尺度。从经济学的角度看,就这么简单,所以找到双方利益的平衡点,便是我们所希望的最大并发用户数。这种现象在后续章节中介绍下载服务的时候还会提到。
当然,经过权衡后,我们所希望的最大并发用户数还存在一定的技术制约,这也是狭义层面的最大并发数的定义。柜台的故事只是一个简单的模型,而在我们访问实际的Web站点时,每个请求的处理过程并不像柜台业务员给顾客办理业务那么简单,尤其是在并发用户数较大的情况下,Web服务器使用什么样的并发策略,是影响最大并发数的关键。
另外值得说明的是,即使我们通过压力测试得出服务器支持的最大并发数,但这与实际并发用户数却是两回事,因为有多少用户同时发来请求并不是服务器所能决定的,该来的总是要来,那是客观存在的。一旦实际并发用户数大于服务器所能支持的最大并发数,那必然造成一部分用户需要等待超过预期的时间,影响了站点的服务质量。所以,得出最大并发数的意义,在于了解服务器的承载能力,并且结合用户规模考虑适当的扩展方案。从站点的某些商业角度来看,最大并发用户数的支持程度往往比吞吐率更加容易理解。
在考虑实际用户规模的时候,我们还需要了解一点,用户访问Web站点通常使用浏览器,而浏览器在下载一个网页以及网页中的多个组件时,采用多线程的并发下载方式,但是对于同一域名下URL的并发下载数是有最大限制的,具体限制视浏览器的不同而不同,比如,在:HTTP/1.1下,IE 7支持两个并发连接,IE 8支持6个并发连接,Firefox 3支持4个并发连接,我们使用诸如HttpWateh这样的HTTP监视工具可以很清晰地看到这一点。所以,我们前面说到的服务器支持的最大并发数,具体到真实的用户,可能并不是一对一的关系,一个真实的用户可能会给服务器带来两个或更多的并发用户数的压力,一些高明的用户还可以通过一些方法来修改浏览器的并发数限制。而我们在本书中为了简化模型,暂且认为每个用户的并发下载数均为1。
另一方面,从Web服务器的角度来看,实际并发用户数也可以理解为Web服务器当前维护的代表不同用户的文件描述符总数,也就是并发连接数,当然,不是同时来了多少用户请求就建立多少连接,Web服务器一般会限制同时服务的最多用户数,比如Apache的MaxClients参数,所以这个实际并发用户数,有时候大于服务器所维护的文件描述符总数,而多出的这些用户请求,则在服务器内核的数据接收缓冲区中等待处理,所以这些请求在用户看来处于阻塞状态。
喜欢构建高性能Web站点(修订版) [平装]请与您的朋友分享,由于版权原因,读书人网不提供图书下载服务