缩短响应时间专项方案RESPONSETIME.docx
- 文档编号:3527064
- 上传时间:2023-05-06
- 格式:DOCX
- 页数:9
- 大小:193.60KB
缩短响应时间专项方案RESPONSETIME.docx
《缩短响应时间专项方案RESPONSETIME.docx》由会员分享,可在线阅读,更多相关《缩短响应时间专项方案RESPONSETIME.docx(9页珍藏版)》请在冰点文库上搜索。
缩短响应时间专项方案RESPONSETIME
一、背景
性能是Web应用程序成功与否核心因素,响应时间则是性能一种重要指标,特别是从顾客角度来看,随着同步访问顾客数增长,Web应用程序响应时间也会相应增长,当其增长到顾客无法接受限度时,顾客便会失去耐心而离开该网站。
依照ZonaResearch研究指出,如果使用者等待下载网页时间超过8s,将有30%顾客选取停止浏览网页,同样研究表白,如果下载网页时间缩短1s,则这个数字将从30%减少到8%。
由此可见终端顾客所感届时间延迟(user-perceivedlatency)已经成为今天Internet重要性能问题。
在网络带宽并没有得到相对扩充、网络流量绝对增长状况下,找到某些有效办法来缩短整个网络对顾客祈求响应时间,就显得愈发重要。
针对这一问题,咱们从如下几种方面进行了调研与摸索,从而加速网络对顾客反映速度,缩短顾客感知时间延迟。
二、缩短响应时间方案
2.1优化数据访问
对数据访问速度很大限度上影响应用系统性能,如果被祈求页面是一种静态页面或只有一小某些内容需要从数据库中提取,则它加载速度比那些需要从数据库中大量读取数据或不断从数据库接受和更新数据页面要快,因而,对于动态页面来说,对SQL层数据解决优化就显得非常重要。
在Web开发中,除了老式改进数据库构造和优化SQL语句外,重要从如下几种方进行优化。
2.1.1使用XML技术
采用XML(可扩展标记语言)技术,可将查询成果生成XML文献保存在Web服务器上,使客户端可以直接和XML文献进行交互,以节约访问数据库资源;同步也可以将XML传送到客户端,在客户端恢复为数据集,此后就可以直接在客户端进行某些操作,而不必和服务器交互,建立非连接数据访问以节约时间。
这里采用如下算法过程运用XML技术实现对数据库访问。
(1)建立数据库连接,生成查询成果数据集(DataSet);
(2)用XmlDataDocument将查询成果集(DataSet)以XML形式保存在Web服务器指定目录下,同步断开数据库连接;
(3)一旦顾客发送访问祈求,一方面查询Web服务器指定目录下与否有满足条件XML文献,如果存在转(4),否则转
(1);
(4)创立XmlDataDocument对象,并用其Load办法加载该XML文献;
(5)运用XPath或者XQuery查询技术,查询已加载XML文献,生成相应成果集。
从上面过程可以看出,一旦有顾客发送查询祈求,一方面将数据库服务器中数据转化为XML文档,保存在Web服务器上,然后查询XML文献中数据,获取查询成果。
之后如果有新祈求查询相似记录时,可以直接从Web服务器XML文献中提取数据而不用再访问数据库。
这对于顾客频繁查询汇总操作中,优势非常明显,且效率很高。
这种思想在逻辑上将数据生成和操作分开,同步节约了和数据库服务器建立连接时间,将其转换为对服务器端XMl文献读取,有效地减轻了对系统数据库服务器负荷。
3.1.2使用连接池
建立Web应用程序与数据库之间TCP连接时,DBMS(数据库管理系统)需要为其分派各种资源,而在释放连接时,DBMS需要释放掉这些资源,分派和释放资源都是比较耗时工作,因而重复建立和释放连接势必会影响整个系统性能。
事实上,大多数应用程序仅使用1个或几种不同连接配备。
这意味着在执行应用程序期间,许多相似连接将重复地打开和关闭。
为了使打开连接成本最低,ADO.NET使用连接池优化办法。
连接池技术可以能重用到数据库连接,而不是每次祈求都建立新TCP连接,新连接仅在连接池中得不到连接时才建立。
当连接被关闭时,它被返回到连接池中,在那里它依然保持与数据库连接,与完全断开TCP连接相反。
池进程保持物理连接所有权。
通过为每个给定连接配备保存一组活动连接来管理连接。
只要顾客在连接上调用Open,池进程就会检查池中与否有可用连接。
如果某个池连接可用,会将该连接返回给调用者,而不是打开新连接。
应用程序在该连接上调用Close时,池进程会将连接返回到活动连接池集中,而不是真正关闭连接。
连接返回到池中之后,即可在下一种Open调用中重复使用。
池连接可以大大提高应用程序性能和可缩放性。
默认状况下,ADO.NET中启用连接池。
除非显式禁用,否则,连接在应用程序中打开和关闭时,池进程将对连接进行优化。
2.2减少网络通信量
数据传播量大小是决定显示响应速度必要前提,数据传播量是指在客户端Web浏览器和Web服务器之间传送数据量。
咱们可以通过减少网络通信量:
减少IE浏览器和Web服务器层之间数据传数量,缩短顾客感知时间。
2.2.1使用缓存技术
Internet登记表白,超过80%顾客经常访问是20%网站内容,在这个规律下,缓存服务器可以解决大某些客户静态祈求,而原始服务器只需解决约20%左右非缓存祈求和动态祈求,于是大大加快了客户祈求响应时间,并减少了原始服务器负载。
合理有效地设计和使用缓存是优化应用系统性能重要手段,在基于Web支持大量顾客系统开发中,这一点尤为明显。
运用有效缓存,可以避免Web服务器与数据库之间网络来回,绕过占用诸多资源计算,并节约服务器资源,同步改进响应时间和等待时间。
缓存服务是一种提高服务器性能、减少服务器资源挥霍有效办法。
对于安全性规定高应用程序,采用在WEB服务器上维护缓存数据方式可以有效地提高页面性能。
缓存实现了近来至少使用(least-recently-used)替代算法,并且容许强制缓存清除操作——如果可用内存下降到低水平——则自动从缓存中删除不使用项目。
此外缓存支持依赖性到期特性,它能强制涉及时间、键值、文献失效。
多级缓存体系构造如图3所示。
2.2.2避免服务器和客户端交互
HTTP是用于客户端和服务器之间进行信息传播合同,它是一种祈求响应类型合同:
客户机向服务器发送祈求,服务器收到祈求后进行解决,对这个祈求作出回答。
Web浏览器包括了许多HTTP祈求,每一种祈求相应一种小型文献,HTTP对每一种HTTP祈求需要建立1个独立TCP连接。
因而,客户端每次祈求将会引起客户端和服务器间一次通信,频繁操作势必对系统响应时间导致严重影响。
为避免不必要TCP连接建立,普通只需在向服务器查询或更新数据时才触发客户端与服务器之间信息交互。
能在客户端执行数据操作应尽量用客户端脚本(如Javascript)实现。
例如,对顾客输入数据校验,应当尽量在客户端进行校验,再将数据提交给服务器。
2.2.3客户端缓存
上面提到数据缓存在服务器端有诸多好处,可以减少IE浏览器和Web服务器层之间数据传数量,然而有时候咱们为了提高性能咱们要把有些数据缓存到客户端,也可以减少网络通信量,从而用这种机制来达到缓和服务器压力。
在客户端缓存网页或者其她网络资源(图片,脚本,样式表,等)好处是显而易见:
避免了不必要祈求,从而增长访问速度;并且减少了响应数据量,从而减少带宽。
减少网络带宽不但意味着访问速度提高,在当网络带宽不是完全免费状况下,也有着显而易见好处。
在HTTP/1.1RFC中,也提到通过恰当使用缓存,HTTP合同中定义了三种类型缓存机制:
Freshness:
容许客户端无需检查原始服务器上内容就缓存当前响应,惯用是Expires和Cache-Control。
Validation:
容许在当前缓存内容“过期”后检查原始内容与否已经更新,例如Last-Modified和ETag。
Invalidation:
容许在访问同一种资源时使之前缓存内容失效,例如对同一种资源POST,PUT或者DELETE祈求就会使之前缓存失效。
例如Expires可以指定缓存过期时间,指定内容过期时间是最简朴实现客户端浏览器缓存办法。
Expires指定一种时间,告诉浏览器相应内容在指定期间之前都不会发生变化。
浏览器因而也就不需要重新祈求文档内容,只需从缓存中读取相应内容就可以了。
如果不但愿浏览器缓存当前内容,可以把Expires设立为一种过去时间。
再例如Last-Modified相应头指定一种时间,告诉浏览器当前文档最后修改时间。
浏览器下次访问该文档时会包括一种If-Modified-Since字段,目是告诉服务器,只有祈求文档最后更新时间不不大于指定期间时,才需要服务器重新传送文档内容。
If-Modified-Since值来自浏览器收到Last-Modified值。
2.3对象包装
大某些网页都是由许多小文献(不大于16K)构成,这是通过对象包装进行web文献传播一种大前提。
服务器端大多数开销都来自于操作系统从本地磁盘中检索被祈求文献开销,如果锁清秋文献数减少了,则服务器端开销就减少了,通过避免包残片,从而在网络中要传播包也减少了。
因此咱们提出通过对象包装来进行web文献传播,对象包装是在一种主页上web文献集合,包装在一种未压缩存档文献里。
这样各种文献,例如HTML文本和图片文献等,就可以被包装在一种对象包装文献里,从而提高传播效率。
主页上文献是按顺序地被包装,并不通过压缩,这样可以避免在接受端解压开销。
对象包装可以通过独特文献扩展名来标记,接受时,客户端解包装在对象包里文献。
对象包装格式
咱们提出新传播机制-对象包装,可以减小web浏览响应时间,不但减小了传播途径上路由器处开销,还减小了web服务器处响应时间。
对象包装旨在解决web文献传播中,两大不同问题:
文献获取开销和合同解决开销。
实验表白经对象包装后文献传播可减少34.7%响应时间、40.1%传播字节数、和7.1%包。
2.4最小盼望响应时间(MRT)分布式web缓存机制
Web缓存是提高web服务性能和质量一种原则方案,然而单点缓存效率很低,在web中缓存命中率只有40%甚至更低。
通过把单个缓存节点扩展为协作缓存集合,支持在各种缓存服务器间数据共享,从而能提高webcaching有效性,提高缓存命中率,缩短响应时间。
协作缓存系统有两类:
分层和分布式。
分层缓存服务器架构在缓存服务器中定义了父级和兄弟级关系,如果一种缓存服务器不能响应某个HTTP祈求,它先检查它兄弟缓存服务器与否可以响应,如果它们也都无法响应,则此祈求被传递给它父缓存服务器,然后一层一层往上传递。
如果最后根缓存服务器也没有所祈求页面,她就把祈求转发给web服务器。
分布式缓存服务器架构,与分层架构相反,它容许所有缓存服务器以对等关系来共享数据。
咱们还提出一种新分布式缓存方案,称为最小盼望响应时间(MRT)分布式web缓存机制。
它在一种分布式web缓存系统中,使用内容感知层5转换,透明地把可缓存HTTP祈求以最小响应时间重定向到缓存服务器中。
基于缓存服务器内容、负载,web服务器负载和网络延迟结合,试图最小化HTTP响应时间,并且在各个缓存服务器中进行负载均衡。
仿真证明,在平均HTTP祈求响应时间方面,MRT能提供增强缓存协作,从而提高性能,优于现存分布式webcaching机制。
2.5动态流添加SCTP合同
SCTP(StreamControlTransmissionProtocol,流控制传播合同):
是IETF新定义一种传播层transportlayer合同。
是提供基于不可靠传播业务合同之上可靠数据报传播合同。
SCTP设计用于通过IP网传播SCN窄带信令消息。
SCTP是一种可靠传播合同,它在两个端点之间提供稳定、有序数据传递服务(非常类似于TCP),并且可以保护数据消息边界。
SCTP重要贡献是对多重联外线路支持,一种端点可以由多于一种IP地址构成,使得传播可在主机间或网卡间做到透明网络容错备援。
当前SCTP旨在初始连接建立阶段创立流,之后流不能被修改。
当同步地用多流传播web对象时,由于大对象占用了流,而小对象没有可分派流,因此会引起不必要等待。
咱们提出对SCTP扩展,来支持在通信中动态流添加,叫做动态流添加SCTP(DSA-SCTP,DynamicStreamAdditionSCTP),在通信过程中,一条连接两端都可以动态地添加新出去流和进来流。
当需要匹配一种突发性对象并发传播时,动态流添加可以依照应用程序需求来创立新流,从而在web应用中,可以减少web服务器响应时间。
仿真证明,提出DSA-SCTP会明显提高web服务器响应时间。
2.6在web服务器集群中使用协同调度
使用服务集群,特别是分布式web服务器已经成为提高吞吐量和响应时间一种重要研究方向,某些大服务商已经开始运用大量PC集群来解决海量数据。
虽然提高吞吐量已经成为所有分布式或基于集群web服务器设计重要动机,然而顾客层通信也对服务性能有着很大影响。
顾客层通信机制,例如VIA(虚拟接口架构)能明显最小化通信开销。
PRESS模型一方面分析了顾客层通信对分布式web服务影响,PRESS模型客户端通过在迅速以太网上TCP与集群进行通信,集群内通信使用在cLAN上VIA。
由于集群内通信成本很低,多以从远程缓存处读取一种文献比从本地磁盘读取要快,并且节约成本。
实验显示,PRESS与TCP/IP相比,能提高29%服务器吞吐量。
基于以上集群和PRESS特点,咱们提出一种协同调度PRESS模型,它能使用任何协同调度算法来更快通信。
在PRESS中,发送线程和接受线程解决了所有集群内通信,咱们把集群内通信提成远程缓存和远程紫攀接入两种。
使用远程缓存发送线程和远程缓存接受线程来解决对一种缓存缓存祈求,远程磁盘发送线程和远程磁盘接受线程则支持对远程磁盘访问。
对缓存访问和磁盘访问分离,是由于远程缓存访问使用了顾客层通信,比磁盘访问快得多。
咱们还可以通过在两个节点处协同调度所需进程来最小化通信延迟,从而缩短响应时间。
但是远程磁盘访问比较耗时,因此也许不会运用打牌协同调度优势。
咱们方案运用了顾客层通信和协同调度优势,研究使服务器响应时间最小化可行性。
基于PRESS设计,使得远程缓存访问能在不同节点处被协调调度,从而减少了响应时间。
仿真成果表白,通过协同调度通信进程,分布式服务器平均响应时间能明显减小。
2.7SWIFT(在web服务器中调度以获得迅速响应时间)
这篇文章解决了如何迅速对web祈求作出服务,来最小化客户端响应时间。
在webserver中使用当前流行最短剩余进程解决时间调度(SRPT),用来对平均响应时间进行优化,它优先考虑了对短文献祈求。
然而它只考虑文献大小来决定祈求优先级,没有对网络和终端系统之间交互隐含潜在有用调度信息进行捕获。
基于SRPT调度方略,咱们提出并实现了一种SWIFT算法,它侧重于把服务器和网络特性相结合。
咱们基于所祈求文献大小和客户端与服务器之间距离,来对祈求进行优先级排序,对进入到网络中包进行更细粒度控制。
不同于SRPT只关注于祈求大小,咱们SWIFT算法基于祈求大小和传播延迟两个方面,对祈求进行优先级排序。
祈求大小约等于文献大小,传播延迟约等于平均来回时间。
咱们使用一种轨迹驱动web祈求发生器,假设RTT嵌入在了祈求之中,从而来预计平均来回时间。
基于这两个参数,SWIFT算法得以实现。
咱们在WAN环境中测试了SWIFT效果,成果显示,对于大尺寸文献,SWIFT比SPRT机制有2.5%-10%性能提高。
2.8自适应客户端对象复制机制
由于复制高成本(重要是在一致性管理中发生)和资源约束性、节点异质性、以及应用程序行为高度动态性,在普适环境协作应用中使用对象复制时不可行。
因而,本文提出一种自适应复制机制,在执行期间,以提高响应时间性能为目,能在客户端节点处动态地创立和释放复制品。
这既基于运营时执行环境信息,也基于客户端和服务器节点应用程序行为。
与不复制和所有复制机制相比,对自适应复制算法在资源运用率和响应时间上做了模仿。
成果显示与不复制或所有复制相比,自适应机制能在大范畴执行环境内,提高响应时间,与全复制相比,它使用了更少同步开销。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 缩短 响应 时间 专项 方案 RESPONSETIME