-
【转】系统瓶颈分析经验举例
2008-10-23 17:29:18
经验举例1
交易的响应时间如果很长,远远超过系统性能需求,表示耗费CPU的数据库操作,例如排序,执行aggregate functions(例如sum、min、max、count)等较多,可考虑是否有索引以及索引建立的是否合理;尽量使用简单的表联接;水平分割大表格等方法来降低该值。
经验举例2
分段排除错误。测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器,这样,就可以在Web端测出的响应时间减去以上各个分段测出的时间就可以知道瓶颈在哪并着手调优。
经验举例3
UNIX资源监控(NT操作系统同理)中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。“Swap in rate”和“Swap out rate”也有类似的解释。
经验举例4
UNIX资源监控(NT操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器 。合理使用的范围在60%至70%。
经验举例5
UNIX资源监控(NT操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统、重新部署业务逻辑等,另外设置Tempdb in RAM,减低"max async IO","max lazy writer IO"等措施都会降低该值。
经验举例6
Tuxedo资源监控中指标队列中的字节数(Bytes on queue),队列长度应不超过磁盘数的1.5~2倍。要提高性能,可增加磁盘。注意:一个Raid Disk实际有多个磁盘。
经验举例7
SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。注意该参数值是从SQL Server启动后,就一直累加记数,所以运行经过一段时间后,该值将不能反映系统当前值。
-
如何写性能测试用例
2008-08-27 21:01:14
由于性能测试与功能测试有很大的区别,所以讨论出的结果可能与预先的设想有一定的区别。性能测试的目的:为了验证系统是否达到用户提出的性能指标,同时发现系统中存在的性能瓶颈,起到优化系统的目的。性能测试指标的来源:用户对各项指标提出的明确需求;如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。(需求+经验)主要的性能指标:服务器的各项指标(CPU、内存占用率、平均负载等等)、后台数据库的各项指标、网络流量、响应时间。BUG观点:1、性能测试就象人在无风情况下跑步(正常情况下的性能指标);2、压力测试就象人在微风中跑步(在正常的基础上加大多少百分比压力的性能指标);3、负载测试就象人在强风中跑步(不断加压,直到系统崩溃)。HTTP观点:1、 负载测试是正常情况下持续的加压;2、 压力测试是直接加压达到一个极限值。大家统一的观点:性能测试、压力测试、负载测试密不可分,可统称为性能测试。性能测试要点:1、 性能测试是在功能测试完成之后进行。2、 性能测试计划、方案一般与测试用例统一在一个文档里。3、 测试环境应尽量与用户环境保持一致。4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成,性能测试的环境应单独运行尽量避免与其他软件同时使用。5、 性能测试的重点在于前期数据的设计与后期数据的分析。6、 性能测试的用例主要涉及到整个系统架构的问题,所以测试用例一旦生成,改动一般不大,所以做性能测试的重复使用率一般比较高。(说明:当系统中出现的某个功能点需要修改,它一般只会影响到功能测试的设计用例,而对于性能测试,很少影响到性能测试的设计用例。但是如果某个功能有较大的修改,性能测试也应该进行重新测试。) -
解决LoadRunner监控Linux中遇到的问题
2008-07-29 16:12:37
LoadRunner监控Linux安装成功,所以共享出来,备忘. 需要下载3个包,到网上google一个吧:
(1)rsh-0.17-14.i386.rpm
(2)rsh-server-0.17-14.i386.rpm
(3)rpc.rstatd-4.0.1.tar.gz
1.安装rsh,和rsh-server两个服务包。
a. 卸载rsh
rpm –q rsh----------查看版本号
rpm -e 版本号---------卸载该版本。
b.安装
rpm –ivh rsh-0.17-14.i386.rpm rsh-server-0.17-14.i386.rpm
这两个包在我的目录下有共享。
2.下载并安装rstatd
gunzip rpc.rstatd-4.0.1.tar.gz
Tar –cvf rpc.rstatd-4.0.1.tar.
./configure ---配置
make ---编译
make install ---安装
rpc.rstatd ---启动rstatd进程
3. 打开/etc/xinetd.conf
里面内容是:
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
4.重启xinetd:
A: service xinetd reload
B: /sbin/service xinetd rstart
5.修改/etc/xinetd.d/下的三个conf文件 rlogin ,rsh,rexec 这三个配置文件
打这三个文件,将里面的disable = yes都改成 disable = no (disabled用在默认的{}中禁止服务)
或是把# default: off都设置成 on ,并把“#”去掉,这个的意思就是在xinetd启动的时候默认都启动上面的三个服务!
6.启动rstatd: rpc.rstatd
7.查看rstatd是否启动:
rpcinfo –p
如果能看到:
100001 5 udp 618 rstatd
100001 3 udp 618 rstatd
100001 2 udp 618 rstatd
100001 1 udp 618 rstatd
就说明rstatd服务已经启动。可以用LR去监视了。 -
个人对性能测试的理解
2008-07-20 08:42:58
测试系统在指定的环境或某一场景中的性能表现是否与预期目标达成一致,根据测试结果识别系统瓶颈,判断系统存在的性能缺陷,并改善、优化系统性能的整个过程; -
http错误代码含义
2008-07-20 08:16:04
HTTP
1xx - 信息提示
这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收一个或多个 1xx 响应。• 100 - 继续。 • 101 - 切换协议。
这类状态代码表明服务器成功地接受了客户端请求。• 200 - 确定。客户端请求已成功。 • 201 - 已创建。 • 202 - 已接受。 • 203 - 非权威性信息。 • 204 - 无内容。 • 205 - 重置内容。 • 206 - 部分内容。
客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请求服务器上的不同的页面,或通过代理服务器重复该请求。• 302 - 对象已移动。 • 304 - 未修改。 • 307 - 临时重定向。
发生错误,客户端似乎有问题。例如,客户端请求不存在的页面,客户端未提供有效的身份验证信息。• 400 - 错误的请求。 • 401 - 访问被拒绝。IIS 定义了许多不同的 401 错误,它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示,但不在 IIS 日志中显示: • 401.1 - 登录失败。 • 401.2 - 服务器配置导致登录失败。 • 401.3 - 由于 ACL 对资源的限制而未获得授权。 • 401.4 - 筛选器授权失败。 • 401.5 - ISAPI/CGI 应用程序授权失败。 • 401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。 • 403 - 禁止访问:IIS 定义了许多不同的 403 错误,它们指明更为具体的错误原因: • 403.1 - 执行访问被禁止。 • 403.2 - 读访问被禁止。 • 403.3 - 写访问被禁止。 • 403.4 - 要求 SSL。 • 403.5 - 要求 SSL 128。 • 403.6 - IP 地址被拒绝。 • 403.7 - 要求客户端证书。 • 403.8 - 站点访问被拒绝。 • 403.9 - 用户数过多。 • 403.10 - 配置无效。 • 403.11 - 密码更改。 • 403.12 - 拒绝访问映射表。 • 403.13 - 客户端证书被吊销。 • 403.14 - 拒绝目录列表。 • 403.15 - 超出客户端访问许可。 • 403.16 - 客户端证书不受信任或无效。 • 403.17 - 客户端证书已过期或尚未生效。 • 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。 • 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。 • 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。 • 404 - 未找到。 • 404.0 -(无) – 没有找到文件或目录。 • 404.1 - 无法在所请求的端口上访问 Web 站点。 • 404.2 - Web 服务扩展锁定策略阻止本请求。 • 404.3 - MIME 映射策略阻止本请求。 • 405 - 用来访问本页面的 HTTP 谓词不被允许(方法不被允许) • 406 - 客户端浏览器不接受所请求页面的 MIME 类型。 • 407 - 要求进行代理身份验证。 • 412 - 前提条件失败。 • 413 – 请求实体太大。 • 414 - 请求 URI 太长。 • 415 – 不支持的媒体类型。 • 416 – 所请求的范围无法满足。 • 417 – 执行失败。 • 423 – 锁定的错误。
服务器由于遇到错误而不能完成该请求。• 500 - 内部服务器错误。 • 500.12 - 应用程序正忙于在 Web 服务器上重新启动。 • 500.13 - Web 服务器太忙。 • 500.15 - 不允许直接请求 Global.asa。 • 500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。 • 500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。 • 500.100 - 内部 ASP 错误。 • 501 - 页眉值指定了未实现的配置。 • 502 - Web 服务器用作网关或代理服务器时收到了无效响应。 • 502.1 - CGI 应用程序超时。 • 502.2 - CGI 应用程序出错。application. • 503 - 服务不可用。这个错误代码为 IIS 6.0 所专用。 • 504 - 网关超时。 • 505 - HTTP 版本不受支持。 常见的 HTTP 状态代码及其原因
• 200 - 成功。 此状态代码表示 IIS 已成功处理请求。 • 304 - 未修改。 客户端请求的文档已在其缓存中,文档自缓存以来尚未被修改过。客户端使用文档的缓存副本,而不从服务器下载文档。 • 401.1 - 登录失败。 登录尝试不成功,可能因为用户名或密码无效。 • 401.3 - 由于 ACL 对资源的限制而未获得授权。 这表示存在 NTFS 权限问题。即使您对试图访问的文件具备相应的权限,也可能发生此错误。例如,如果 IUSR 帐户无权访问 C:\Winnt\System32\Inetsrv 目录,您会看到这个错误。 有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 187506 (http://support.microsoft.com/kb/187506/) INFO: IIS 4.0 的基础 NTFS 权限• 403.1 - 执行访问被禁止。 下面是导致此错误信息的两个常见原因: • 您没有足够的执行许可。例如,如果试图访问的 ASP 页所在的目录权限设为“无”,或者,试图执行的 CGI 脚本所在的目录权限为“只允许脚本”,将出现此错误信息。若要修改执行权限,请在 Microsoft 管理控制台 (MMC) 中右击目录,然后依次单击属性和目录选项卡,确保为试图访问的内容设置适当的执行权限。 • 您没有将试图执行的文件类型的脚本映射设置为识别所使用的谓词(例如,GET 或 POST)。若要验证这一点,请在 MMC 中右击目录,依次单击属性、目录选项卡和配置,然后验证相应文件类型的脚本映射是否设置为允许所使用的谓词。 • 403.2 - 读访问被禁止。验证是否已将 IIS 设置为允许对目录进行读访问。另外,如果您正在使用默认文件,请验证该文件是否存在。 有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 247677 (http://support.microsoft.com/kb/247677/) 错误信息:403.2 Forbidden:Read Access Forbidden(403.2 禁止访问:读访问被禁止)• 403.3 - 写访问被禁止。 验证 IIS 权限和 NTFS 权限是否已设置以便向该目录授予写访问权。有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 248072 (http://support.microsoft.com/kb/248072/) 错误信息:403.3 Forbidden:Write Access Forbidden(403.3 禁止访问:写访问被禁止)• 403.4 - 要求 SSL。禁用要求安全通道选项,或使用 HTTPS 代替 HTTP 来访问该页面。如果没有安装证书的 Web 站点出现此错误,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 224389 (http://support.microsoft.com/kb/224389/) 错误信息:HTTP 错误 403、403.4、403.5 禁止访问:要求 SSL• 403.5 - 要求 SSL 128。禁用要求 128 位加密选项,或使用支持 128 位加密的浏览器以查看该页面。如果没有安装证书的 Web 站点出现此错误,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 224389 (http://support.microsoft.com/kb/224389/) 错误信息:HTTP 错误 403、403.4、403.5 禁止访问:要求 SSL• 403.6 - IP 地址被拒绝。您已把您的服务器配置为拒绝访问您目前的 IP 地址。 有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 248043 (http://support.microsoft.com/kb/248043/) 错误信息:403.6 - Forbidden:IP Address Rejected(403.6 - 不可用:IP 地址被拒绝)• 403.7 - 要求客户端证书。您已把您的服务器配置为要求客户端身份验证证书,但您未安装有效的客户端证书。 有关其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 190004 (http://support.microsoft.com/kb/190004/) 错误 403.7 或“Connection to Server Could Not Be Established”(无法建立与服务器的连接)186812 (http://support.microsoft.com/kb/186812/) PRB:错误信息:403.7 Forbidden:Client Certificate Required(403.7 禁止访问:要求客户端证书)• 403.8 - 站点访问被拒绝。您已为您用来访问服务器的域设置了域名限制。有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章: 248032 (http://support.microsoft.com/kb/248032/) 错误信息:Forbidden:Site Access Denied 403.8(禁止访问:站点访问被拒绝 403.8)• 403.9 - 用户数过多。与该服务器连接的用户数量超过了您设置的连接限制。 有关如何更改此限制的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章: 248074 (http://support.microsoft.com/kb/248074/) 错误信息:Access Forbidden:Too Many Users Are Connected 403.9(禁止访问:连接的用户太多 403.9)注意:Microsoft Windows 2000 Professional 和 Microsoft Windows XP Professional 自动设置了在 IIS 上最多 10 个连接的限制。您无法更改此限制。• 403.12 - 拒绝访问映射表。 您要访问的页面要求提供客户端证书,但映射到您的客户端证书的用户 ID 已被拒绝访问该文件。 有关其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章: 248075 (http://support.microsoft.com/kb/248075/) 错误信息:HTTP 403.12 - Access Forbidden:Mapper Denied Access(HTTP 403.12 - 禁止访问:映射表拒绝访问)• 404 - 未找到。 发生此错误的原因是您试图访问的文件已被移走或删除。如果在安装 URLScan 工具之后,试图访问带有有限扩展名的文件,也会发生此错误。这种情况下,该请求的日志文件项中将出现“Rejected by URLScan”的字样。 • 500 - 内部服务器错误。 很多服务器端的错误都可能导致该错误信息。事件查看器日志包含更详细的错误原因。此外,您可以禁用友好 HTTP 错误信息以便收到详细的错误说明。 有关如何禁用友好 HTTP 错误信息的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章: 294807 (http://support.microsoft.com/kb/294807/) 如何在服务器端禁用 Internet Explorer 5 的“显示友好 HTTP 错误信息”功能• 500.12 - 应用程序正在重新启动。 这表示您在 IIS 重新启动应用程序的过程中试图加载 ASP 页。刷新页面后,此信息即会消失。如果刷新页面后,此信息再次出现,可能是防病毒软件正在扫描 Global.asa 文件。 有关其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章: 248013 (http://support.microsoft.com/kb/248013/) 错误信息:HTTP Error 500-12 Application Restarting(HTTP 错误 500-12 应用程序正在重新启动)• 500-100.ASP - ASP 错误。 如果试图加载的 ASP 页中含有错误代码,将出现此错误信息。若要获得更确切的错误信息,请禁用友好 HTTP 错误信息。默认情况下,只会在默认 Web 站点上启用此错误信息。有关如何在非默认的 Web 站点上看到此错误信息的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章: 261200 (http://support.microsoft.com/kb/261200/) 显示 HTTP 500 错误信息,而不显示 500-100.asp 的 ASP 错误信息• 502 - 网关错误。 如果试图运行的 CGI 脚本不返回有效的 HTTP 标头集,将出现此错误信息。 -
LoadRunner资料整理(性能测试)
2008-07-20 07:31:00
环境搭建
1.安装LR8.0版本
a.到\doc复制安装包到本地,解压后,里面有2个文件:Loadrunner 8.0 (Web Site Load Test Tool - Good).iso和说明.txt(10000并发用户注册码)
b.用光驱工具(DAEMON Tools)打开iso镜像文件,安装LR
c.安装过程注意:光驱工具在/doc中的daemon347.exe
按默认步骤一步步安装下来
二.web性能测试计划
1.性能测试基本概念
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试,两者可以结合进行。
通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
2.什么时候需要做web性能测试
一般来说,开发人员或项目经理会提出需求,帮忙测下某个网站或某个功能点的性能如何?所以基本的测试需求和性能标准需要自己来设定。
首先先了解到测试的范围,如果是整个网站的性能水平,则选择网页流量最多的几个页面,进行页面概率测试,首先判断出该网站流量最大的页面有:首页,下载页,个人管理页,广告页,等等其他页面。页面和页面之间的流量也存在着某种关系。假使用户群的20%会浏览首页,其中20%中的80%会到下载页面,20%会进入个人管理页面,20%会进入广告页面。
如果是某个功能的测试,可以先进行试探性的测试,可以开始录制基本的脚本。例如测试网站注册功能的性能如何?先得出基本的性能标准。
这次我要测的是网站的注册性能。首先注册功能的功能测试要全部通过,保证功能上没有问题。然后分析所测对象的模块结构是如何的?注册方式有3种:直接注册,第三方帐号注册,手机注册。其中预期到直接注册和第三帐号的注册量最大,所以测试2种方式下的注册性能如何。那么这次的性能测试范围就是直接注册了。然后在考虑测试环境
测试工具:LoadRunner工具模拟多用户并发请求注册的客户端请求。那么如何模拟这个压力,如何得出压力过程中网站的是否稳定,事务的失败率是否太大?这些都要在开始压力之前想好。
3.Web性能测试计划
5W:“5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”
做什么:也就是测试范围,测试web注册系统性能是否满足用户需求?
为什么做:在上线之前,或用户快速增长之后,及早的验证系统是否能支持多用户同时注册,以免在线时才发现系统承载不了。
何时做:也就是测试任务的时间,基本上要1个星期的时间。
在哪里:需要2台测试机,一台是web服务(注册系统,linux系统),一台是压力测试专用机(安装LR,windows系统)。另外需要准备一个自己的观察机(远程桌面操作并观察压力2台系统的结果)。
如何做:也就是测试脚本的录制和测试场景的设置了。有几个问题必须先考虑清楚才开始做,LoadRunner能做些什么?
a.功能是一个什么流程?用户点击页面->下一步到号码页面->用户输入验证码->设置用户密码->后台注册成功(数据库及日志)->用户注册成功
b. LoadRunner 通过使用虚拟用户来代替实际用户来减少人员要求。这些Vuser 模拟实际用户的行为(也就是注册)
c. LoadRunner 联机监视应用程序的性能,使您可以在测试执行期间对您的系统进行微调。从服务器的性能调试还是代码的性能调试。
d. LoadRunner 在测试过程中会自动记录应用程序的性能。您可以从众多的图和报告中进行选择以查看性能数据。
e. LoadRunner 可检查出现性能延迟的地方:网络或客户端延迟、CPU 性能、I/O延迟、数据库锁定和数据库服务器上的其他问题。LoadRunner 将监视网络和服务器资源以帮助改进性能。
f.性能测试并不是1次2次就能完成的工作,可能需要多轮的场景设置然后观察。
三.一轮测试的整个过程
1.规划测试
也就是刚才所说的性能测试计划,想好第一探测要怎么做,从最表面的性能指标观察(响应时间,定义明确的测试计划确保方案能完成本次测试的目标
2.创建user脚本
录制单个用户完成整个功能时所做的动作(用户点击页面->下一步到号码页面->用户输入验证码->设置用户密码->后台注册成功(数据库及日志)->用户注册成功),而且后面的方案需要,可以设置单个用户反复录制该脚本的次数
3.创建方案(测试场景)
设置整个压力过程中,客户端请求动作的所有情况,你可以设置用户数量,多个脚本的百分比,而且还可以创建面向目标的方案,在其中定义你希望达到的测试目标,LR将根据你所设置的目标自动为你创建方案。
4.运行方案(在运行前,先想好需要监视那些数据)
第一次运行方案时,你可以观察下监视的性能指标图表变化,看是否有太大的异常,因为初次用工具肯定会有些问题,这时候可以查找答案排除问题。
5.监视方案(LR能满足大部分的性能指标观察,但有些性能指标需要自己写些sh脚本录制)
你可以观察用户加载数量,事务成功数,系统资源,web资源,WEB服务器资源,web应用程序服务器资源,数据库服务资源,网络吞吐量等。
6.分析测试结果,得出更有效的下一步测试用例设计
LR可以记录下不同负载下的性能数据,可以使用图表和报告来分析应用程序的性能,而这一环节也是最难的一步
四.测试计划
1.分析应用程序
分析单用户完成整个功能的过程:用户从客户端机发出请求,网络环境,web服务器响应请求,数据库服务器保存结果
先不考虑网络环境的瓶颈,在内网中进行性能测试
2.定义测试目标
度量最终用户的响应时间:完成一个注册需要多长时间
定义最优的硬件配置:哪一种硬件配置可以提供最佳性能
检查可靠性系统:无错误或无故障运行的时间长度或难度
度量系统容量在没有显著性能下降的前提下,系统能够处理多大的负载:确定瓶颈哪些因素会延长响应时间
3.计划测试实施方案
定义用户的活动,一个用户的请求可以定义为一个事务,而且可以在脚本中设置集合点:指示多个用户同一时刻执行。
4.检测测试目标
度量最终用户响应时间:从客户端请求到服务器响应完毕所花费的时间
定义最优的硬件配置(服务器的):检查各项系统配置对性能测试的影响
检查可靠性:确定系统在高工作长期负载下的稳定性级别
确定瓶颈(客户端,网络,服务器,数据库服务器,程序)
五.录制脚本
虚拟用户模拟实际用户的操作,开始录制(url,action),在页面上操作,完成注册后,停止脚本录制。就可以得出整个虚拟用户注册过程客户端部分的行为录制了。
录制基本的vuser脚本
VuGen 通过录制浏览器和 Web 服务器之间的活动来创建 Web Vuser 脚本。VuGen 监控系统的客户端(浏览器),并跟踪所有发送到服务器以及从服务器接收的请求。
在 VuGen 中或从 LoadRunner Controller 运行录制的 Vuser 脚本时, Vuser 将与服务器直接通信,无需依赖客户端软件。而 Vuser 脚本则通过 API 函数直接执行对 Web 服务器的调用。
过程:新建脚本->设置录制选项为action->录制浏览网站时执行的操作->终止操作
增强并编辑脚本
通过插入事务、集合点、检查和服务步骤来增强 Vuser 脚本。需要的话还可以定义参数(有变量时),vuser_init 和 vuser_end 部分通常用于录制服务器登录和注销过程。
配置运行时设置
以独立模式运行vuser脚本
调试脚本,查看脚本是否有错。
脚本保存,以便集成到LR方案中
保存脚本。
六.设置方案
1.选择方案类型
选择下列两个选项之一:
a.手动方案:如果要生成手动方案,请选择此方法。通过创建组并指定脚本、负载
生成器和每组中包括的 Vuser 数,可以生成手动方案。
使用百分比模式在脚本间分配Vuser,如果要通过指定许多要在选定 Vuser 脚
本间分配的 Vuser 来生成手动方案,请选择此选项。
b.面向目标的方案:选择此方法可让 LoadRunner 为您生成方案。在面向目标的方
案中,可以定义通过测试要实现的目标, LoadRunner 将根据这些目标自动生成
方案。
2.选择脚本
选择刚刚保存录制的脚本
3.设计方案
a.“方案计划”窗格显示了与计划配置文件有关的信息:名称、计划模式、方案持
续时间、负载行为和方案中要使用的 Vuser 总数。“负载预览”显示已定义方案
计划的预览图。
主要用途是设置虚拟用户的加载数,以及用户随着时间的增长如何加载用户数量(上升虚拟用户数,保持最高用户数,下降讯用户数),而且可以指示 LoadRunner 在一段延迟之后开始执行方
案。您可以指定让 LoadRunner 自发出Run命令以来等待的分钟数,也可以指定让方案开始的特定时间。
设置相同的时间加载一定的用户数量,直到全部加载完毕为止,这样设置的目的是为了方便记录用户数量明显增大时,性能指标的变化情况。
b.“方案脚本”窗格列出了所有启用和禁用的 Vuser 脚本、脚本路径、负载生成器
计算机以及分配给每个脚本的 Vuser 在总数中所占的百分比。
4.预设计方案输出窗口,监视vuser状态。需要加进你想要的性能指标图表
七.执行方案
开始执行方案,保存执行方案的结果。方案将会持续你所设计的时间限制,也可以在中途手工停止或某些条件下停止。
八.监视方案
1.运行时和事务监视
a.正在运行的用户数,已加载时间,每秒点击次数(表明每个 Vuser 所运行的每一秒钟内对测试的网站有多少次点击(HTTP 请求)),通过的事务数,失败的事务数,错误数(点击后可看到具体的错误日志)。
b.事务监视图
事务响应时间
每秒事务数(通过)
每秒事务数(失败、停止)
每秒事务总数(通过)
2.Web 资源
每秒点击次数图:每秒点击次数图将点击(HTTP 请求) Web 服务器的次数显示为方案已用时间的函数。可将此图与事务响应时间图进行比较,以查看点击次数对事务性能产生的影响。
吞吐量图:吞吐量图显示 Web 服务器在 方案运行的每一秒中的吞吐量。吞吐量的度量单位是字节,表示
性能测试的一些思路
2007-10-23 12:40:12
测试目标:
测试过程是否满足以上过程指标及最终的需求指标;
及如何通过结合2者指标评估出被测系统及上线环境的线性对比指标;
最后得到系统的性能、可扩展性、可用性等测试结论。测试步骤:
1) 基准测试:分步测试。测试结果是一致的且可重现。测试环境一直处在相同的高负载下进行。
2) 容量规划测试:系统测试。容量规划在测试需求阶段就需要从设计获取了,详见附件《性能指标容量规划.DOC》。如果要确定系统的容量,需要考虑几个因素。这些用户中有多少是并发与服务器通信的,其次是,每个用户的"考虑时间"即请求时间是多少,以及本次请求服务通信总响应的时间是多少,等等。通过用户考虑时间+服务器响应时间=场景总运行时间,且通过调整各参数及随机因子(利用"调步"的理念向负载场景中引入更多的随机性),换算出最大及最优同时并发用户数。接着引入ramp-up测试及flat测试不断微调。
3) 峰谷测试:系统测试。峰谷测试通过一系列的快速ramp-up测试,继之以一段时间的平稳状态(取决于业务需求),然后急剧降低负载,然后再进行快速的ramp-up;反复重复这个过程。这样可以确定以下事项:
第二次高峰是否重现第一次的峰值?
其后的每次高峰是等于还是大于第一次的峰值?
在测试过程中,系统是否显示了内存或GC(内存释放)性能降低的有关迹象?
测试运行(不停地重复"峰值/空闲"周期)的时间越长,系统的性能越被了解。
4) 渗入测试:系统测试。渗入测试所需时间较长,也叫疲劳测试。渗入测试以2端负载通过低负载/高负载运行较长时间,即运行两次测试,一次使用较低的用户负载(要在系统容量之下,以便不会出现执行队列),一次使用较高的负载(以便出现积极的执行队列)。
测试所需指标:
1、 获取各WEB服务的性能指标,包括 WEB SERVER的性能(包括线程数(为了给执行队列决定一个理想的线程数,当队列中所有应用程序都运行在最大负荷的情况下,监视队列的吞吐量。增加线程数,重复负载测试,直到达到最佳的吞吐量。(在某些情况下,增加线程数将产生足够多的上下文转换程序,使得队列中的吞吐量开始减少。))、最大并发数、最优并发数、TPS);
--最佳线程数(调整并满足既定的配置数,详见2.2硬件环境描述)
--最佳吞吐量 for server (tomcat/sip/oracle)
--响应时间 for case(OSAP/PXYWEB/xxxCOMP/WEB SERVICES)
--最大同时并发用户数 for osap
--最佳同时并发用户数 for osap
--最佳用户数下的TPS for case(OSAP/PXYWEB/xxxCOMP/WEB SERVICES)
2、 能力组件性能
--最大并发用户数下的CPS for case(xxxCOMP)
--最佳线程数(调整并满足既定的配置数,详见2.2硬件环境描述)
--最佳吞吐量 for server (tomcat)
--响应时间 for case(xxxCOMP)
--最大同时并发用户数 for case(xxxCOMP)
--最佳同时并发用户数 for case(xxxCOMP)
3、 应用服务(SIPSVR)的性能指标:
---最佳线程数
---最佳吞吐量 for case5
---CPS for case2/case5
4、 后置指标:
---各服务器的CPU占用百分比(基准测试/容量规划测试/渗入测试)
---各服务器的Memory平均占用比例 (基准测试/容量规划测试/渗入测试)
(例如,如果想知道增加JVM内存是否会影响应用程序的性能,就逐次递增JVM内存(例如,从1024 MB增至1224 MB,然后是1524 MB,最后是2024 MB),在每个阶段收集结果和环境数据,记录信息,然后到下一阶段。)容量规划
前提(测试结果有效的先决条件):
1、 web/sip/oracle/第三方后台服务器配置满足建设方案标准配置或以上;2、 系统正常工作时,用户访问系统的基本性能需求如下:
1) 软终端用户登录时间<= 3秒
2) WEB终端用户页面初始化操作<= 3秒
3) WEB接入的系统响应时间:在带宽足够的情况下,用户点击访问页面时间不超过3秒,请求提交响应时间最大不超过5秒;
4) 系统一般性操作最长时间<= 2秒
5) 用户操作界面友好,交互性强,在出现错误时,应能显示错误提示信息,并且错误信息能够被用户取消,并恢复界面正常显示。3、 根据项目一期设计,系统建设要求满足3万用户需求,业务话务模型如下:
1) 点击拨号
按最大CAPS为60计算,普通用户的通话时长为60秒,媒体服务器为主叫放音时长为30秒。
2) 网络传真
按最大CAPS为3计算,每个呼叫时长为120秒,媒体服务器话音提示时长为15秒。
3) Web会议
按最大CAPS为0.2计算,每次会议保持时长为120秒,会议方数为5方,40%用户存在数据协同会议需求。
4) 短信
短信按每秒100条计算。
5) 电话总机
按最大CAPS为0.5计算,每个呼叫时长为90秒。4、 九的个数和时间之间的对应关系。
可接受的运行时间百分比 每天的停机时间 每月的停机时间 每年的停机时间
95 72.00 分钟 36 小时 18.26 天
99 14.40 分钟 7 小时 3.65 天
99.9 86.40 秒钟 43 分钟 8.77 小时
99.99 8.64 秒钟 4 分钟 52.60 分钟
99.999 0.86 秒钟 26 秒钟 5.26 分钟
5、业务比例选取:
“xx”平台用户主要针对中小企业用户,按照约有3万企业用户,xx商业客户分类如下:
客户类型 客户员工规模 客户数量 比率
1-2线客户 约3-10人 135万 86%
3-10线客户 约10-100人 19.5万 12%
10线以上客户 约20-500人 2.2万 2%
按以上比例,3万用户中,2.58万为1-2线用户,3600为3-10线用户,600为10线以上用户。6、在线使用概况
峰值乘数用于计算与平均负载有关的系统的最大容量。 如果每秒钟的平均请求数量是 50 ,如果您的峰值乘数是 3 的话那么预期峰值将会是每秒钟 150 次请求。 为了对实施进行容量规划,您应当为系统的峰值容量做规划。
描述 值
会话的平均时间 7 分钟(420 秒)
峰值乘数 3x 平均值
每个用户每次访问的请求数 107、事务比例选取
对于行业应用,测试数据的准备中最重要的就是事务的选取,以上从业务比例中抽取每个客户类型的事务比例:
比例的分布:
操作 分布权重 发送比例 标准化 每个操作的请求数 每个会话的请求数
定购(ws)/请求使用 0.10 10*0.1=1 2 1 Ws:canuse
登录 0.10 10*0.1=1 1 2 Login->logout
发送传真 0.20 10*0.2=2 1 3 Osap->pxy->comp->sip
已发/接收传真 0.03 10*0.03=0.3 2 2 Osap->pxy->comp->
发送短信 0.20 10*0.2=2 1 3 Osap->pxy->comp->
已发/接收短信 0.05 10*0.05=0.5 2 2 Osap->pxy->comp->
点击拨号 0.20 10*0.2=2 1 3 Osap->pxy->comp->ctd
发起会议 0.09 10*0.09=0.9 1 3 Osap->pxy->comp->ipunity
定制语音流程 0.03 10*0.03=0.3 1 3 Osap->pxy->comp->->sip
总计 1 10其中 分布权重 一栏给出某类操作占总请求数的百分比。
其中 标准化 一栏表示分布权重乘以前表给出的每用户每次访问请求数得到的结果。 注意这一栏合计达10。
其中 每个操作的请求数 一栏给出了执行某一操作所用的用户请求数量。 由于回帖或服务器重定向等原因,有些操作会产生多个请求。
其中 每个会话的请求数 一栏给出了用户在每次会话中发起的对某一操作的请求数量。8、测试强度估算:
测试强度估算时采用如下假设前提:
*全年的业务量集中在10个月完成,每个月20个工作日,每个工作日8个小时;
*采用80—20原理,每个工作日中80%的业务在20%的时间内完成,即每天80%的业务在1.6小时内完成;
测试压力的估算结果:
按照3万用户每用户每次访问的10请求数,每7分钟一次会话计算,可处理业务约30万笔,每小时处理超过100次请求。其中,假设早上9点及下午15点为高峰期,按照2个小时段的业务处理量估计如下:
10%的业务处理每笔订购业务需对应用服务器提交1(标准化)*10=10次请求;
10%的业务处理每笔登录业务需对应用服务器提交1(标准化)*10=10次请求;
20%的业务处理每笔传真业务需对应用服务器提交2(标准化)*10=20次请求;
20%的业务处理每笔短信业务需对应用服务器提交2(标准化)*10=20次请求;
20%的业务处理每笔呼叫业务需对应用服务器提交2(标准化)*10=20次请求;
9%的业务处理每笔呼叫业务需对应用服务器提交9(标准化)*10=9次请求;
其余11%的业务每笔业务向应用服务器提交1.1(标准化)*10=11次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后三年业务发展的需要,测试需按现有业务量的2倍进行。
每年总的请求数量为:(30*10%*10*2+30*10%*10*2+30*20%*20*2+30*20%*20*2+30*20%*20*2+30*9%*9*2+30*11%*11*2)*2=60+60+240+240+240+48.6+72.6=961.2万次/年。
每天的请求数量为:961.2/200=4.806万次/天。
每秒的请求数量为:(48060*80%)/(8*20%*3600)=38448/5760=6.675次/秒。
正常情况下,应用服务器处理请求的能力至少应达到:6.675次/秒。
某种程度上,可认为请求数量约等于交易数量:
如果再考虑未来几年的交易量的增加(每年增长15%),则可以归纳为:
第一年(万) 第二年(万) 第三年(万) 第四年(万) 合计(万)
30 34.5 39.675 45.627 149.802性能瓶颈分析方法
2007-09-30 09:43:03
同一场景
1.小用户量的情况下测试
2.大用户量情况下的测试
分析的方法:
整个系统架构分析,系统响应时间消耗,利用图表分析
查看事务响应时间,通过事务摘要图分析事务响应时间,那个消耗最大(通过小用户量和大用户量的响应时间分析,查看那个事务响应时间最高),确定哪部分功能是性能的瓶颈,分析window resource图表,查看cpu
使用下列计数器标识cpu瓶颈
Processor\ Interrupts/sec
Processor\ % Processor Time
Process(process)\ % Processor Time
System\ Processor Queue Length
通过它来确定是否硬件本身出现瓶颈,或者进一步确定应该怎么去判断性能产生瓶颈的地方!
下一步去判断进程,那个进程消耗cpu最高
下边就有很多种情况需要你自己去判断,有可能是进程调用了的函数消耗了系统资源形成上边的问题,也有可能是后台数据库出现的问题(这个就要看你的系统配置是什么样的,比如你的db服务器和应用服务器都配置在一台机器上)
性能产生瓶颈有很多地方,所以需要进一判断,是否是后台数据库的问题还有待分析,是那条语句导致的问题需要进一步分析判断。
分析原则:
• 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
• 查找瓶颈时按以下顺序,由易到难。
服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
• 分段排除法 很有效
分析的信息来源:
•1 根据场景运行过程中的错误提示信息
•2 根据测试结果收集到的监控指标数据
一.错误提示分析
分析实例:
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
•Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely
分析:
•A、应用服务死掉。
(小用户时:程序上的问题。程序上处理数据库的问题)
•B、应用服务没有死
(应用服务参数设置问题)
例:在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%
•C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数(跟硬件的内存有关))
2 Error: Page download timeout (120 seconds) has expired
分析:可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多
二.监控指标数据分析
1.最大并发用户数:
应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。
在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK。否则,再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2.业务操作响应时间:
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的?问题是否与网络或服务器有关?
• 如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用“网络监视器”图确定导致性能瓶颈的网络问题
3.服务器资源监控指标:
内存:
1 UNIX资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)
处理器:
1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。
2 Windows资源监控中,如果System\Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘I/O:
1 UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)
4.数据库服务器:
SQL Server数据库:
1 SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。
2 如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高,则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
3 Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒),通过优化查询来减少读取次数,可以减少该计数器的值。
Oracle数据库:
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
快存(共享SQL区)和数据字典快存的命中率:
select(sum(pins-reloads))/sum(pins) from v$librarycache;
select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存: select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
缓冲区高速缓存命中率:
select name,value from v$sysstat where name in ('db block gets’,
'consistent gets','physical reads') ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况 :
select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序 。
内存排序命中率 :
select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'在LR中两种截取字符串的方式
2007-08-24 13:43:49
1.截取某个字符中的某几位代码:
下面的列子是:截取字符串"ABCDEFG"中, 从第三位开始连续两位的字符,即:CD.
int k;
char tempstr2[30];
char *strtmp="ABCDEFG";for (k=1;k<3;k++)
{
strtmp++;
}
lr_output_message( "strtmp=%s",strtmp);
strncpy(tempstr2,strtmp,2);
lr_output_message( "tempstr2=%s",tempstr2);
2.将某个变量的值赋值给某个参数下面的列子是:将上段代码中变量tempstr2的值,赋值给参数列表中的参数temp,并且显示出来。
lr_save_string(tempstr2,"temp");
lr_output_message("the velue is:%s",lr_eval_string("{temp}"));最大的并发用户数
2007-08-23 09:35:51
LoadRunner执行的时候随着虚拟用户数的增加,耗用的系统资源也会增加,根据以往的使用经验,在512m的机器上可以模拟500个并发用户,所以请根据运行LoadRunner的机器的性能决定最大的并发用户数,一般来说,只有外网的门户网站才可能达到并发500用户这样的规模,一般的应用系统在100并发用户的情况下就已经是满负载了。对参数表中添加新列的两种方式
2007-08-23 09:33:13
1.在原有参数化文件用记事本打开的时候添加新列(注意在记事本编辑过程中字段内容与内容之间要有间隔符和换行符,间隔符号一般都用逗号,换行符直接回车就行了)。
2.也可以在参数属性中直接添加。软件性能测试框架
2007-08-17 10:03:46
性能测试框架执行步骤:测试启动、测试建模、测试准备、测试执行、测试分析,五个阶段
第一阶段:引入本次性能测试目的,给出测试参考依据,撰写产品测试计划(初稿)
第二阶段:技术调研,比如:产品服务拓扑架构,服务器交互技术,数据存储方式,雏形逻辑调用关系(一般以核心增、删、改、查及异常类)
了解服务器架构(主要用到技术特征)
需要明确:(如
使用LoadRunner作为压力测试工具
使用Web/HTTP WinSock协议开发测试脚本
使用Spotlight 监控数据库
使用Server Monitor监控服务资源
UDI需事先准备全量数据
EAI/ECTIP实时交易需要开发相关挡板程序)
定义测试方案
第三阶段:测试数据建模,如:建立测试数据基础模型,空数据量、1年数据量、3年数据量等
定义基础表单、基础流程(如:控件的数量、控件的大小、流程中节点的个数、条件的复杂程度)
定义基准数据的分布、基准事务的建立、事务的比例关系(百分率、机器人的个数)、场景关系)
第四阶段:测试准备
部署测试环境、明确执行性能测试前各系统参考指标、撰写准备测试报告
第五阶段:测试执行
执行测试、记录测试数据
第六阶段:测试分析性能测试分析-中级测试师用
2007-08-02 08:31:35
性能测试(并发负载压力)测试分析-简要篇
在论坛混了多日,发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试,但多数人对怎样去分析工具收集到的测试结果感到无从下手,下面我就把个人工作中的体会和收集到的有关资料整理出来,希望能对大家分析测试结果有所帮助。
分析原则:
• 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
• 查找瓶颈时按以下顺序,由易到难。
服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
• 分段排除法 很有效
分析的信息来源:
•1 根据场景运行过程中的错误提示信息
•2 根据测试结果收集到的监控指标数据
一.错误提示分析
分析实例:
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
•Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely
分析:
•A、应用服务死掉。
(小用户时:程序上的问题。程序上处理数据库的问题)
•B、应用服务没有死
(应用服务参数设置问题)
例:在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%
•C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数(跟硬件的内存有关))
2 Error: Page download timeout (120 seconds) has expired
分析:可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多
二.监控指标数据分析
1.最大并发用户数:
应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。
在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK。否则,再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2.业务操作响应时间:
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的?问题是否与网络或服务器有关?
• 如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用“网络监视器”图确定导致性能瓶颈的网络问题
3.服务器资源监控指标:
内存:
1 UNIX资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)
处理器:
1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。
2 Windows资源监控中,如果System\Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘I/O:
1 UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)
4.数据库服务器:
SQL Server数据库:
1 SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。
2 如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高,则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
3 Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒),通过优化查询来减少读取次数,可以减少该计数器的值。
Oracle数据库:
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
快存(共享SQL区)和数据字典快存的命中率:
select(sum(pins-reloads))/sum(pins) from v$librarycache;
select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存: select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
缓冲区高速缓存命中率:
select name,value from v$sysstat where name in ('db block gets’,
'consistent gets','physical reads') ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况 :
select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序 。
内存排序命中率 :
select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
注:上述SQL Server和Oracle数据库分析,只是一些简单、基本的分析,特别是Oracle数据库的分析和优化,是一门专门的技术,进一步的分析可查相关资料。【图解】插入检查点的三种方式
2007-08-01 08:18:11
性能测试注意的几点
2007-08-01 08:04:11
性能测试注意事项:
1.服务器端和客户端一定要同一个局域网内,否则网络因素会成为性能测试的瓶颈。
2.在性能测试脚本中要注意检查点的设置,否则都不清楚脚本是否真的成功执行操作。
3.设置参数化和关联是性能测试脚本调通的关键。
4.录制脚本时通常会包括一些think time,因此在回放脚本时,注意在runtime setting中设置忽略think time,否则会影响测试数据的准确性,如:响应时间的准确性。
5.尽量每个页面设置一个transcation,否则不知哪个页面最慢。
6.运行性能测试时在runtime setting中关闭日志功能,调试脚本时可以打开日志功能。
7.性能测试前的数据准备很重要:比如:系统数据库存在60000个用户和系统数据库存在60个用户,分别在两种情况下执行登陆性能测试,性能测试的结果也不会一样的。
8.在性能测试时用户登陆的用户名和密码,每个用户尽可能不要一样!
如何编写性能测试用例
2007-07-30 09:20:01
由于性能测试与功能测试有很大的区别,所以讨论出的结果可能与预先的设想有一定的区别
性能测试的目的:
为了验证系统是否达到用户提出的性能指标,同时发现系统中存在的性能瓶颈,起到优化系统的目的
性能测试指标的来源:
用户对各项指标提出的明确需求;如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。(需求+经验)
主要的性能指标:
服务器的各项指标(CPU、内存占用率等)、后台数据库的各项指标、网络流量、响应时间。
BUG观点:
1、性能测试就象人在无风情况下跑步(正常情况下的性能指标);
2、压力测试就象人在微风中跑步(在正常的基础上加大多少百分比压力的性能指标);
3、负载测试就象人在强风中跑步(不断加压,直到系统崩溃);
HTTP观点:
1、 负载测试是正常情况下持续的加压;
2、 压力测试是直接加压达到一个极限值。
大家统一的观点:
性能测试、压力测试、负载测试密不可分,可统称为性能测试。
性能测试要点:
1、 性能测试是在功能测试完成之后进行。
2、 性能测试计划、方案一般与测试用例统一在一个文档里。
3、 测试环境应尽量与用户环境保持一致。
4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成,性能测试的环境应单独运行尽量避免与其他软件同时使用。
5、 性能测试的重点在于前期数据的设计与后期数据的分析。
6、性能测试的用例主要涉及到整个系统架构的问题,所以测试用例一旦生成,改动一般不大,所以做性能测试的重复使用率一般比较高。(说明:当系统中出现的某个功能点需要修改,它一般只会影响到功能测试的设计用例,而对于性能测试,很少影响到性能测试的设计用例。但是如果某个功能有较大的修改,性能测试也应该进行重新测试。)在Controller中看出进行到第几次迭代了
2007-07-26 11:01:21
Action()
{iter=iter+1;
lr_vuser_status_message("We are on iteration #%d",iter);
lr_think_time(3);
return 0;
}
在init中:int iter=0;
这样在Controller中可以看到点Vuers可以看到:
We are on iteration #5.说明它进行到第5次迭代了。负载生成器如何访问脚本
2007-07-26 10:52:36
运行方案时,默认情况下,脚本会复制到Vuser组计算机的临时目录中。这样,Vuser组负载生成器便可以从本地而不是通过网络访问脚本。
当然你也可指示Controller将脚本存储在共享网络驱动器上,请参见“执行路径转换”。使用LR测试系统性能时用到的五中目标类型
2007-07-20 11:14:23
LR有5种目标类型:并发的用户数,每秒点击数,每秒事务数,每分钟页面数,你想达到的事务响应时间。
1:如果你知道了用户总数,则选》并发的用户数
2:如果你知道了服务器处理能力就选》每秒点击数,每秒事务数,每分钟页面数
3:如果你期望得到完成一个事务所要的响应时间》你想达到的事务响应时间。例如你不想让登录时间超过5秒,则设定最大接受事务响应时间为5秒来看一下有多少用户登录成功。controller中如何设置默认并发用户数
2007-07-20 10:54:52
controller中设置了100个用户并发,可是运行的时候,每次只初始化50个用户。
进入controller后在Tools->options->Run-time setting中可以自己设置每次最多初始化的虚拟用户数。
标题搜索
我的存档
数据统计
- 访问量: 237879
- 日志数: 342
- 文件数: 23
- 书签数: 10
- 建立时间: 2007-06-14
- 更新时间: 2008-12-30