Web Services 应用程序效能调教

Web Services 应用程序效能调教

作者：胡士亮 (台湾微软平台架构技术副理)

响应速度与延展性是在这个 IT 世代是决定应用程序成功或失败的关键。效能不佳的应用程序会造成企业营利上的损失，包括降低员工的生产力、增加开发与硬件成本、损害客户关系等等严重的问题。不管对程序开发者或者系统管理者来说，应用程序效能调教一直是心中永远的痛。对 Web Service 的开发者来说，这个问题更加严重。Web Services，包括 Web 接口的应用程序与在服务导向架构 (SOA) 中扮演重要角色的 Web Service，必须面对 Internet 上突然暴增的要求数量，更凸显了应用程序效能管理的重要性。但是对开发人员来说，传统的开发流程从使用者需求开始，到测试与上线为止，几乎把所有的时间放在如何把使用者的功能需求开发出来、和程序臭虫 (Bug) 搏斗以及赶在产品上市前完成这几件项目上，至于效能部分往往是上线运转之后才开始面对。如何在设计规划效能良好的架构、如何开发使用资源少执行速度快的程序代码、如何测试取得应用程序的效能数据、如何部署应用程序避免硬件瓶颈、如何持续侦测管控上线后的效能状况与问题一直困扰着信息专业人员。

为了妥善管理 Web Service 应用程序效能，在应用程序开发过程中必须考虑下列事项：

设定效能目标:
在使用者需求分析阶段增加效能目标设定资料，并将效能目标加入系统功能需求书中。效能目标应该要包括下列项目：
响应时间 (Response time)：系统执行特定功能所需时间，例如网络下单确认。
处理能力 (Throughput)：每秒支持的工作量。包括每秒要求次数 (Request per second)，每秒交易次数 (Transaction per second) ，每秒网络流量 (Byte per second)。
资源使用量 (Resource Utilization)：系统执行特定功能时使用系统资源的百分比与使用时间。包括处理器、内存、硬盘存取、与网络存取等。
工作量 (Workload)：使用者使用系统的习惯，包括最大使用者人数、同时上线人数、资料量、交易量、与交易种类等。
设计阶段效能考量
在设计阶段将效能需求放入系统分析中。目前许多人常用 UML 来进行系统分析与设计，而在效能考量部分则是使用 Performance Modeling 来协助评估系统架构以符合效能目标。Performance Modeling 可分为以下八个步骤：
确认主要使用情境 (Scenario)：找出最在乎执行效能的使用情境，这些使用情境会对整个应用程序的效能造成威胁。
确认工作量：找出系统需要支持多少使用者与同时存取人数。
确认效能目标：订定每个主要使用情境的效能目标，效能目标符合企业需求。
确认预算：订出硬件预算与限制，包括处理器、内存、硬盘存取、网络支持的最大运算能力
确认处理流程：将主要使用情境处理与系统组件的互动流程订定出来, 可以配合使用 UML Use Case Scenario
分配预算：经步骤 4 的预算分配到步骤 5 的处理流程上并满足效能目标
评估：评估系统设计是否符合目标与预算，您可能需要调整设计或重新分配预算来满足效能目标
验证：验证您的设计符合目标与预测，透过不断重复的雏型、测试、评量来确认设计是正确的
效能测试
效能测试是评估应用程序能否支持预期与尖峰工作量，以及是否能够延展来提高容量。效能测试包括下列步骤：
确认主要使用情境：找出需要测试潜在效能问题的使用情境
确认工作量：订出上项情境中所需支持的使用者与同时存取人数，这可以从需求中找出平时与最大使用者人数。
确认测量数据： 订出效能测试时所需收集与应用程序相关的测试数据用来找出潜在的效能瓶颈。
建立测试范例 (Test Case)： 建立测试范例，需包含测试所需的步骤与预期结果。
压力测试：透过工具来执行测试范例的压力测试，并收及相关测量数据
分析结果：分析压力测试所收集到的相关测量数据。
效能调教
效能调教流程是不断重复的找出系统瓶颈并消除直到应用程序达到预计的效能目标为止。整个过程包括建立效能基准 (Baseline)、收集测量数据、分析数据找出效能瓶颈、调整系统设定、再度收集测量数据以确认调整结果
以上就是完整的应用程序效能管理所需的步骤。接下来举一个 Web Service 应用程序效能调教的实例。

