一个Web服务的性能瓶颈分析及对策

1、 引言 

QoS(Quality of Service，服务质量)控制技术作为下一代网络的核心技术之一，越来越成为计算机网络中研究与开发的热点问题。QoS控制的基本目标是为Internet应用提供性能保证和区分服务。随着Internet上Web应用的爆炸性增长和电子商务的飞速发展，如何为用户提供满意的服务性能保证成了一个新的研究课题，由于传统的Web服务器无法为Web应用提供服务区分和性能保证，因此，随着QoS技术研究和应用的深入，Web QoS作为QoS技术的一个新的重要研究领域应运而生。这种面向Web客户和Http请求的技术，是属于应用层的QoS，是企业对企业交易的一个重要条件，也是Web服务器中的一个必要元素，它度量的是用户在与Web站点进行交互时所感受到的服务性能，如：交易时间，交易的可靠性等等。在Web服务应用程序的实现中需要满足各种QoS属性，比如：可用性、可访问性、完整性、性能、可靠性、常规性和安全性等[1]。 

目前，Web QoS控制研究已经越来越受到国内外学界和业界的重视并取得了一定的成果。概括起来，实现Web QoS控制技术可以分为这样几大类：Web请求的分类机制、Web服务器软件的QoS控制机制、操作系统的Web QoS控制机制以及Web服务器集群的QoS控制机制。本文主要研究一个Web服务的性能瓶颈，并对其进行分析，提出相应的策略。 

2、 Http对Web QoS的影响及对策 

由于底层消息传递和传输协议的局限性，Web服务会遇到性能瓶颈。然而，对公众普遍接受的协议（例如 HTTP 和 SOAP）的依赖却使它们成了必须承担的永久的负担。因此，本文对其加以分析并得出相应的解决措施。 

2.1、 Http成为制约Web服务性能的一个瓶颈 

Http是一种尽力而为的传输服务，是一个无状态的数据转发机制，它不保证数据包会被传输到目的地，而且不保证数据包到达的顺序。因而产生一个可怕的问题：在没有可用带宽的情况下，数据包就会被简单地丢弃。这样，许多服务级别高的付费用户就无得到服务级别的保证。比如：企业和企业之间的交易就比一般的浏览需要更可靠的服务保证，一个股票在线交易就比普通的下载更加需要实时保障。所以，随着运行在网络上的用户和数据量的增加和电子商务的飞速发展，在有限带宽和网络资源的条件下，Http显然是一个制约Web服务性能的一个瓶颈，Http协议无法为Web服务器提供区分服务和性能保证。 

虽然可以使用新设计的协议如“可靠 HTTP”（Reliable HTTP，HTTPR）、“块可扩展交换协议”（Blocks Extensible Exchange Protocol，BEEP）和“直接因特网消息封装”（Direct Internet Message Encapsulation，DIME） [2],但这些用于 Web 服务传输的新协议（如 HTTPR 和 BEEP）的广泛采用还需要一些时间。因此，使用 Web 服务的应用程序设计人员在设计系统时应该理解 Web 服务的性能问题，比如延迟和可用性。下面给出了一些改善 Web 服务性能的策略来解决这个问题。 

2.2四解决策略 

2 .1.1使用异步消息队列 

习惯上，许多应用程序使用同步消息传递，当在自己的计算机上运行应用程序时，同步的消息传递是没什么问题的；组件通信的延迟以几毫秒计。但是，对于 Web 服务来说，它们是通过因特网进行通信，这意味着延迟要以几十、几百甚至几千微秒计。 

依赖远程 Web 服务的应用程序可以使用消息排队来改善可靠性，但要以响应时间为代价。 一个企业内的应用程序和 Web 服务可以使用消息排队如“Java 消息传递服务”（Java Messaging Service，JMS）或 IBM MQSeries 进行 Web 服务调用[2]。企业消息传递为整个企业内的关键数据异步交换提供可靠、灵活的服务。 消息队列有两个主要优势： 

(1)它是异步的：一个消息传递服务提供者可以在消息到达时向请求者传递消息，请求者不必为接收消息而请求消息。 

(2)它是可靠的：消息传递服务可以确保一条消息被传递一次，且仅传递一次。 

将来，因特网上的发布和订阅消息传递系统如 alphaWorks 上的 Utility Services 包可以用于 Web 服务调用[3]。 

2.1.2对到来的Http请求进行分类 

实现Web QoS的一个重要环节是对到来的Http请求进行分类，在传统的Web服务中 HTTP的请求是直接由工作进程侦听的,它对于所有的请求均采用先到先服务的处理方式，显然这种方法忽略了客户的优先级别。现在通常使用一种用连接管理模块，可以对不同的请求进行分类，并设定其优先级，这样就可以实现对不同用户的差别服务。请求分类是实现Web差别服务的核心模块，它对不同的请求设定不同的优先级并将其放入相应的队列。分类的方法有很多，可以根据实际的需要进行选择，目前常用的方法可以分为以下几类： 

