Web缓存技术概述

Web缓存技术概述
Web缓存技术概述

Web缓存技术概述

[日期:2006-05-31] 来源:作者:[字体:大中小]

王世克吴集金士尧

摘要WWW是互联网上最受欢迎的应用之一,其快速增长导致网络拥塞和服务器超载,缓存技术被认为是减轻服务器负载、降低网络拥塞,减少客户访问延迟的有效途径之一。本文首先描述了Web缓存系统的基本要素及理想属性,然后介绍目前围绕Web缓存技术已经开展的研究,最后讨论Web缓存技术需要进一步研究的问题。

关键字WWW 缓存技术代理

1 引言

WWW是互联网上最受欢迎的应用之一,其快速增长造成网络拥塞和服务器超载,导致客户访问延迟增大,WWW服务质量问题日益显现出来。缓存技术被认为是减轻服务器负载、降低网络拥塞、增强WWW可扩展性的有效途径之一,其基本思想是利用客户访问的时间局部性(Temporal Locality)原理,将客户访问过的内容在Cache中存放一个副本,当该内容下次被访问时,不必连接到驻留网站,而是由Cache中保留的副本提供。

Web内容可以缓存在客户端、代理服务器以及服务器端。研究表明,缓存技术可以显著地提高WWW性能[1][2],它可以带来以下好处:

(1)减少网络流量,从而减轻网络拥塞;

(2)降低客户访问延迟,其主要原因有:①缓存在代理服务器中的内容,客户可以直接从代理获取而不是从远程服务器获取,从而减小了传输延迟;②没有被缓存的内容由于网络拥塞及服务器负载的减轻而可以较快地被客户获取;

(3)由于客户的部分请求内容可以从代理处获取,从而减轻了远程服务器负载;

(4)如果由于远程服务器故障或网络故障造成远程服务器无法响应客户请求,客户可以从代理中获取缓存的内容副本,使得WWW服务的鲁棒性(Robustness)得到了加强。Web缓存系统也会带来以下问题:

(1)客户通过代理获取的可能是过时的内容;

(2)如果发生缓存失效,客户的访问延迟由于额外的代理处理开销而增加。因此在设计W eb缓存系统时,应力求做到Cache命中率最大化和失效代价最小化;

(3)代理可能成为瓶颈。因此应为一个代理设定一个服务客户数量上限及一个服务效率下限,使得一个代理系统的效率至少同客户直接和远程服务器相连的效率一样。

目前,围绕Web缓存系统及其最优化问题已经开展了广泛而深入的研究,这些研究工作主要是围绕代理的作用展开的。

2 Web缓存系统的理想特性

一个理想的Web缓存系统应具有以下特性:

(1)快捷性:缓存系统应该能够有效地降低客户的访问延迟;

(2)鲁棒性:鲁棒性意味着可用性,客户希望Web服务随时可用;

(3)透明性:缓存系统对客户应是透明的,客户得到的结果仅仅是快速的响应和良好的可用性;

(4)可扩展性:Web缓存系统应能够随着网络规模和密度的不断增长而很好地进行扩展;(5)高效性:Web缓存系统给网络带来的开销越小越好;

(6)适应性:缓存系统能够适应客户请求和网络环境的动态变化,这涉及到缓存管理、缓存路由、代理配置等,对于获得理想的缓存性能至关重要;

(7)稳定性:Web缓存系统采用的方案不应给网络带来不稳定;

(8)负载均衡:一个理想的缓存方案应能够将负载均匀地分发到整个网络,以避免某一个代理或服务器成为瓶颈或Hot spot点,而造成系统一部分甚至整个系统性能下降;

(9)异构处理能力:随着网络规模和覆盖域的不断增大,网络将跨越一系列不同的硬件和软件体系结构。Web缓存系统应能够适应不同的网络体系结构;

(10)简单性:简单的方案容易实现且易被普遍接受,一个理想的Web缓存方案配置起来应简单易行。

围绕上述特性,一个Web缓存系统必须解决好以下问题:

(1)缓存体系结构:缓存代理在网络中如何组织和配置;

(2)代理合作:代理间如何合作,相互合作的代理可以提高命中率而改善缓存系统的性能;(3)缓存路由:当一处缓存代理失效时,如何将请求向其它缓存代理转发;

(4)缓存替换算法:当缓存空间不够时,缓存内容如何替换;

(5)缓存一致性:即缓存内容的时效性问题,如何防止缓存的内容过时;

(6)内容预取:代理如何决定从服务器或其它代理处进行内容预取以减少客户的访问延迟;(7)负载平衡:如何解决网络中的“Hot spot”现象;

(8)缓存内容:什么样的内容可以被缓存。

在设计Web缓存系统时,必须涉及上述问题。

3 Web缓存方案概述

3.1 Web缓存体系结构

一个Web缓存系统的性能取决于其客户群的大小,客户群越大,缓存的内容被再次请求的可能性就越高。相互合作的Cache组可能会提高命中率而提高缓存系统的性能,因此缓存系统的体系结构应确保代理间能够有效地进行合作。典型的缓存体系结构有以下几种:层次式、分布式和混合式。

图1 Web缓存系统体系结构图

3.1.1 层次式缓存体系结构

Harvest项目[3]首先提出了层次式Web缓存体系结构。在层次式缓存体系结构中,Cache

在网络呈多级配置,如图1(a)所示。为简单起见,假定有四级:底层Cache、局域层C ache、区域层Cache、广域层Cache。底层是客户/浏览器Cache,当客户端Cache不能满足客户的请求时,该请求被转发到局域层Cache,如果仍然得不到满足,则该请求被转发到区域层Cache直至广域层Cache。如果该请求在各级Cache中都得不到满足,则请求最终被转发到服务器。然后服务器对该请求的响应自顶向下地发送给客户,在沿途的每一个中间层Cache中留下一个副本。请求相同内容的其它请求则自下而上地进行转发,直到在某一级Cache中得到满足。

层次式缓存体系结构带宽效率高,点击率较高的Web内容可以快速高效地分布到网络中。但该体系结构也存在一些不足[4]:

(1)建立层次式缓存体系结构,缓存服务器必须配置在网络中关键的访问点上,缓存服务器间需相互合作;

(2)每一级Cache都会带来额外的延迟;

(3)高层Cache可能会成为瓶颈并带来较长的排队延迟;

(4)同一个内容的多个副本被保存在不同的Cache中,整个系统Cache空间利用率不高。

3.1.2 分布式缓存体系结构

针对层次式缓存结构的上述缺陷,一些研究者提出了分布式缓存体系结构,在这种结构中,只有低层Cache,如图1(b)所示。文献[5]中的分布式Web缓存结构中,没有超出局域层的中间Cache层,Cache之间相互协作以处理失效。为了确定将客户请求转发给哪一个局

域层Cache来获取失效的内容,每一个局域层Cache保留一份其它局域层Cache中缓存内容的目录信息,以便发生失效时将客户请求准确地转发到相应的局域层Cache。缓存阵列路由协议CARP[6](Cache Array Routing protocol)是一种分布式缓存方案,它将UR L空间分割成不同的部分,将每一部分指定给一组松散耦合的Cache组,每个Cache只能缓存具有指定给它的URL的Web内容,从而可以根据客户请求内容的URL来确定将请求转发给哪一个Cache。

