ASP_3高级编程--第26章___优化ASP的性能
下载
第26章 优化ASP的性能
有些性能指标,例如正确性,是只有在其不出现时才被人们注意到的品质特征。如果能
努力地改正网站中的所有错误,并不断提高其工作性能,那么其用户很少会提意见。如果网
站存在少量错误,或者是运行缓慢,那么其用户们会产生抱怨。
本章将介绍与A S P工作性能有关的几个重要概念,提供一些优化 A S P工作性能的方法和应
注意的事项。
本章的主要内容如下:
• 以处理速率和响应时间衡量性能指标。
• 硬件的性能。
• 脚本优化。
• NT Performance Moniter 和 ...
下载
第26章 优化ASP的性能
有些性能指标,例如正确性,是只有在其不出现时才被人们注意到的品质特征。如果能
努力地改正网站中的所有错误,并不断提高其工作性能,那么其用户很少会提意见。如果网
站存在少量错误,或者是运行缓慢,那么其用户们会产生抱怨。
本章将介绍与A S P工作性能有关的几个重要概念,提供一些优化 A S P工作性能的方法和应
注意的事项。
本章的主要内容如下:
• 以处理速率和响应时间衡量性能指标。
• 硬件的性能。
• 脚本优化。
• NT Performance Moniter 和 Web Application To o l(WA S)等工具。
• 会话和应用程序状态。
• 进程隔离、组件和线程模型。
最后,我们用一些综合技巧结束本章的内容,这些技巧在实践中行之有效,而且可以用
来改善网站性能。首先,让我们考虑一下应该用什么样的尺度来衡量 A S P的工作性能。
26.1 衡量工作性能的
在研究如何提高ASP 的工作性能之前,我们需要来理解两个基本的指标:吞吐量和响应
时间。
吞吐量(T h r o u g h p u t):是指服务器处理请求的速率。从网络管理员的角度来看,可以实
现的吞吐量越高越好。如果能够提升网站潜在的吞吐量,就可以应付日益增加的用户请求;
就能处理更多的事情;而且也可以因此推迟升级服务器的硬件。
响应时间(Response Ti m e):是指从客户开始提出请求到接收到响应最后一个比特之间
的时间。响应时间越短越好。用户很在意响应时间,对全系统的吞吐量不太关注。
26.1.1 吞吐量
吞吐量通常用每秒或每天的请求次数来衡量。有时,使用页请求数比使用请求次数更有
意义。当浏览者要求得到一个 H T M L页面时,一般会紧跟着发出与图片和网页有关的独立请
求,其中图片一般都标有< I M G >的标记。这些紧密联系着的请求被视为一个页面请求。
另一个近似衡量吞吐量的方法是客户数量除以客户的“思考时间”。例如,假如有 1 0 0个
客户,平均每人用2 0秒阅读一个网页,那么吞吐量就是 1 0 0 / 2 0,或者说是每秒回答5次。吞吐
量并非
示阅读一个网页需要的时间,表明请求多快才能到达服务器,服务器要多久才能对
它们做出响应。
吞吐量受许多变化因素影响。其中之一就是带宽,带宽是用来计量每秒能够传输多少数
据的物理量。如果使用一条 I S D N线来连接到 I n t e r n e t,那么由于 I S D N很容易饱和,相对较低
第26章 优化ASP 的性能计计783
下载
的带宽将成为限制性能的主要因素。带宽是限制网络服务器向用户快速传递内容的一个主要
因素。
网页尺寸(Page size)同样影响吞吐量。传递的网页越大,每页花费的时间越多,每秒
可以传递的网页越少。如果可以减少网页的尺寸(尤其是嵌入式图片的尺寸,这些图片往往
是最大的文件),不仅可以提高吞吐量,而且减少了响应时间;也就是说,客户看到完整一页
所需的时间更少。
复杂的应用程序(Complex application)会降低吞吐量。如果每一个请求都需要花费较长
的时间来执行,那么每秒可以处理的请求数就比处理简单的申请时少。对于动态内容来说,
C P U的性能是影响吞吐量的主要因素。
在速度较快的局域网上,H T T P的连接是几乎瞬时完成的。但是,在相对较慢的广域网上,
例如I n t e r n e t,它的连接就需要几秒钟。同时,由于每一个连接都要使用服务器资源,所以并
发连接个数成了重要的指标。
有两种方法测量吞吐量:
一是使用性能监视器(Performance Monitor)来读取由网络服务器产生的吞吐量统计数据。
对于静态文件来说,N T性能计数器为Web Service (_Total) | Get Raquests/sec;对于A S P来说,
N T性能计数器为 Actire Server Pages | Requests/sec。本章的后面将详细讨论性能计数器。
二是使用装载产生工具,例如 WA S。在运行了一个特殊的测试程序后, WA S将报告吞吐
量和许多其他的统计数据。
26.1.2 响应时间
用户希望响应时间少于一秒,但是却很少能够实现。人们经常半开玩笑地称 W W W是
“世界范围内的等待( Wo r l d - Wide Wa i t)”。响应时间取决于网络延时、请求在服务器端排队
的时间及服务器处理请求的时间。
WAS 提供获得第一个比特的时间( T T F B)和获得最后一个比特的时间( T T L B)
的统计纪录。
网络延时是一个数据包从一个地方传送到另一个地方的时间,它受以下几个因素的影响:
网络拥挤度、链路的质量、链路的带宽、链节点间的物理距离,与目的地之间的中继站或区
域的个数和在路由器和网关的等待时间。
延时既受到请求从客户端传递到服务器端的时间的影响,也受到从服务器端到客户端返
回响应的时间的影响。在大多数情况下,响应时间既不受客户控制也不受服务器控制。
窄带设备,例如调制解调器,延时更长。相反,宽带设备通常延时较少,不过并非总是
如此。两个通过微波、卫星连接的系统,每秒可以传递几百万比特的数据,但如果仅把单个
数据从一个终端经卫星传送到另一个终端的话,花费的时间比在局域网内传输要长。
即使从客户端到服务器的延时为零,任何一个请求在排队等待接受服务器处理时仍要花
费时间。请求排队时间取决于队列的长度和服务器处理每个请求的时间。队列的长度与服务
器的负荷成比例。
请求执行时间是响应时间的最后一个组成部分。它是唯一的一个服务器可以控制的量。
较长的处理时间会减低吞吐量。减少执行时间是本章的主要任务。
业务量特性曲线
另一个概念是业务量特性曲线,业务量曲线在一天内并不平坦。地区性的新闻网站在清
晨、午饭时间和傍晚会有较重的业务量,但在半夜却非常闲,这时其主要读者已经睡着了。
在业务较重的时间,服务器可能要处理三到五倍于 2 4小时平均业务量的业务。新闻网站在发
生突发新闻事件时会偶尔遇到尖峰业务量。
显然,一个We b站点必须不仅可以处理平均业务量,也必须有足够能力应付一
天中可能的高峰,而且它的速率最好能应付得了最高容量。
从长远角度看,应该建成一个可以适应日益增长的业务量的成功网站。不要让服务器超
负荷运转。如果平均业务量占用了 C P U资源的5 0 %,那就可能不能很好地应付业务量的高峰。
使用NT Performance Monitor来了解站点的工作情况。 PerMon 可以把所有计数值记录到一个
日志并在NT 事件日志中报警。
26.1.3 衡量性能的其他指标
如前所述,衡量工作性能最基本的标准是吞吐量(服务器每秒可以处理的请求数量)和
响应时间(处理一个指定的请求有多快)。作为一个网络管理员或者 A S P应用程序开发者,最
关心的是使吞吐量最大,因为它既能够使网站可以处理更多的下载请求,还可以推迟升级硬
件。与此不同,用户希望响应时间越短越好,因为他们已经厌倦了“世界范围内的等待”。
其他的性能指标也是非常有用的。这些指标是兆赫费用、资源利用率和多处理器可扩展
性。兆赫费用是一种估计执行一个动态网页有多“贵”的方法,而且它还能帮助你推断出通
过改换不同的硬件可以得到的性能。使用的资源越少,可用空间就越大,而且对多用途的服
务器来说,就越是好成员。在单处理器系统上开发的应用程序在多处理器系统中并不能自动
地扩展。
1. 兆赫费用
兆赫费用使用每秒每个请求的兆赫值表示,即:兆赫费用 = CPU数量×C P U速度×C P U利
用率/每秒请求数。例如,如果一个双奔腾 I I服务器的工作频率为3 3 3 M H z,系统可以利用6 0 %
的C P U资源稳定地工作在8 0页/秒的速度上(由Task Manager 或Performance Moniter实测得到),
即:
总频率为2×333 MHz = 666 MHz,可利用的频率为:6 6 6×0.60 = 400 MHz,因此,4 0 0
MHz / 80页/ 秒 = 5 (M H z /每秒页),所以,兆赫费用为5 MHz/每秒页。
兆赫费用与吞吐量等其他指标相比有一定的优点,它使得规划系统的容量变得相对容易。
例如,尽管系统B与系统A的硬件不同,假如两个系统的 C P U个数相同,并且一个页面的兆赫
费用一定的话,则页面在系统 A与在系统B运行的兆赫费用基本相同,只是在速度较快的机器
会略高一点。
然而现在还不能把兆赫费用看得太重;它仅仅是一个估计值。对动态内容的处
理能力还无法确定。
例如,网站上最高层的主页的兆赫费用为 3,搜索网页是2 5,订单网页是1 5。网站可承受
的速率是每秒有5 0个客户访问最高层的主页,一人在搜索, 2人在下订单,同时还需有一些剩
余能力用来对付业务高峰和满足其他网页的用户的要求。网站的兆赫费用多大才能满足需
求?
784计计ASP 3 高级编程
下载
第26章 优化ASP 的性能计计785
下载
(5 0×3)+(2×1 5)+(1×2 5)= 150 + 30 + 25 = 205 MHz
考虑到系统业务高峰时的冗余,至少要使系统的兆赫容量达到 3 0 0 M H z,才可以满足需求
了。
建议系统的平均工作量不超过 C P U资源的5 0 %,否则将不能很好地应付业务量
的高峰。
这个网站的工作频率为4 0 0 M H z是比较安全的。
2. 降低C P U的占用率
很明显, C P U占用率越低越好。如果可以优化网页使其可以运行得更快且占用最少的
C P U资源,那么网站就有更多的能力来应付业务高峰。另外,对于运行在同一系统上的数据
库和电子邮件服务器等其他服务来说,希望让给它们尽可能多的 C P U资源。
3. 降低带宽的占用率
即使是专用的网络服务器也不得不与其他系统分享网络资源。因此,应该尽可能地占用
较少的网络带宽资源。这不仅仅意味着可以给其他系统留下更多的带宽,还可以使网络服务
器达到更高的吞吐量和提供更短的客户响应时间。有三种方法可以实现这一目标:
• 第一种方法是为每个请求传递较少的数据。去掉 H T M L文件中的空格;发送一部分结果
以代替整个结果;发送尽可能少的图片,并且通过剪切使图片尽可能小,或使用较高压
缩比例的 J P E G和颜色较少的G I F方式使图片变小。
• 第二种方法是减少客户与服务器在网络上的往返时间。服务器可以下载给客户的信息越
多越好。往返时间经常由于网络的等待时间而变长,并由此增加了服务器的工作量,还
占用了网络的带宽资源。优秀的客户可以用客户端脚本来验证数据;使用 D H T M L来改
变显示器的显示图案而不用请求从服务器下载新的 H T M L文件或图片;用R D S来巧妙地
处理A D O记录集;用X M L来转换数据等。
• 第三种方法是数据缓冲。把数据寄存起来,然后一次性发出可以节约网络资源的占用。
IIS 4.0的缺省值并不缓冲A S P动态网页,而 IIS 5.0的缺省值是缓冲A S P动态网页。
每一个R e s p o n s e . Wr i t e和H T M L段分别传递给客户的。每个数据包内都加上了描述性的报
头;每一次传递都需要花时间来完成;每一次传递都给网络增添了阻塞问题。这就像分几次
从超级市场买回采购单上的物品而不是一次把所有的东西都买回来一样。 T C P / I P
有一种
慢开始的算法,它先传递一个数据包,然后是一次两个,再一次传递四个,如此下去,直到
建立起最大的数据传输速率为止。如果一个网页被分割成许多小的部分来传送, T C P / I P对每
次传递都有一个慢开头的数据流,而不是对整个数据仅用一个慢开头的数据流。当整个网页
被缓冲后,T C P / I P会变得更高效,尤其是在等待时间较长的连接上。
4. 多处理器的可扩展性
理想情况下,在单处理器系统中增加一个处理器可以使吞吐量加倍,再加两个处理器可
以得到四倍的处理性能。但是,实际中一个应用程序很难在多处理器系统上扩展。 IIS 4.0可
以很好地出从一个处理器扩展到两个处理器,但超过两个就不行了。 IIS 5.0可以扩展到出4个
甚至是8个处理器。
图2 6 - 1表示了在 IIS 5.0中A S P的性能改善情况。它表明了一个经常使用 L o o k u p Ta b l e组件
的不太复杂的A S P脚本(大约1 0 0 0行的代码,产生约25 KB的H T M L文件)在 IIS 5.0中的性能
改善情况。
图26-1 IIS 5.0中A S P的性能改善情况
应用程序无法很好地扩展的原因是资源争用和串行化过程。每一个线程都在争用共享的
资源、组件的关键部分或系统总线。当一个线程对某一资源进行独占访问时,其他线程被阻
塞,只有第一个线程释放这些资源,其他线程才能再使用这些资源。资源的使用是串行的而
不是并行的。由于单处理器系统在一个瞬间实际只有执行一个线程,所以这种问题不容易出
现。对有n个处理器的系统,同时执行 n个线程,就会出现资源争用问题。
如果A S P应用程序要在多处理器系统上使用,首先必须对应用程序在多处理器
系统上的可扩展性和性能进行测试。
通过测试可以把一些诸如线程安全、死锁等问题及发现的其他问题从应用程序中清除掉。
26.2 改善服务器的硬件性能
必须有合适的硬件支持,才可以满足现在的要求和将来可能的负荷要求。一个奔腾 1 3 3也
许足以应付小部门的网络服务要求,但却不能满足一个繁忙的商业站点的要求。
26.2.1 内存
服务器有足够的物理内存是至关重要的。如果没有足够的物理内存,那么,改善服务器
性能的最简单最有效的方法就是增加内存。虚拟内存子系统虽能很好地工作,但是系统的吞
吐量将会大大降低,因为系统将很多的时间用在内存与硬盘之间的页面交换上。即使系统有
足够的内存,增加内存仍能提高系统性能。 I I S的核心需要大量内存来高速缓存存储静态文件,
A S P需要内存来存储编译了的A S P文件和A S P会话数据。
可以使用N T Performance Monitor来诊断内存问题。在 IIS Technet 网站和 M S D N
网络服务器技术站点上,有些文章对这一问题做了进一步的讨论 ,微软出版社出版的
《IIS Resource Guide》对这一问题也进行了研究。
1 2 8 M B是专用网络服务器的最小内存数,增加到 2 5 6 M B较好,如果是任务比较繁重的商
业网站,内存应为 5 1 2 M B到1 G B。增加内存可以改善服务器的工作性能,最终将逐渐接近系
统的最高性能,例如,少数服务器的实际内存为 2 G B。
786计计ASP 3 高级编程
下载
IIS 5 中的ASP 性能提高
进程
内
进程
外
进程
内
进程
外
进程
内
进程
外
26.2.2 硬盘
硬盘用来存储静态的内容( H T M L文件和图片)、程序、脚本、日志文件和数据库等。对
许多的网站来说,标准的 E I D E或S C S I硬盘就够用了。将系统文件、数据库、日志文件、临时
文件和网页文件分别存储到不同的物理硬盘上,可以减少硬盘磁头的寻找时间,从而改善性
能。硬盘工作量较多的网站应该使用 RAID 0、RAID 1或RAID 5 硬盘子系统来提高硬盘的吞
吐量。一定要确定硬盘的工作瓶颈不是由过度页面交换所致。
26.2.3 网络带宽
确保有足够的网络带宽可以满足网络服务器的负荷要求,确保有合适的网卡和网络交换
器。快速的以太网(1 0 0 M b p s)在大多数情况下能满足需要,主要的问题是费用太高。
26.2.4 CPU
用I I S传递静态文件非常高效,但是要产生一个动态文件就要占用许多 C P U资源。如果服
务器经常满负荷使用 C P U,那就应考虑换一个速度更快的 C P U了。如果已经有了一个较快的
C P U,那就要考虑增加第二个。如果使用 IIS 5.0,就可以考虑增加到4至8个C P U。
还要确定C P U有较大的二级缓存,每个至少 1 M B。C P U的二级缓存要比内存快得多。如
果缺乏二级缓存,将影响系统的性能。
26.2.5 更多的服务器
有时,一台机器是不够的。它可能应付不了现有工作量。拥有更多的机器可以得到更高
的可用性,即使有一台机器坏了,网站仍能继续正常运行;也就是就没有单一故障点。
可以有几种选择。如果 We b服务器上正在运行一个数据库,可以把数据库转移到后端服
务器上,这样可以减轻服务器的负荷。特别是对于一个 We b阵(许多机器作为一台逻辑网络
服务器使用),多服务器更是非常必要的。我们将在下一章详细介绍 We b阵。
26.3 性能的调整
总体来说,静态内容很少会有性能问题。性能问题常常是由于服务器的硬件不足(尤其
是缺少内存)、带宽不够或网络等待时间长而产生的。然而, I I S和其他现代的网络服务器都
擅长传递高容量的静态文件。
许多性能问题发生在动态内容上。但不幸的是,这些问题是无法确定的,比较难解决。
有无限种方法可以用来编写 A S P网页,可它们中的许多是低效的。即使是在像 A S P或I S A P I这
样完善的系统中,应用程序开发者仍可能写出低效率的代码。
26.3.1 解决性能问题
首先,必须设置一些合理的目标。例如,指定网站应有能力每秒传递至少 5 0个A S P网页,
且只使用不超过4 0 %的C P U资源,在低于平均负荷时,9 5 %的请求的响应时间低于5秒。然后,
用最大负荷(或可能的峰值负荷)和平均负荷来衡量网站的工作性能。
最大负荷是指使用 WA S等工具在服务器上产生的极高负荷,它使服务器的 C P U
第26章 优化ASP 的性能计计787
下载
或网络饱和。
给出可持续的服务器吞吐量的上限,用平均负荷来测试网站性能看是否达到这一目标。
平均负荷量应该根据原始数据或猜测值来模拟。在可能的峰值负荷下测量网站的工作性能可
以检测机器在最繁忙的情况下工作得如何。
如果网站性能达不到要求,就需要找出影响性能的最主要问题,然后解决它。在找到和
解决了这个问题后,应该重新进行测量,重新调整,直到获得了满意的性能或从机器中榨取
出最后一点性能为止。如果还不满意,还可以选择:
• 增加新硬件。
• 重新现实地确定性能指标。
• 把A S P应用程序的关键部分重写成C O M组件或一个 I S A P I。
26.3.2 强度工具
调节工作性能的关键因素是要知道应用程序的工作。为分析工作,建立一个受控环境是
非常重要的,因为这样可以得到有关负荷能力的正确数据。为了模拟几百个并发客户的行为,
使用多台客户计算机是很必要的。测试应在不受一般的网络活动和尖峰信号干扰的独立网络
中进行,这样得到的结果才是有用的。
受控制的强度测试环境的另一个组成部分是网络服务器。强度试验环境要在测试期间提
供一致的不受其他活动影响的环境。这就允许通过改变设置和脚本,来清楚地看到这些变化
的效果。换句话说,当进行性能分析和调节的时候,需要能够提供一系列一致的试验环境。
如果试验服务器兼任域控制器或邮件服务器,则试验结果将会因为调用的机器用于其他目的
而改变。
理想的情况是由拥有一个测试实验室,其硬件环境与站点相同。然而,这不是必需的。
最重要的是这个测试实验室只用于测试期间的测试过程。
一旦建立了强度测试实验室,可以选择多种强度工具。有多种选择,价格可以从免费的
到非常昂贵的,功能上从支持 HTTP 1.0规范到支持H T T P 1 . 1规范并有分析和报告的能力。如
果喜欢Web Application Stress(WA S)工具,可以免费从微软公司得到的,运行界面如图 2 6 - 2
所示。
图26-2 运行WA S的界面
788计计ASP 3 高级编程
下载
WA S可以从http: //webtool.rte.microsoft.com下载得到。该站点还提供了有关这个强度工
具的基础知识和综合指南。这个工具包括联机帮助,帮助非常完整,包含许多实例。
26.3.3 脚本优化
有个比喻:一根链条的强度就是其中最脆弱的那个环节的强度。这个比喻同样适用于评
价网络应用程序的性能。可能有几个脚本程序比其他脚本程序慢。然而,网络的性能正是由
于这几个脚本程序的存在变得极差。由于这几个脚本程序占用了可被其他脚本利用的资源,
应用程序的性能一般情况下会有所降低。增加环境切换会影响整个应用程序的性能。但如何
查明出现瓶颈的原因呢?毕竟,一个脚本程序有一些包含文件,还有相当数量的代码。我们
希望能够查明脚本的什么地方占用了时间,什么消耗了太多的处理器资源。我常用的方法如
下:
首先,运行强度工具来这个脚本程序以得到性能数据。假设有一个名为 P r o c e s s
R e q u e s t . a s p的脚本程序,当强度工具运行时,将得到每秒 1 0个请求。这是一个开始点,作为
参考。其次,在脚本程序的“中点”设置一个 R e s p o n s e . E n d,并且重新运行强度工具。例如,
如果P r o c e s s R e q u e s t . a s p有1 0 0行,那就可以简单地在第 5 0行插入R e s p o n s e . E n d。结果如何?脚
本程序的后一半将不会被执行。通过观察前一半的工作性能,可以知道瓶颈是在前一半,还
是在后一半,或者是平均分布在两部分之中。假设没有了后一半脚本程序,得到每秒 1 0 0个请
求而不是1 0个,现在就知道了是后一半的某些东西降低了速度。如果得到的结果与“开始点”
接近,
的范
围内使用时,是一个很好的应用程序。然而,却不利于快速传送大量数据。最好将其在 D a t a
Sources 面板中的驱动程序也删除。
在缺省状态下, A D O被设置成单元线程的。这可能是由于 A c c e s s仅支持通过O D B C驱动
程序的单元线程访问。 A D O支持多线程模型,使用这种方式可以使性能提高。有一个批处理
文件可以用来进行这样的转换。在典型安装的情况下,可以在 \ Program Files\Common
Files\System\ado 目录下找到它。在此路径下运行m a k e f r e l 5 . b a t,A D O可以转换成双线程对象,
同时支持单元线程模型和自由线程模型。同样,也有一个批处理文件可以返回单元线程模型。
当使用的A D O是2 . 5版时,其批处理文件及 D L L文件名中的“1 5”很容易把人搞
糊涂,因为1 5表示1 . 5版。D L L文件中的C O M能力改进了,但D L L文件仍然继承低版
本的名字。这尽管不直观,但这比相同的组件在不同的版本中使用不同的名字好。
尽管各个企业数据库的管理系统不尽相同,但它们仍然有一个共同之处:为了使其获得
较高的性能,需要足够的内存。如果有足够的内存支持缓存, I I S的表现也会更好。正因为此,
把I I S和S Q L分开放在不同的机器上是一个好主意。许多人马上就会想到由于计算机间的传输
问题会使系统的性能下降。然而,从使用情况看,大容量的内存、专用的处理能力及良好的
低层通信方法使得对数据库的访问速度极快。
如果数据库运行在一台独立机器上,使用数据库有两个可行的方案,两者都能提高网络
应用程序的性能。
第一,应用程序几乎全由数据库来驱动。在这种情况下,数据库需要足够的资源来有效
处理查询和缓存数据 .
第二个方案是另一个极端,很少使用从数据库来的数据。在这种情况下,把数据库独立
放在另一台机器上仍然十分有意义。这将使得处理主要业务量的网络服务器的资源不被数据
库占用。跨机器边界所付出的代价多于提高数据库和网络服务的效率所付出的代价。
一个数据库经常可以同时处理几个网络服务器的请求。
利用C O M +的特性,包括以前的 M T S,可以处理一些数据检查的工作。通过利用置于数
据库定义内的引用完整性校验,不用启动脚本显式地检查就可以找出相应的错误。利用 We b
页的事务可以进一步保护数据库数据的更新和插入。引用完整性检查在数据库中执行得要比
在脚本中快得多。例如,检查用户现在的地址提供的邮政编码和服务器提供的邮政编码表。
另外,要确保索引存在于被访问的表中。数据库引擎能做一项神秘的工作:当得知数据
库如何被访问的某些线索后,系统能自动调整性能。这些线索由已经建立起来的索引提供。
第26章 优化ASP 的性能计计795
下载
796计计ASP 3 高级编程
下载
发挥数据库中存储过程的优势:经常需要的例行程