客户的 Web 应用系统包括前端 Windows 2000 IIS 网站服务器，应用程序使用 ASP 与 Visual Basic 6.0 开发的 COM+ 组件，后端 SQL 2000 资料库存放的大量的客户与商品资料，应用程序透过 ADO 对象存取数据库。这套应用系统在离峰时间并没有太大问题，系统响应时间都在可接受范围内，问题是发生在晚上 6 到 10 点的尖峰时间中，系统常发生响应时间超过 1000 秒、IIS 500 内部错误、IIS 500.13 Server too busy 等问题造成使用者抱怨不断。

在开始执行效能调教步骤，先收集网络、系统、平台、应用程序相关效能数据。在网络、系统与平台这部分使用Windows 2000 内建的效能工具来收集效能信息，共收集下列效能项目与对象：

Active Server Pages\Requests Queued
Active Server Pages\Requests/Sec
Active Server Pages\Sessions Current
Memory\Available Bytes
Memory\Pages/sec
PhysicalDisk\% Disk Time
PhysicalDisk\Current Disk Queue Length
Processor\% Processor Time
Web Service\Byte Received/sec
Web Service\Bytes Sent/sec
Web Service\Current Connections
Web Service\Maximum Connections

图 1 Windows 2000 内建效能工具

分析收集到的效能信息发现，Web Server 在晚上 7 点到 11 点的尖峰期间 ASP/Request Queued 值高达 71，并且超过 20 以上的时间持续5分钟以上，表示 ASP 程序有执行时间过长的问题。数据库服务器在尖峰时间 PhysicalDisk\Current Disk Queue 最大值 117，且平均值超过 16，表示硬盘 I/O 速度不够快；SQL Server\Table Lock Wait Time 最大值 1328 秒而且不只一次，表示 SQL 有 Lock/Block 问题；SQL Server\Full Scan/sec 最大值 1108 平均值 34，表示对数据库的查询没有使用索引，由于效能资料发现 ASP/Request Queued 值很高，表示 ASP 程序有执行过长的问题。为了找出是哪些 ASP 程序有问题，我们可以透过分析 IIS Log 来发现。在使用 IIS Log 来找出执行时间过长的问题时，首先我们必须先增加 IIS Log 的纪录字段包含 Time Taken 字段，这个字段存放 ASP 程序在服务器端的执行时间。

图 2 设定 IIS Log增加Time Taken字段

由于 IIS Log 的大小十分庞大，必须使用工具来分析。我选用的工具是 SQL Server DTS + OLAP + Excel 数据透视表来进行分析。首先先使用 SQL DTS 将 IIS Log 资料汇入数据库，接着建立 OLAP Cube，在使用 Excel 数据透视表来进行分析的工作，很快就能所订执行时间过长的 ASP 程序与发生问题时间与错误类型

图 3 Excel 数据透视表显示各类型档案执行笔数与最长最短时间

图 4 ASP 程序执行时间超过 60 秒笔数与执行结果

图 5 ASP 程序执行错误数量分布

透过找出发生问题的 ASP 程序并分析 ASP 程序执行时间花费过长的部分进行效能调教，可以改善发生问题最严重的程序，接着在收集效能资料继续找出造成效能问题的瓶颈家以改善。根据 80/20 法则，80% 的效能问题是由 20% 的程序造成，找过几轮后就可以发现 Web 应用程序的效能显著改善，减少开发与管理者的压力并且让使用者能更顺利的完成每日工作，提高生产效率。

以上是针对 Web Service 应用程序效能调教方法简介与案例介绍，希望能让您更了解如何来进行效能调教的工作。