在分布式缓存结构中,大多数的网络流量都发生在网络底层,不容易产生网络拥塞,Cach e空间利用率高,且可以更好地实现负载共享,容错性更好。然而,一个大规模的分布式缓存系统的配置可能会遇到几个问题:连接次数较多、带宽要求高、管理困难[4]。

3.1.3 混合式缓存体系结构

混合式体系结构如图1(c)所示,同级Cache采用分布式缓存结构,相互合作。Harvest 集团设计的互联网缓存协议ICP(the Internet Cache Protocol)支持从RTT最小的父Ca che或邻居Cache中获取相应的内容。

3.1.4 缓存体系结构的优化

研究表明[4]层次式缓存体系结构和分布式缓存结构相比,层次式缓存体系结构具有较短的连接时间,因此将较小的文档缓存在中间层Cache中可以减少访问延迟;分布缓存结构具有较短的传输时间和较高的带宽利用率。理想的方案就是将二者结合起来,充分发挥各自的长处,同时减少连接时间和传输时间。

3.2 缓存路由

出于对Web缓存系统扩展性的考虑,大多数缓存系统将大量的Cache分散在互联网上,这样带来的最大问题是如何快速地定位缓存有所需内容的Cache,这就是缓存路由问题。该问题有点类似于网络路由,但却不能用同样的方式解决。传统的网络路由可依地址聚类(层次式的地址表示使得地址聚类成为可能)而进行,但是在WWW中,具有相同URL前缀或服务器地址前缀的文档未必发送给相同的客户,难以对路由地址进行聚类,这样缓存路由表将大得难以管理。此外,缓存内容不断更新,过时的缓存路由信息将导致缓存失效。为降低Cache失效的代价,理想的缓存路由算法应该将客户的请求路由到下一个代理,该代理具有较高的命中可能性且位于或接近于客户到服务器的网络路径上。

3.2.1 缓存路由表法

Malpani等人[7]将一组Cache组合起来,当客户的请求被转发到指定的Cache时,如果该Cache缓存有请求的内容,则将其发送给客户,否则通过IP组播将请求转发给同组的其它Cache,由缓存有相应内容的Cache对客户的请求进行响应,如果所有Cache中都没有缓存请求的内容,则该请求被转发到源服务器。Harvest[3]缓存系统将Cache组织成层次式结

构并使用Cache解析协议ICP(Internet Cache Protocol),当发生Cache失效时,低层Cache在将客户请求转发到上一层Cache前,首先查询兄弟节点Cache是否缓存有相应的内容,以避免顶层Cache超载。自适应Web缓存系统[8]为每一个服务器建立Cache树,树中的Cache被组织成相互重叠的多点传送组,一个请求通过这些传送组来获取相应的缓存内容。该方法对每一个服务器构造不同的Cache树,因此没有根结点的超载问题,自配置性和鲁棒性都比较好。但是对点击率较低的内容请求可能会经过较多的Cache,产生较大的Cache通信开销,作者建议通过限制请求经过的Cache数来解决该问题。

3.2.2 哈希函数法

Cache阵列路由协议CARP[6]使用一个基于阵列成员列表和URL的哈希函数来确定一个W eb对象确切的缓存地址或一个Web对象应缓存在什么地方。在Summary Cache[9]中,每个代理保存一个同组中其它代理所缓存内容的URL摘要信息,该代理在转发客户请求时检查这些摘要信息以确定将请求转发给哪一个代理。为减小开销,这些摘要信息定期进行更新。试验表明该系统可以显著地减少Cache间的信息数量、带宽消耗以及协议带来的CPU开销,而保持和ICP几乎一样的缓存命中率。

3.3 Cache替换算法

Cache替换算法是影响代理缓存系统性能的一个重要因素,一个好的Cache替换算法可以产生较高的命中率。目前已经提出的算法可以划分为以下三类:

(1)传统替换算法及其直接演化,其代表算法有:①LRU(Least Recently Used)算法:将最近最少使用的内容替换出Cache;②LFU(Lease Frequently Used)算法:将访问次数最少的内容替换出Cache;③Pitkow/Recker[10]提出了一种替换算法:如果Cache中所有内容都是同一天被缓存的,则将最大的文档替换出Cache,否则按LRU算法进行替换。(2)基于缓存内容关键特征的替换算法,其代表算法有:①Size[10]替换算法:将最大的内容替换出Cache;②LRU—MIN[11]替换算法:该算法力图使被替换的文档个数最少。设待缓存文档的大小为S,对Cache中缓存的大小至少是S的文档,根据LRU算法进行替换;如果没有大小至少为S的对象,则从大小至少为S/2的文档中按照LRU算法进行替换;③LRU—Threshold[11]替换算法:和LRU算法一致,只是大小超过一定阈值的文档不能被缓存;④Lowest Lacency First[12]替换算法:将访问延迟最小的文档替换出Cache。

(3)基于代价的替换算法,该类算法使用一个代价函数对Cache中的对象进行评估,最后根据代价值的大小决定替换对象。其代表算法有:①Hybrid[12]算法:算法对Cache中的每一个对象赋予一个效用函数,将效用最小的对象替换出Cache;②Lowest Relative Value[1 3]算法:将效用值最低的对象替换出Cache;③Least Normalized Cost Replacement(L CNR)[14]算法:该算法使用一个关于文档访问频次、传输时间和大小的推理函数来确定替

换文档;④Bolot等人[15]提出了一种基于文档传输时间代价、大小、和上次访问时间的权重推理函数来确定文档替换;⑤Size—Adjust LRU(SLRU)[16]算法:对缓存的对象按代价与大小的比率进行排序,并选取比率最小的对象进行替换。

总之,为了使Cache命中率最大化,围绕Cache替换算法已经开展了大量的工作,但是替换算法的性能很大程度上取决于WWW访问的特性,还没有哪一种替换算法能够对所有W eb访问模式都优于其它算法。

3.4 缓存一致性

Web缓存系统可以减小访问延迟,但带来了一个副作用:缓存的副本提供给客户的可能是过时的内容,因此必须有一套缓存一致性机制来确保缓存的内容能够及时进行更新及有效性确认,以便为客户提供最新的内容。

目前主要有两种缓存一致性类型:强缓存一致性和弱缓存一致性。

3.4.1 强缓存一致性

(1)客户端确认:对于每一次访问,代理都认为缓存的内容已经过时并随请求发送一个“I F—Modified —Since—date”报头到服务器。如果在指定的时间后该内容发生了变化,则服务器将更新后的内容发送给代理并最终发送给客户;如果请求内容未修改,则发回“304”响应,表示文档未修改,缓存内容继续有效。

(2)服务器确认:当服务器检测到一个内容发生变化时,服务器向所有最近请求过该内容并有可能缓存该内容的客户发送作废信息[17]。该方法要求服务器必须保存一个访问该内容的客户链表以便发送作废信息,当客户数量很大时,该方法将变得不适用,同时,该链表本身也可能过时,造成服务器向许多已经不再缓存该内容的客户发送作废信息。

3.4.2 弱缓存一致性