（1）   根据不同的用户分类 

要对客户进行分类，客户可以按服务器的要求输入一定的信息，服务器以此来判断客户的身份。一种方法是用客户的IP地址来区分客户，这种方法是在QoS Web服务器模型中，服务器可以对客户的服务请求设定不同的服务等级，按照预先定义的资源分配策略对客户的服务请求作出响应[4]。这种方法具有占用带宽小，容易实现，客户等等时延小的优点。但缺点是客户端的IP地址经常会被代理服务器或者防火墙所屏蔽，因此它的应用也受到限制。 

另外一种方法是基于Http Cookie的分类，它是将Web Cookie嵌入Http请求内，以表明客户所属的类别。HTTP请求中的Cookie是可以由服务器发送给浏览器的唯一标识符，它可以内嵌在HTTP请求中，用来表示不同的服务级别。服务商可以给某个特定的服务提供一个永久的Cookie以供给用户使用。这样，就可以为付费用户和免费用户设置不同的优先级，利用cookie 来识别用户信息,记录下用户在一段时间内的访问倾向,例如经常浏览哪一类的网页,或者常常购买哪一类的商品;并将有相同兴趣的用户归类分组。当用户访问网站时,服务器可以根据他们的兴趣倾向推荐他们可能接受的网页,而且可以预测用户将来可能的行为,以此来提高服务质量。 

和基于Http Cookie的分类相似，基于浏览器plug-in的分类是将特定的标识符嵌入Http请求内以表明客户所属的类别。浏览器中的plug-in插件是内嵌在客户端的又一种标识方法，购买了某种优先级服务的用户可以从服务器端下载特定的插件，把它放入HTTP的请求中。这些方法可以对客户进行分组，从而对高级别的客户提供更好的Web QoS保证。 

以上这些方法虽然很准确，但是比较繁琐，增加了客户的等待时延，同时也为判断客户的身份占用了额外的带宽。

（2）   根据请求的目标分类 

根据请求的目标所特有的一些属性和特点，我们可以对客户进行分类。我们都知道，由于URL请求类型或文件名路径可以区分不同请求，以及若多个站点访问同一Web服务器节点的时候，服务器可以识别其IP。所以可以用基于URL请求类型或请求的文件路径的分类和基于目标IP或端口的分类两种方法来实现Web QoS控制。这种分类方法同样也可以为高级别用户提供优先服务。较好地消除由于在网络少量较大时，由Http协议而产生的瓶颈[5]。 

不同的URL请求类型或者不同的请求文件路径表明了请求的不同的重要程度，在这种情况下请求的重要性与发送者是无关的。它侧重于对于不同的请求动作和请求目的进行分类。按照其重要程度，一般可以将请求分为紧急的 (Mission-critical) 、对时延敏感(delay-sensitive)的、和尽力而为(best-effort)传送3种。 例如,在电子商务应用中，购买商品的用户显然应当比仅仅浏览的用户获取更高的优先级目的地的IP地址，如果在同一个网络节点中架设多个Web站点，那么就要用目的地址来区分请求的重要性。 

（3） 利用其他网络参数 

Web服务器也可以将传输和路由中对数据包分级的参数集成到自己的连接管理模块中。例如,在因特网的差分服务体系中,IP数据报头的TOS域常被用作包的优先级标识,Web服务器可直接从IP头取出TOS域中的数据作为请求的优先级[5]。这样，也可以达到高级别用户服务的保证。 

2.1.3、通过备份使服务平滑降级 

在每个服务器上存储多份不同质量的Web 内容。当服务器超载时,可以使服务器有选择地为客户提供适宜质量的Web 内容,即以体面的方式为低优先级客户提供平滑的服务降级[6],而保证高优先级的客户不会受到降级服务。这样就可以在服务器过载的情况下自适应地提供连续的内容降级服务而不是简单地拒绝请求,从而能够更好地为用户提供Web QoS。 

2.1.4、其它的保证Web Qos的方法 

除了上文中所述的方法之外，我们还可以提供主动Web服务 QoS 的方法，如服务请求的高速缓存和负载平衡，服务提供者可以主动向服务请求者提供很高的 QoS。在Web服务器级别上和 Web 应用程序服务器级别上都可以完成高速缓存和负载平衡。负载平衡区分各种类型通信的优先次序，并确保适当地按照每个请求所表现出的价值对待它。 

3、 结论和展望 

随着Web 服务的广泛扩大,服务质量QoS 将变成一个判定服务提供者是否成功的重要因素。QoS 决定服务的可用性和实用性, 本文所列出的消除Http对于Web服务性能瓶颈的方法针对性强，易于实现。随着Web QoS研究技术的发展，基于中间件技术和Web服务器集群的QoS控制机制必将给Web提供更可靠的服务保障，有待我们进行更深入的研究。 

 

 

http://baalwolf.iteye.com/blog/1322302