(1)自适应TTL[18](Time To Live)机制:通过观察一个文档的生存期来调整其生存时间,从而解决缓存一致性问题。如果一个文档在一个相当长的时间内都未修改过,它往往不会再发生变化。这样,一个文档的生存期属性被赋予一个该文档目前“年龄”(等于目前时间减去上一次修改的时间)的百分比。自适应TTL法可以将一个文档过时的可能性控制在<5%的范围内。大多数的代理服务器都使用该机制,但是这种基于文档生存期的缓存一致性机制并不能确保缓存内容的有效性。

(2)捎带作废机制

Krishnamurthy等人提出使用捎带作废机制来提高缓存一致性的效率。他们提出了三种机制:①捎带确认PCV[19](Piggyback Cache Validation)机制:利用代理发送给服务器的请求来提高缓存一致性。例如,当一个代理向服务器发出请求时,它捎带一系列缓存的但可能过时的来自该服务器的内容进行有效性确认;②捎带作废PSI[20](Piggyback Service I

nvalidation)机制:其基本思想是当服务器对代理进行响应时,把一系列上次代理访问后变化的内容告诉代理服务器并由代理将这些内容作废,从而延长其它缓存内容在Cache中的缓存时间;③PSI和PCV混合机制[21]:该机制根据代理上次请求作废的时间距当前时间间隔的大小来确定采用何种机制,以实现最佳的总体性能。如果这个时间间隔较小,则使用P SI机制,否则使用PCV机制来对缓存内容进行确认。其基本原理是时间间隔越小,与PSI 一起发送的作废数量就小,但随着时间的增长,发送作废的开销将大于请求确认的开销。3.5 内容预取

Web缓存技术可以提高Web性能,但研究表明[22],不管采用何种缓存方案,最大缓存命中率通常不大于40~50%。为进一步提高缓存命中率,引入了预取技术。预取技术本质上是一种主动缓存技术,其基本思想是在处理客户的当前请求时,利用客户访问内容或模式的先验知识,对客户接下来的请求内容进行预测,并利用客户请求的间隙将预测内容缓存在Ca che中,从而更好地隐藏延迟,提高服务质量。

早期研究集中在浏览器/客户与Web服务器之间进行内容预取,当代理被引入后,人们的研究兴趣转到了代理与服务器之间的预取技术研究。研究表明预取技术可以有效地降低客户访问延迟,但预取技术仍饱受争议,原因有二:

(1)内容预取是一种实时性要求较高的任务,它主要利用客户请求的间隔进行,而这个间隔一般情况下小于一分钟[23],如果在这段时间内不能完成预取任务,预取将变得毫无意义。因此对预取算法的效率有较高的要求。

(2)内容预取是通过加重服务器负载及增加网络流量为代价来降低客户端响应时间的,因此对预取的准确度有较高的要求。同时,一个预取模型在确定预取文档的数量时,必须考虑客户的访问特性、服务器负载及网络流量状况,如果抛开这些因素来进行预取可能会造成事与愿违的效果。

总之,一个良好的预取模型,效率、准确度要高,付出代价小。围绕预取的高效性和准确性还需做进一步的研究。

3.5 负载平衡

当众多客户同时从一台服务器获取数据或服务时就会发生Hot Spot现象,导致服务器性能下降甚至失效。目前处理该问题的方法大多数是使用某些复制策略将被请求的内容分贮在互联网上,从而将负载分散到多个服务器(代理)上[24],避免单个服务器成为为瓶颈。

3.6 缓存内容

一个代理可能发挥多种作用,除进行数据缓存外还可以进行连接缓存和计算缓存。连接缓存指在客户与代理、代理与服务器间使用持久连接,来减少建立TCP连接开销及服务器发送时的慢起动开销,从而减小客户访问延迟时间[25]。计算缓存可以看作是Web服务器可以将

它们的部分服务迁移到代理,以减轻服务器瓶颈,其应用之一就是动态数据缓存,通过代理来缓存动态数据并将一部分计算迁移到代理,由代理来产生和维护缓存的动态数据,从而提高客户获取动态数据的性能。

4 需要进一步研究的问题

围绕Web缓存技术已经开展了大量的研究并取得了丰硕成果,但仍有一些问题需做进一步的研究。这些问题包括:

(1)客户访问模式研究:通过研究客户的访问模式,从而更好地进行缓存管理和内容预取,提高缓存命中率;

(2)动态数据缓存:目前Web缓存命中率不高的一个重要原因是相当一部分内容(私有数据、授权数据、动态数据等)不能被缓存。如何使得更多的数据可以缓存以及如何减小客户访问非缓存页面的访问延迟已经成为提高Web性能的关键问题;

(3)Web流量特征:缓存系统的效率在于Web访问流的时间局部性以及良好的Cache管理策略,理解Web客户产生的负载特性对于更好地设计和提供Web服务具有重要意义;(4)代理配置:要获得良好的Web性能,代理的配置至关重要,代理配置策略的理想标准是:自组织、高效路由、负载均衡、行为稳定等,围绕此问题还需做进一步的研究。

总之,提高Web性能的前沿研究在于开发扩展性、鲁棒性、适应性、稳定性好、高效且能够较好地配置在当前及今后网络中的缓存方案。

参考文献

[1] R. Caceres, F. Douglis, A. Feldmann, G. Glass, and M. Rabinovich, Web proxy caching: the devil is in the details, ACM Performance Evaluation Review, 26 (3): pp. 11-15, December 1998.

[2] B. M. Duska, D. Marwood, and M. J. Feelay, The measured access chara cteristics of World Wide Web client proxy caches, Proceedings of USENIX Symposi um on Internet Technologies and Systems (http://cs.ubc.ca/spider/feeley/wwwap/ww wap.html).

[3] A. Chankhunthod, P. B. Danzig, C. Neerdaels, M. F. Schwartz, and K. J. Worrel, A hierarchical Internet object cache, Usenix’96, January 1996.

[4] P. Rodriguez, C. Spanner, and E. W. Biersack, Web caching architectures: hierarchical and distributed caching, Proceedings of WCW’99.

[5] R. Tewari, M. Dahlin, H. Vin, and J. Kay, Beyond hierarchies: design con siderations for distributed caching on the Internet, Technical Report TR98-04, Depar tment of Computer Science, University of Texas at Austin, February 1998.

[6] V. Valloppillil and K. W. Ross, Cache array routing protocol v1.0, Internet Draft _ draft- vinod-carp-v1-03.txt

[7] R. Malpani, J. Lorch, and D. Berger, Making World Wide Web caching se rvers cooperate, Proceedings of the 4th International WWW Conference, Boston, M A, Dec. 1995

[8] E. Cohen, B. Krishnamurthy, and J. Rexford, Evaluating server-assisted ca che replacement in the Web, Proceedings of the European Symposium on Algorith ms-98, 1998.

[9] L. Fan, P. Cao, J. Almeida, and A. Z. Broder, Summary cache: a scalabl

e wide-area Web cache sharing protocol, Proceedings o

f Sigcomm’98.

[10] S. Williams, M. Abrams, C. R. Standridge, G. Abdulla, and E. A. Fox, Re moval policies in network caches for World-Wide Web documents, Proceedings of Sigcomm’96.

[11] M. Abrams, C. R. Standridge, G. Abdulla, S. Williams, and E. A. Fox, Cac hing proxies: limitations and potentials, Proceedings of the 4th International WWW Conference, Boston, MA, Dec. 1995.

[12] R. P. Wooster and M. Abrams, Proxy caching that estimates page load de lays, Proceedings of the 6th International WWW Conference, April 1997 (http://www. https://www.360docs.net/doc/2818046784.html,/ chitra/docs/www6r/).

[13] P. Lorenzetti, L. Rizzo, and L. Vicisano, Replacement policies for a proxy cache .

[14] P. Scheuermann, J. Shim, and R. Vingralek, A case for delay-conscious c aching of Web documents, Proceedings of the 6th International WWW Conference, Santa Clara, Apr. 1997.

[15] J. C. Bolot and P. Hoschka, Performance engineering of the World-Wide Web: Application to dimensioning and cache design, Proceedings of the 5th Interna tional WWW Conference, Paris, France, May 1996.

[16] C. Aggarwal, J. L. Wolf, and P. S. Yu, Caching on theWorld Wide Web, I EEE Transactions on Knowledge and data Engineering, Vol. 11, No. 1, January/Fe bruary 1999.

[17] P. Cao and C. Liu, Maintaining strong cache consistency in theWorld Wide Web, Proceedings of the 17th IEEE International Conference on Distributed Comput ing Systems, May 1997.

[18] V. Cate, Alex - a global file system, Proceedings of the 1992 USENIX File System Workshop, pp. 1-12, May 1992.

[19] B. Krishnamurthy and C. E.Wills, Study of piggyback cache validation for p roxy caches in the World Wide Web, Proceedings of the 1997 USENIX Symposium on Internet Technology and Systems, pp. 1-12, December 1997.

[20] B. Krishnamurthy and C. E. Wills, Piggyback server invalidation for proxy c ache coherency, Proceedings of the WWW-7 Conference, pp. 185-194, 1998. [21] B. Krishnamurthy and C. E. Wills, Proxy cache coherency and replacement - towards a more complete picture, ICDC99, June 1999.

[22] F. Douglis, A. Feldmann, B. Krishnamurthy, and J. Mogul, Rate of change and other metrics: a live study of the World-Wide Web, Proceedings of the 1997 Usenix Symposium on Internet Technologies and Systems (USITS-97), Dec. 1997.

[23] B. Krishnamurthy and J. Rexford. Web Protocols and Practice : HTTP 1.1, Networking Protocols, Caching, and Tra_c Measurement. Addison-Wesley, 2001. [24] P. Barford, A. Bestavros, A. Bradley, and M. E. Crovella, Changes in Web client access patterns: characteristics and caching implications, World Wide Web (special issue on Characterization and Performance Evaluation), 1999.

[25] A. Feldmann, R. Caceres, F. Douglis, G. Glass, and M. Rabinovich, Perfor mance of Web proxy caching in heterogeneous bandwidth environments, Proceedin gs of Infocom’99

web cache缓存技术的概述与举例

1.1 宽带用户需求分析 面对主流宽带运营商(电信、联通)的强大资源优势,移动、广电处于不利局面。申请和使用线路会遇到一定麻烦,同时电信与联通的互访速度慢、国内访问国外网站的速度慢,都会造成用户体验下降。 同时使用大量带宽的大学、职业学院、大企业也会面临同样的问题。 通过下面几节分析我们认为,使用基于HTTP协议的CACHE,将显著降低基于HTTP协议的小数据包的应用,有助于明显优化客户体验,节省大量带宽资源。同时,基于HTTP的CACHE 将解决在线web视频的问题,极大地提升了在线视频的客户体验。 同时,采用P2P协议的其它部分视频内容由于大型视频网站如迅雷的采用加密算法,目前没有有效地P2PCACHE解决方案,建议与原服务提供商联系得到其授权的镜像服务器。 以上网络问题可以用web Cache 来解决,即增加用户带宽体验,减少网络带宽流量。 例如:可以通过MARA SYSTEM(迈锐赛腾)的高性能加速加速平台CACHEMARA,解决了处理HTTP小包过程中所面临的问题,一、大量HTTP小包所产生的短连接形成的连接的成本消耗。二、大量HTTP小包的频繁读取对存储介质所产生的巨大压力。而CACHEMARA最高端型号的单台设备的HTTP小包处理能力可支持到1.5Gbps,业界仅有其能实现这一点。(下面我们也将以CACHEMARA来做参考) 更详细的信息,请访问https://www.360docs.net/doc/2818046784.html, 或https://www.360docs.net/doc/2818046784.html,

1.2 目前网络应用的协议及用户群分析 据统计用户上网的基本应用按照协议分类为:

Web网站架构详解

Web网站架构详解

前言 俗话说得好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的,当然对于我们开发人员来说,一个好的架构也不是一蹴而就的。 初始搭建 开始的开始,就是各种框架一搭,然后扔到Tomcat容器中跑就是了,这时候我们的文件、数据库、应用都在一个服务器上。 服务分离

随着系统的的上线,用户量也会逐步上升,很明显一台服务器已经满足不了系统的负载,这时我们就要在服务器还没有超载时,提前做好准备。 由于我们是单体架构,优化架构在短时间内是不现实的,增加机器是一个不错的选择。这时,我们可能要把应用和数据库服务单独部署,如果有条件也可以把文件服务器单独部署。 反向代理

为了提升服务处理能力,我们在Tomcat容器前加一个代理服务器,我一般使用Nginx,当然你如果更熟悉Apache也未尝不可。 用户的请求发送给反向代理,然后反向代理把请求转发到后端的服务器。 严格意义上来说,Nginx是属于Web服务器,一般处理静态HTML、CSS、JS请求,而Tomcat 属于Web容器,专门处理JSP请求,当然Tomcat也是支持html的,只是效果没Nginx 好而已。 反向代理的优势,如下: o隐藏真实后端服务 o负载均衡集群 o高可用集群 o缓存静态内容实现动静分离

o安全限流 o静态文件压缩 o解决多个服务跨域问题 o合并静态请求(HTTP/2.0后已经被弱化) o防火墙 o SSL以及http2 动静分离

基于以上Nginx反向代理,我们还可以实现动静分离,静态请求如HTML、CSS、JS等请求交给Nginx处理,动态请求分发给后端Tomcat处理。 Nginx 升级到1.9.5+可以开启HTTP/2.0时代,加速网站访问。 当然,如果公司不差钱,CDN也是一个不错的选择。 服务拆分 在这分布式微服务已经普遍流行的年代,其实我们没必要踩过多的坑,就很容易进行拆分。市面上已经有相对比较成熟的技术,比如阿里开源的Dubbo(官方明确表示已经开始维护了),Spring家族的Spring Cloud,当然具体如何去实施,无论是技术还是业务方面都要有很好的把控。

Web缓存技术概述

Web缓存技术概述 [日期:2006-05-31] 来源:作者:[字体:大中小] 王世克吴集金士尧 摘要WWW是互联网上最受欢迎的应用之一,其快速增长导致网络拥塞和服务器超载,缓存技术被认为是减轻服务器负载、降低网络拥塞,减少客户访问延迟的有效途径之一。本文首先描述了Web缓存系统的基本要素及理想属性,然后介绍目前围绕Web缓存技术已经开展的研究,最后讨论Web缓存技术需要进一步研究的问题。 关键字WWW 缓存技术代理 1 引言 WWW是互联网上最受欢迎的应用之一,其快速增长造成网络拥塞和服务器超载,导致客户访问延迟增大,WWW服务质量问题日益显现出来。缓存技术被认为是减轻服务器负载、降低网络拥塞、增强WWW可扩展性的有效途径之一,其基本思想是利用客户访问的时间局部性(Temporal Locality)原理,将客户访问过的内容在Cache中存放一个副本,当该内容下次被访问时,不必连接到驻留网站,而是由Cache中保留的副本提供。 Web内容可以缓存在客户端、代理服务器以及服务器端。研究表明,缓存技术可以显著地提高WWW性能[1][2],它可以带来以下好处: (1)减少网络流量,从而减轻网络拥塞; (2)降低客户访问延迟,其主要原因有:①缓存在代理服务器中的内容,客户可以直接从代理获取而不是从远程服务器获取,从而减小了传输延迟;②没有被缓存的内容由于网络拥塞及服务器负载的减轻而可以较快地被客户获取; (3)由于客户的部分请求内容可以从代理处获取,从而减轻了远程服务器负载; (4)如果由于远程服务器故障或网络故障造成远程服务器无法响应客户请求,客户可以从代理中获取缓存的内容副本,使得WWW服务的鲁棒性(Robustness)得到了加强。Web缓存系统也会带来以下问题: (1)客户通过代理获取的可能是过时的内容; (2)如果发生缓存失效,客户的访问延迟由于额外的代理处理开销而增加。因此在设计W eb缓存系统时,应力求做到Cache命中率最大化和失效代价最小化; (3)代理可能成为瓶颈。因此应为一个代理设定一个服务客户数量上限及一个服务效率下限,使得一个代理系统的效率至少同客户直接和远程服务器相连的效率一样。

大型WEB网站架构深入分析_缓存

缓存 1介绍 缓存就是利用本地参考原则:当CPU要读取一个数据时,首先从缓存中查找,找到就立即读取并送给CPU处理;没有找到,就用相对慢的速率从内存中读取并送给CPU处理,同时把这个数据所在的数据块调入缓存中,可以使得以后对整块数据的读取都从缓存中进行,不必再调用内存。它们几乎被用在每一个计算层上:硬件、操作系统、Web浏览器、Web应用程序等。一个缓存就相当于是一个临时内存:它有一个有限的空间量,但访问它比访问原始数据速度要快。缓存也可以存在于各个层的架构中,但经常在离前端最近的那个层上发现,在那里可以快速实现并返回数据,无需占用下游层数据。 那么如何利用缓存使数据访问更快呢在这种情况下,有许多地方可以插入缓存。一种是在请求层节点上插入缓存,如图1所示。 图 1 在请求层节点插入缓存 在请求层节点上放置一个缓存,即可响应本地的存储数据。当对服务器发送一个请求时,如果本地存在所请求数据,那么该节点即会快速返回本地缓存数据。如果本地不存在,那么请求节点将会查询磁盘上的数据。请求层节点缓存即可以存在于内存中(这个非常快速)也可以位于该节点的本地磁盘上(比访问网络存储要快)。

图2 多个缓存 ] 当扩展到许多节点的时候,会发生什么呢如图2所示,如果请求层被扩展为多个节点,它仍然有可能访问每个节点所在的主机缓存。然而,如果你的负载均衡器随机分布节点之间的请求,那么请求将会访问各个不同的节点,因此缓存遗漏将会增加。这里有两种方法可以克服这个问题:全局缓存和分布式缓存。 1.1全局缓存 顾名思义,全局缓存是指所有节点都使用同一个缓存空间。这包含添加一台服务器或某种类型的文件存储,所有请求层节点访问该存储要比原始存储快。每个请求节点会以同种方式查询缓存,这种缓存方案可能有点复杂,随着客户机和请求数量的增加,单个缓存(Cache)很容易溢出,但在某些结构中却是非常有效的(特别是那些特定的硬件,专门用来提升全局缓存速度,或者是需要被缓存的特定数据集)。 在图3中描述了全局缓存常见的两种方式。当一个Cache响应在高速缓存中没有发现时,Cache自己会从底层存储中检索缺少的那块数据。如图4所示,请求节点去检索那些在高速缓存中没有发现的数据。

Web服务器配置方法教程

Web服务器配置方法教程 服务器是一种高性能计算机,作为网络的节点,存储、处理网络上80%的数据、信息,因此也被称为网络的灵魂。那么该如何配置Web服务器呢?如果你不知道,请看的Web服务器配置方法详解吧! 一般在安装操作系统时不默认安装IIS,所以在第一次配置Web 服务器时需要安装IIS。安装方法为: 1、打开“控制面板”,打开“添加/删除程序”,弹出“添加/删除程序”窗口。 2、单击窗口中的“添加/删除Windows组件”图标,弹出“Windows组件向导”对话框。 3、选中“向导”中的“应用程序服务器”复选框。单击“详细信息”按钮,弹出“应用程序服务器”对话框。 4、选择需要的组件,其中“Inter信息服务(IIS)”和“应用程序服务器控制台”是必须选中的。选中“Inter信息服务(IIS)”后,再单击“详细信息”按钮,弹出“Inter信息服务(IIS)”对话框。

5、选中“Inter信息服务管理器”和“万维网服务”。并且选中“万维网服务”后,再单击“详细信息”按钮,弹出“万维网服务”对话框。 6、其中的“万维网服务”必须选中。如果想要服务器支持ASP,还应该选中“Active Server Pages”。逐个单击“确定”按钮,关闭各对话框,直到返回图1的“Windows组件向导”对话框。 7、单击“下一步”按钮,系统开始IIS的安装,这期间可能要求插入Windows Server xx安装盘,系统会自动进行安装工作。 8、安装完成后,弹出提示安装成功的对话框,单击“确定”按钮就完成了IIS的安装。 友情提示:如果想要同时装入FTP服务器,在“Inter信息服务(IIS)”对话框中应该把“文件传输协议(FTP)服务”的复选框也选中。 打开“Inter 信息服务管理器”,在目录树的“网站”上单击右键,在右键菜单中选择“新建→网站”,弹出“网站创建向导”:

缓存服务器介绍

什么是缓存服务器 无论企业有多大,Web缓存都有助于优化性能和节省带宽。而且如果选择了正确的缓存解决方案,它可以随着企业网络的增长而扩大,而无需进行昂贵且耗时的重建。 Web缓存提供了比将访问对象放在Internet Web服务器上更好的方法,它将需要频繁访问的Web页面和对象保存在离用户更近的系统中。当再次访问这些对象的时候加快了速度。 几年以前,理论是超高带宽的Internet连接会使Web缓存毫无用处,但是结果并非如此。即使最快的速率达到30-45Mbps的光纤Internet连接和速度在100 Mbps到1 Gbps速率的局域网相比仍然很慢,所以性能依旧是一个问题。除此之外,缓存提高了可用性,因为即使托管的Web服务器停机或者由于网络问题而不可达时,缓存的对象拷贝仍然可以访问。如果企业根据流量付费,缓存还可以降低Internet连通性的费用。即使是小公司,缓存也会有利,而且好的缓存解决方案将随着企业级别升级。[1] 编辑本段缓存概念 这是两种主要的Web缓存: 直接缓存,将用户频繁访问的来自Internet服务器的Web对象的拷贝保存在企业本地网络中。 反向缓存,企业内部Web服务器的Web对象的拷贝保存在企业网络边缘的代理服务器上以提高外界访问企业站点的性能。 Web缓存可以根据不同等级进行配置: 本地缓存:将Web对象缓存的拷贝保存在本地计算机中。大多数流行的Web浏览器默认情况下保留一个先前访问对象的缓存。例如,Internet Explorer称之为“临时Internet 文件”。本地缓存拷贝只是在用户频繁地从同一台机器访问页面时有用。 代理缓存:代理服务器是为公司内的多个用户/客户计算机缓存Web对象的单独机器。它们是位于客户端和托管的Web服务器之间的计算机,而且它们比本地缓存效率更高,因为在企业本地网络中的任何用户或计算机访问某个Web对象时,缓存拷贝对想访问该对象的任何其他用户/计算机是可用的,无需到Internet服务器上再次下载它。代理缓存可以在网络边缘与防火墙结合使用。 微软的ISA Server和BlueCoat的工具一样,既包括防火墙也包括缓存代理服务器。缓

利用Squid反向代理搭建CDN缓存服务器加快Web访问速度

本文介绍利用Squid反向代理搭建CDN缓存服务器加快Web访问速度的搭建方法. 案例: Web服务器:域名https://www.360docs.net/doc/2818046784.html, IP:192.168.21.129 电信单线路接入 访问用户:电信宽带用户、移动宽带用户 出现问题:电信用户打开https://www.360docs.net/doc/2818046784.html,正常,移动用户打开https://www.360docs.net/doc/2818046784.html,很慢,甚至打不开 解决方案:在移动机房放置一台CDN代理服务器,通过智能DNS解析,让电信用户直接访问Web服务器、让移动用户访问CDN代理服务器,解决移动用户访问Web服务器慢的问题 具体操作: CDN代理服务器: 系统:CentOS 5.5 主机名:https://www.360docs.net/doc/2818046784.html, IP:192.168.21.160 安装Squid软件,配置反向代理搭建CDN缓存服务器 安装前准备: 1、关闭SELinux vi /etc/selinux/config #SELINUX=enforcing #注释掉 #SELINUXTYPE=targeted #注释掉 SELINUX=disabled #增加 :wq 保存,关闭。 shutdown -r now重启系统 2、开启防火墙80端口(后面配置squid的端口为80)

vi /etc/sysconfig/iptables 添加下面的内容 -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT /etc/init.d/iptables restart #重启防火墙使配置生效 3、修改主机的路由模式 vi /etc/sysctl.conf net.ipv4.ip_forward = 1 #0为关闭,1为开启路由使用sysctl -p 命令查看系统运维 https://www.360docs.net/doc/2818046784.html, 温馨提醒:qihang01原创内容?版权所有,转载请注明出处及原文链接 4、修改主机hosts文件,增加域名解析记录 vi /etc/hosts 192.168.21.129 https://www.360docs.net/doc/2818046784.html, #添加解析记录 ===================================================================== ====== 安装开始 1、安装Squid yum install squid #安装(Squid 2.6) service squid start #启动 service squid restart #重启 chkconfig squid on #设置开机启动 2、配置Squid cp /etc/squid/squid.conf /etc/squid/squid.confbak #备份 vi /etc/squid/squid.conf #编辑文件 http_port 80 transparent #设置squid端口,默认为3128,设置为80,客户端打开网站的时候不需要输入端口号 cache_mem 1024 MB #分配内存大小 cache_dir ufs /var/spool/squid 4096 16 256 #设置缓存文件大小 cache_effective_user squid #设置用户 cache_effective_group squid #设置用户组 access_log /var/log/squid/access.log #设置访问日志文件 cache_log /var/log/squid/cache.log #设置缓存日志文件 cache_store_log /var/log/squid/store.log #设置缓存记录文件 visible_hostname https://www.360docs.net/doc/2818046784.html, #设置squid服务器主机名 cache_mgr root@https://www.360docs.net/doc/2818046784.html, #设置管理员邮箱(设置为自己的邮箱地址) acl all src 0.0.0.0/0.0.0.0 #设置访问控制列表,默认开启 http_access allow all #设置访问权限,默认注释掉的 cache_peer 192.168.21.129 parent 80 0 no-query originserver name=web #用户访问web时,Squid向192.168.21.129的80端口发送请求 cache_peer_domain web https://www.360docs.net/doc/2818046784.html, #设置web域名为https://www.360docs.net/doc/2818046784.html,

web缓存服务器介绍

web缓存服务器介绍 对于web缓存服务器的了解,大多数人都不是很了解,只是道听途说,对于其真正的作用,专职优化、域名注册、网站空间、虚拟主机、服务器托管、vps主机、服务器租用的中国信息港就在这里为你详细探讨! 无论企业有多大,Web缓存都有助于优化性能和节省带宽。而且如果选择了正确的缓存解决方案,它可以随着企业网络的增长而扩大,而无需进行昂贵且耗时的重建。 Web缓存提供了比将访问对象放在Internet Web服务器上更好的方法,它将需要频繁访问的Web 页面和对象保存在离用户更近的系统中。当再次访问这些对象的时候加快了速度。 几年以前,理论是超高带宽的Internet连接会使Web缓存毫无用处,但是结果并非如此。即使最快的速率达到30-45Mbps的光纤Internet连接和速度在100 Mbps到1 Gbps速率的局域网相比仍然很慢,所以性能依旧是一个问题。除此之外,缓存提高了可用性,因为即使托管的Web服务器停机或者由于网络问题而不可达时,缓存的对象拷贝仍然可以访问。如果企业根据流量付费,缓存还可以降低Internet连通性的费用。即使是小公司,缓存也会有利,而且好的缓存解决方案将随着企业级别升级。 缓存概念 这是两种主要的Web缓存: 直接缓存,将用户频繁访问的来自Internet服务器的Web对象的拷贝保存在企业本地网络中。 反向缓存,企业内部Web服务器的Web对象的拷贝保存在企业网络边缘的代理服务器上以提高外界访问企业站点的性能。 Web缓存可以根据不同等级进行配置: 本地缓存:将Web对象缓存的拷贝保存在本地计算机中。大多数流行的Web浏览器默认情况下保留一个先前访问对象的缓存。例如,Internet Explorer称之为“临时Internet文件”。本地缓存拷贝只是在用户频繁地从同一台机器访问页面时有用。 代理缓存:代理服务器是为公司内的多个用户/客户计算机缓存Web对象的单独机器。它们是位于客户端和托管的Web服务器之间的计算机,而且它们比本地缓存效率更高,因为在企业本地网络中的任何用户或计算机访问某个Web对象时,缓存拷贝对想访问该对象的任何其他用户/计算机是可用的,无需到Internet服务器上再次下载它。代理缓存可以在网络边缘与防火墙结合使用。 微软的ISA Server和BlueCoat的工具一样,既包括防火墙也包括缓存代理服务器。缓存服务器也可以是单独的机器,运行免费的缓存软件或商业产品,例如: Linux版的Squid免费缓存代理 MOWS基于Java分布式web和缓存服务器 Vicomsoft RapidCache Server for Windows或Macintosh WinProxy for Windows 可升级的缓存解决方案 随着公司的扩大,单一的Web缓存服务器可能无法处理所有的通信或存储足够的Web 对象。在这种情况下,可以扩展缓存解决方案以建立一个缓存阵列——一组共同工作以便在组内分配缓存负载的缓存代理服务器。万一某个缓存服务器停机,还提供缺省的容量。

使用JCS在Web门户应用中实现对象缓存

使用JCS在Web门户应用中实现对象缓存(1) 使用JCS在Web门户应用中实现对象缓存 在我最近的web门户应用开发工作中,我们需要在Servlet容器(Tomcat)的内存中存储一些查找数据(例如:比率更新数据、状态和产品列表),这样我们不需要在每次访问数据的时候进行数据库查找。同时,我们也需要定期地刷新存储在内存中的数据以保证其新鲜和准确。我们也需要一种机制在不同的时间间隔对存储在内存中的不同类型的数据进行刷新。例如,比率更新数据需要每天刷新一次,而查找类型的数据则可以在内存中保留很长一段时间。对象缓存是最方便地达到上述所有目的的完美解决方案。 对象缓存 最恰当的对象缓存的定义可以在Object Caching Service for Java (OCS4J)的功能规范文档中找到,它是这样定义的: 服务器必须将信息和可执行对象分为三种基本类别管理:永远不会改变的对象,每次请求都会发生改变的对象,以及在两者之间的对象。Java对前两种对象的处理提供了很好的支持,但是对第三种类别的支持非常有限。如果对象永远不改变,我们在服务器初始化的时候创建静态对象。如果对每个请求对象都是不同的,我们每次都创建新的对象。对于介于两者之间的对象或信息,它们的状态可能会发生变化,但是又需要提供跨越请求、跨越用户或跨越进程的共享,就要采用“对象缓存服务”了。 基本上,对象缓存就是通过在使用对象后不立即释放,而是存储在内存中并被后来的客户端请求重用,避免重新获得对象的昂贵成本。当数据第一次从数据源被检索出来后,在名为cache的内存缓冲中临时存放。同样的数据再次被访问的时候,对象从缓存中取出来,而不是从数据源重新获取。最后,被缓存的数据在不再需要的时候从内存中释放出来。从Web应用的观点来看,什么时候指定的对象可以从内存中释放出来取决于定义一个对象变成无效的合理的间隔时间。 缓存的益处

缓存设计详解低成本的高性能Web应用解决方案

过去几年中,Web应用程序已经从简单的HTML页面堆积演变成使用各种各样的技术构建高可扩展性和交互式的富应用程序。设计和开发这类应用程序变得越来越复杂,此外,决策者正越来越多地寻求构建更丰富的互动功能到这些应用程序中,同时还要保证可维护性和高性能,但高性能意味着高成本。为了构建提供给最终用户体验的是一个牢固的应用程序,开发人员需要解决潜在的性能瓶颈。 本文侧重于缓存——它是交付高性能Web应用程序急需的——也简要介绍一下压缩功能。有一些公司在生产和销售专门的压缩和性能产品。本文旨在简单介绍在寻求专业产品解决性能问题之前开发人员可以在客户端和服务器端对Web应用程序做的一些性能改进。 性能瓶颈 性能瓶颈主要体现在高延时、拥塞和服务器负载。缓存不能完全解决掉这三个问题,但经过详细的设计考虑,缓存是可以提高性能的。在服务器端和客户端都缓存内容,据调查,平均而言,下载HTML只需要总的用户响应时间的10-20%,剩下的80-90%全部用于下载页面中的其它组成内容,这些组成内容通常包括图像,如公司logo,缓存logo可以有效避免到服务器的多次往返。在前日51CTO上发布的中,Google提到的提升网站速度和性能的低成本技巧中就包括缓存这一条。至于架构设计方面,则可参考51CTO的。

简单地讲,缓存是临时存储。它将数据复制到不同的计算机或不同于原始数据源的位置,有了正确的配置,访问缓存数据的速度比访问原始数据的速度要快得多,使用缓存数据可以减小服务器负载和带宽消耗,从最终用户的角度来看就是性能提高了。 图1显示了Internet如何工作的快速总揽,以及缓存在哪里发生作用。 ? 图 1 Internet上的缓存:这个图显示了常见的请求和检索缓存信息的时机

web常用的常用缓存技术有哪些此贴一网打尽

web常用的常用缓存技术有哪些?此贴一网打尽! 1、Opcode缓存 首先php代码被解析为Tokens,然后再编译为Opcode码,最后执行Opcode码,返回结果;所以,对于相同的php文件,第一次运行时 可以缓存其Opcode码,下次再执行这个页面时,直接会去找到缓存下的opcode码,直接执行最后一步,而不再需要中间的步骤了。2、内存式缓存提到这个,可能大家想到的首先就是Memcached;memcached是高性能的分布式内存缓存服务器。 一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度、 提高可扩展性。它就是将需要缓存的信息,缓存到系统内存中,需要获取信息时,直接到内存中取;比较常用的方式就是key–>value方式; <?php $memcachehost = '192.168.6.191'; $memcacheport = 11211;

$memcachelife = 60; $memcache = new Memcache; $memcache->connect($memcachehost,$memcacheport) or die ("Could not connect"); $memcache->set('key','缓存的内容'); $get = $memcache->get($key); //获取信息 ?>复制代码3、php APC缓存扩展Php有一个APC 缓存扩展,windows下面为php_apc.dll,需要先加载这个模块,然后是在php.ini里面进行配置: extension=php_apc.dll apc.rfc1867 = on upload_max_filesize = 100M

搭建web缓存服务器

一、说明 随着网站访问量的不断攀升,网站的负荷也不断上升,数据库负荷变化尤其明显,特别是在访问的高峰期,用户浏览器页面显示很缓慢,长时间连一个文本页面都显示不出来,最差的情况是网站直接崩溃,严重的影响了用户的体验,降低了网站的粘性。这个时候,是一定要考虑搭建web缓存服务器的时候了。 我们选择的是一款Fikker 网站加速产品作为参考示例。根据官方的介绍,Fikker 是一款完全基于高速内存的缓存加速产品,无缓存文件生成,支持跨平台(windows和linux),在V3.2.4 之前还没有看到提供对freeBSD 操作系统的支持,我们使用它的免费版本做为示例。搭建web缓存服务器的目的:除了降低网站服务器的负荷和加快页面显示外,还可以隐藏源站,进行流量统计和实时监控,甚至是防盗链等等,最重要的是整个过程不需要修改已有网站程序的源码,全界面化的web缓存配置操作。 二、准备阶段 这个阶段我们先到Fikker 的官方网站下载它,我们下载和使用的是CentOS Linux 版本,不管是Linux 还是Windows 版本,整个安装和配置过程非常类似。我们将下载后的安装包fikkerd-3.2.4-linux-x86.tar.gz 放在/home/meng 下面,通过命令行进行解压: tar zxvf fikkerd-3.2.4-linux-x86.tar.gz 三、配置阶段 1、根据Fikker 安装说明,到了这个阶段,我们可以进行相关的配置了,目前Apache 已经在占用80 端口,为了安全起见,我们先测试后实施,我们现将Fikker 的默认端口80 改成8080,这样子我们就可先将Fikker 配置和测试完成后,再让其投入实际服务当中去,不会对原有的网站有任何影响。首先修改config 目录下面的fikkerd.ini 配置文件(命令行为:vi fikkerd.ini),如下:

Http页面缓存机制

改善Web 2.0 应用程序的性能 探秘不同的浏览器端缓存机制 Jian Qiao Sun, 软件工程师, IBM Hua Pin Shen, 顾问软件工程师, IBM 简介:随着Web 2.0 应用程序的出现和流行,人们使用Internet 的方式已经悄然改变。现在,这些Web 2.0 应用程序拥有许多典型的特征,包括拥有富客户端、大页面、包含许多小项目的页面、大量的JavaScript 编码等等。鉴于目前的浏览器技术,大部分这些特征都会导致浏览器端性能问题,特别是在长距离网络中。本文将分析典型Web 2.0 应用程序的关键方面,并介绍它们如何影响浏览器端性能。本文还将检查浏览器端性能的一个非常重要的部分——浏览器端缓存。 发布日期: 2010 年2 月25 日 级别:中级 其他语言版本:英文 平均分(共2 个评分) 简介 随着Web 2.0 应用程序的出现和流行,Internet 的使用方式已经发生改变,出现了一种新趋势:针对内容管理、信息共享、通信、团队合作等创建一种更加以用户为中心的方法。从技术角度看,Web 2.0 应用程序并没有带来很多新的技术突破。但是,这些应用程序的确带来了一种新的Internet 使用模式。现在,Web 2.0 应用程序拥有许多典型特征,包括拥有富客户端、大页面、包含许多小项目的页面、大量的JavaScript 编码等等。这些特征会导致浏览器端性能问题,特别是在长距离网络中。这些性能问题会对用户体验造成不利影响,但您甚至不会意识到这些问题的存在。由于开发人员拥有很好的网络条件,因此这些性能问题很难完全暴露出来。 本文将首先分析典型的Web 2.0 应用程序的关键方面,解释它们如何影响浏览器端性能。然后,本文介绍浏览器端性能的一个非常重要的部分——浏览器缓存。通过使用适当的缓存设置,您可以向用户提供较好的应用程序体验。如果您没有一个整体缓存策略设计,那么您的缓存策略不仅会导致低劣的性能,还会引发一些功能缺陷。 有许多影响浏览器缓存的规则,其中的部分规则包括Cache-Control、Etag、Expires、Last-Modified 和Vary。所有这些设置拥有不同的含义和最适用的情形。困难之处在于对于相同的设置,并不是所有流行浏览器都拥有相同的行为。因此,在您决定使用这些设置之前,您应该准确了解这些浏览器是如何工作的。本文将检查目前市面上最流行的浏览器的行为:Internet Explorer、Firefox、Chrome 和Safari。 在本文中,我们还使用IBM? Mashups 和开源“Roller Weblogger” 来提供一些示例,展示如何应用不同的指令以最好地使用浏览器缓存。 背景 在当今的Internet 环境中,Web 2.0 应用程序正在变得越来越流行。许多Web 站点都使用Web 2.0 构建,比如Facebook、Youtube 等。IBM 也有Web 2.0 应用程序,比如Lotus Connections 和Lotus Mashups。 以下是一种用于计算浏览器响应时间的基本方法: ?浏览器响应时间= 服务器端时间+ 页面加载时间+ 浏览器呈现时间 ?页面加载时间= (请求数/ 并发数)* 延迟时间+ 页面总大小/ 带宽

大型网站后台架构的web server与缓存

网站的web server与缓存 1.1 Web server Webserver 用来解析HTTP协议。当web 服务器接收到一个HTTP请求时,会返回一个HTTP响应,例如送回一个HTML页面。为了处理一个请求,web服务器可以响应一个静态页面或者图片。进行页面跳转,或者把动态响应的产生委托给一些其它的程序完成,比如CGI,JSP,servlets,ASP,PHP脚本。 当用户访问一个网站时,首先用户通过查询DNS服务器,得到该域名对应的IP地址,然后使用这个IP地址来进行访问。用户的请求是一个url地址,在web 服务器端,url地址对应web服务器上的文件系统中的某个网站文件的路径。Web server的作用就是解析HTTP 协议,通过用户发来请求的url地址从web服务器的文件系统中找到用户需要的HTML页面、静态文件,然后返回给用户。如果用户访问的是动态页面,则将请求转发到应用服务器来执行。 1.1.1 FastCGI 1.1.1.1 CGI CGI(Common Gateway Interface) ,指运行在服务器上,提供同客户端HTML页面的接口。多数CGI程序被用来解释处理来自表单的输入信息,并在服务器产生相应的处理,或将相应的信息反馈给浏览器。 1.1.1.2 FastCGI FastCGI是语言无关的、可伸缩架构的CGI开放扩展,其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。而CGI解释器的反复加载是CGI性能低下的主要原因。如果CGI解释器保持在内存中并接受FastCGI进程管理器的调度,则可以提供良好的性能、伸缩性能和Fail-over特性等。 FastCGI的工作原理如下: (1) FastCGI进程管理器自身初始化,启动多个CGI解释器进程(多php-cgi进程)并等待来自web server的连接。启动php-cgi FastCGI进程时,可以配置以TCP和UNIX套接字两种方式启动。 (2)当客户端请求到达web服务器时,web服务器将请求采用TCP协议或者UNIX套接字方式转发到FastCGI主进程,FastCGI主进程选择并连接到一个CGI解释器(子进程)。Web 服务器将CGI环境变量和标准输入法发送到FastCGI子进程php-cgi。 (3)FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回web服务器。当FastCGI子进程关闭连接时,请求便告知处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器的下一个连接。 FastCGI的优点如下:

CDN缓存系统用户手册

CDN缓存系统 用户帮助手册 版权声明: 本文件中出现的全部内容,除另有特别注明,版权均属北京互联港湾科技有限公司(以下简称互联港湾)所有,未经互联港湾书面许可,任何人不得以任何形式擅自拷贝、传播、复制、泄露本文件的全部或部分内容。 北京互联港湾科技有限公司

一、概述 CDN的全称是Content Delivery Network,即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN 系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。 其目的有两个: 一是使用户可就近取得所需内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度。 二是防攻击,更好的保护网站,网站源ip不会被暴露,针对流量型攻击,可以通过部署高防cdn节点对付。 二、CDN缓存系统概述 C DN缓存系统是北京互联港湾科技有限公司从2010年起自主研发的是一款专业可运营级别cdn系统。由我司开发的easypanel多节点cdn功能升级而来。CDN缓存系统集成第三方DNS功能,无缝衔接dns,支持大规模节点部署(上千台服务器).cdn节点支持自动升级,cdn 节点反向代理软件采用自主研发的kangle web服务器(以下简称kangle)。CDN缓存系统大量采用开源软件,客户部署CDN缓存系统无需再购买其它的商业软件,节省成本。 1. 高效缓存功能 通过我们完全自主开发的kangle web的缓存机制和强大的访问控制功能对网站性能优化,同时和DNS的无缝隙衔接综合采用多线路智能调度、故障监测、页面优化、页面缓存等技术,能够最大限制提升网站访问速度,降低故障率,从而整体提升网站的用户体验。 2. 多节点智能分流 CDN缓存系统和DNS的无缝隙衔接,通过CDN缓存系统即可操作您的域名解析记录,

相关文档
最新文档