6 分析以及监视场景

6 分析以及监视场景
在运行过程中， 可以监视各个服务器的运行情况（DataBase Server、Web Server 等）。
监视场景通过添加性能计数器来实现。这一章非常的重要，确定系统瓶颈全靠它了。
下面重点讲讲需要添加那些计数器，以及那些计数器代表什么意思。由于Win2000 Professional、Server 以及Advanced Server 提供的计数器不完全相同， 这里我们讨论将以Server 为基准。监视场景需要在Run 视图中设置然后， 出现添加计数器的对话框其他的操作就和控制面板“ 性能”中添加性能计数器的操作一样， 这里不再详细说明。本章主要说明一下各个系统计数器的含义（数据库的计数器不做重点， 只是拿SQL Server2000 作为例子进行说明。因为数据库各个版本之间差异比较大，请参考您使用的数据库系统的帮助）。

6.1Memory相关

内存是第一个监视对象，确定系统瓶颈的第一个步骤就是排除内存问题。内存短缺的问题可能会引起各种各样的问题。
  Object（ 对象）
  		   Counters
  		   Description（ 描述）
  		   参考值
  
  Memory
  		   Available MBytes
  		   物理内存的可用数（  单位 Mbytes）。默认情况下IIS5.0 使用50%的可用物理内存， 作为IIS 的文件缓存（file  cache）。IIS 基本占用 2.5 MB，每个附加连接将在此基础上占用 10 KB 左右
  		   至少要有10% 的物理
  
  Memory
  		   Page/sec 
  Page Faults/sec 
  Pages Input/sec
  Pages Input/sec 
  Page Reads/sec 
  Transition 
  Faults/sec 
   
  		   物理内存的可用数（ 单位 Mbytes）。默认情况下IIS5.0  使用50%的可用物理内存， 作为IIS 的文件缓存（file cache）。IIS 基本占用 2.5 MB，每个附加连接将在此基础上占用 10 KB 左右。至少要有10% 的物理内存值当处理器向内存指定的位置请求一页（  可能是数据或代码）出现错误时， 这就构成一个Page Fault。如果该页在内存的其他位置， 该错误被称为软错误（ 用Transition Fault/sec 数器衡量）； 如果该页必须从硬盘上重新读取时， 被称为硬错误。许多处理器可以在有大软错误的情况下继续操作。但是， 硬错误可以导致明显的拖延。Page Faults/sec是处理器每秒钟处理的错误页（ 包括软错误和硬错误）。Pages Input/sec 是为了解决硬错误页， 从硬盘上读取的页数，而Page Reads/sec 是为了解决硬错误， 从硬盘读取的次数。如果 Page Reads/Sec 比率持续保持为 5， 表示可能内存不足。Pages/sec 是指为解析硬页错误从磁盘
  读取或写入磁盘的页数。
  		   Page/sec 推荐00-20（ 如果服务器没有足够的内存处理其工作负荷，  此数值将一直很高。如果大于80，表示有问题）。这些计数器的值比较低， 说明Web服务器响应请求比较快， 否则可能是服务器系统内存短缺引起（ 也可能是缓存太大， 导致系统内存太少）。Page Input/sec 的值可以衡量出硬错误页发生的速率， 通常它的值会于或者等于Page Reads/sec。Memory Cache Bytes
  
  Memory
  		   Cache Bytes
  		   文件系统缓存（File System Cache）
  		   默默认情况下认情况下为50%的可用物理内存。如为50%的可IIS5.0 运行内存不够时， 它会自动整理用物理内存缓存。需要关注该计数器的趋势变化
  
  Internet File  Cache Hits %
  		    
  		   File Cache Hits %是文件缓存命中全部（ 对于一个Information File Cache 缓存需求的比例，  反映了IIS 的文件缓大部分是静Services Flushes 存设置的工作情况。而File Cache Hits 态网页组成
  Global File  Cache Hits 是文件缓存命中的具体值，File  Cache 的网站）File  Flushes 是自服务器启动之后文件缓存Cache Hits% 刷新次数， 如果刷新太慢， 会浪费内存； 如果刷新太快， 缓存中的对象会太频繁属于非常好！  的丢弃生成， 起不到缓存的作用。通过File Cache Hits 和File Cache Flushes 可以得到一个适当的刷新值（ 参考IIS 的设置ObjectTTL  、MemCacheSize  、MaxCacheFileSize）
  		    
  
   
  		    
  		    
  		    
  
  Memory
  		   PoolPaged  BytesPool Nonpaged Bytes
  		   Pool Paged  Bytes Pool Nonpaged Bytes 这两个计数器监视服务器上各个进程的分页池字节数和非分页池字节数。
  		   在访问数比较固定的情况下， Pool Nonpaged Bytes 是比较定的，  如果访问数逐步增加， 该值会缓慢的增加
  
  Process
  		   Virtual Bytes
  Working Set 计数器
  		   Virtual Bytes(  实Virtual  Bytes 数器监视IIS5.0 保留的例inetinfo 、虚地址空间的数量， 实例化为inetinfo dllhost) Working Set（  实例进程(IIS 运行的核心)和Dllhost 进程（ 隔离/ 连接池的应用程序必需的）。inetinfo 、dllhost） Working Set 计数器反映了每个进程使Dllhost#n 进程都用的内存页的数量。系统的内存页（pool 要添加计数器Page） 只能由操作系统的核心模块直接访问，  用户进程不能访问。运行IIS5.0  的服务器上， 负责web 连接的线程以及它需要的一些对象都保存在未分页的池中（nonpaged  pool）， 比如文件句柄和socket 连接
  		    
  
  Process
  		   Private Bytes
  		   指这个处理不能与其他处理共享的、已分配的当前字节数
  		    
  
  Memory
  		   Committed 
  Bytes
  		   是指以字节表示的确认虚拟内存。(确认内存是指为磁盘分
  页文件在磁盘上保留的空间以便在需推荐不超过物理内存的75% 
  要将其写回磁盘时使用)
  		   推荐部超过物理内存的75％
  
   
  		    
  		    
  		    
  

内存问题主要检查应用程序是否存在内存泄漏。如果发生了内存泄漏，ProcessPrivate Bytes 计数器和ProcessWorking Set 计数器的值往往会升高， 同时Available Bytes 的值会降低。内存泄漏应该通过一个长时间的， 用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。


6.2Processor相关
  Object（ 对象）
  		   Counters
  		   Description（ 描述）
  		   参考值
  
  Sytem
  		   Processor Queue 
  Length 
   
  		   Processor Queue Length  是指处理列队中的线程数。即使在有多个处理器的计算机上处理器时间也会有一个单列队。不象磁盘计数器， 这个计数器仅计数就绪的线程，而不计数运行中的线程。如果处理器列队中总是有两个以上的线程通常表示处理器堵塞
  		   小于2。显示在由 Web服务器所有处理器共享的队列中等待执行的线程数。处理器瓶颈会导致该值持续大于2
  
  Processor
  		   %Processor Time
  		   CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%，则表示此测试的负
  载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 0 到 x 个实例
  		   小于75%。排除内存因素， 如果该计数器的值比较大， 而同时网卡和硬盘的值比较低， 那么可以定CPU 瓶颈
  
  System
  		   Context  Switches/sec
  		   Context  Switches/sec指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。当正在运行的线程自动放弃处理器时出现上下文转换， 由一个有更高优先就绪的线程占先或在用户模式和特权(内核)模式之间转换以使用执行或分系统服务。它是在计算机上的所有处理器上运行的所有线程的Thread: Context Switches/sec 的总数并且用转换数量衡量。在系统和线程对象上有上下文转换计数器
  		   如果切换次数到5000*CPU个数和10000*CPU 个数中， 说明它忙于切换线程而不是
  处理ASP 脚本
  
  Processo
  		   %Privileged Time
  		   % Privileged Time  是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时， 此服务经常在特权模式运行， 以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit)，  例如页面错误或中断。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统保护模式之外，  还使用处理边界作为分系统保护。某些由Windows 为您的应用程序所做的操作除了出现在处理的特权时间内， 还可能在其他子系统处理出现
  		    
  
  Time
  		   Switches/sec （  实例化inetinfo 和dllhost
  		   如果你决定要增加线程字节池的大小，你应该监视这三个计数器（ 包括上面的一个）。增加线数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高， 就应该减小线程字节池的大小
  		    
  
  Processor
  		   Interrupts/sec  %DPC Time
  		   Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10毫秒中断处理器一次， 形成了间15%， 则处理隔活动的后台
  		   如果处理器使用率超过90％，且Interrupts/sec  time大于15％则处理器可能负载过重，并发生中断
  
ProcessorInterrupts/sec %DPC Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断处理器一次， 形成了间15%， 则处理隔活动的后台。器可能负荷过重，并发生中断。判断应用程序是否存在处理器瓶颈的方法： 如果Processor Queue Length 显示的队列长度保持不变（>=2） 个并且处理器的利用率%Processor Time 超过90%， 那么很有可能存在处理器瓶颈。

如果发现ProcessorQueue Length 显示的队列长度超过2， 而处理器的利用率却一直很

低，那么或许更应该去解决处理器阻塞问题， 这里处理器一般不是瓶颈。如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换（Context Switches/sec 显示的上下文切换次数比较大），那么就会占用大量的系统资源。如果系统的吞吐量降低并且CPU 的使用率很高，并且此现象发生时切换水平在15000 以上， 那么意味着上下文切换次数过高同时还可以比较Context Switches/sec 和%Privileged Time 来判断上下文切换是否过量。如果后者的值超过40%， 且上下文切换的速率也很高，那么应该检查为什么会产生这样高的上下文切换。

6.3 网络吞吐量以及带宽
  Object
  		   Counter
  		   Description
  		   参考值
  
  Network Interface
  		   Bytes Total/se
  		   Bytes Total/sec 为发送和接收字节的速率， 包括帧字符在内。判断网络连接速该计数器的值和目前网度是否是瓶颈， 可以用该计数器的值和络的带宽相目前网络的带宽比较
  		   改计数器的值和目前网络带宽相除，结果应该小于50%
  
  Web Servic
  		   Maximum Maximum  Connections
  		   Maximum Maximum  Connections：“ 最大连接数” Attempts Total Connection Attempts ：“ 连接尝试总数” 是从服务启动时利用Web 服务尝试连接的总数。该计数器应用于全部所列的实例。
   
  		    
  

6.4 磁盘相关
Object（ 对象） Counters（ 计数器名称） Description（ 描述） 参考值
  Object
  		   Counters
  		   Description
  		   参考值
  
  Network
  		   Bytes Total/sec
  		   Bytes Total/sec 为发送和接收字节的速Interface率， 包括帧字符在内。判断网络连接速度是否是瓶颈， 可以用该计数器的值和目前网络的带宽比较
   
  		    
  
  Processo
  		   %Processor Time
  % Privileged Time
  		   CPU 使用率该计数器对应于处理器执行Windows. 2000 内核命令（ 如处理SQL Server I/O 请求）所用时间的百分比。如果Physical Disk 计数器的值很高时该计数器的值也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。
   
  		    
  
  PhysicalDisk
  		   %Disk Time
  		   % Disk Time 指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大， 那
  么硬盘不是瓶颈。如果只有%Disk Time 比较大，另外两个都比较适中， 硬盘可能会是瓶颈。在记录该计数器之前， 请
  在 Windows 2000 的命令行窗口中运行 diskperf -yD 。若数值持续超过  80%， 则可能内存泄漏。
  		    
  
  PhysicalDisk
  		   AverageDisk 
  Queue Length
  		   指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
   
  		    
  
  PhysicalDisk
  		   PhysicalDisk
  		   指在此盘上读取操作的速率
  		    
  
  PhysicalDisk
  		   Disk Writes/sec
  		   指在此盘上写入操作的速率
  		    
  
判断磁盘瓶颈的方法是通过以下公式来计算： 
每磁盘的I/O 数 = [读次数 + （4 * 写次数）] / 磁盘个数
如果计算出的每磁盘的I/O 数大于磁盘的处理能力， 那么磁盘存在瓶颈。

6.5 Web应用程序
这里以ASP.NET 开发的Web 应用程序为例进行说明。
  Object
  		   Counters
  		   Description
  		   参考值
  
  ASP.NET  Applications
  		   Request/Sec  Request Executing
  		   每秒执行的请求数。
  		   如果Request/Sec ApplicationsRequest Executing 当前执行的请求数。的值比较小， 你
  的Web 程序可能
  是瓶颈
   
  
  ASP.NET
  		   ASP.NETRequestWait  
  Time 
  Request Executing  Time 
   
   
  		   最近的请求在队列中等待的毫秒数。执行最近的请求所用的毫秒数。Queued在理想状况下应该接近0，Request Queued 等候处理的请求数。该计数器应保持接近 0。超过 IIS 队列长度会出如果这两个值太大， 那么需要重现“服务器太忙”错误
  		    
  
   
  		    
  		    
  		    
  
   
  		    
  		    
  		    
  

6.6 SQLServer

这里针对SQLServer2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。


  Object（
  		   Counters
  		   Description
  		   参考值
  
  Processor
  		   %Processor time
  		   CPU 使用率
  		    
  
  SQL Server:  Logins/sec
  		   这是每秒登录到 SQL Server 的计数
  		    
  		    
  
  SQLServer:CacheManage
  		   Cache Hit Ratio
  (all instances)
  		   显示在高速缓存中找到数据的命中率。如果数值持续小于 85%， 则表
  示内存有问题。
   
   
  		    
  
  SQL Server
  General  Statistics
  		   User Connections
  		   显示当前 SQL 用户数。与  Active Server Pages：Requests/Sec 计数器
  进行比较， 可帮助了解脚本对 SQL Server 的影响程度。如果差别过大， 则表示测试脚本不能有效地对SQL Server 进行应力测试。
   
  		    
  
  SQLServer:Locks
  		   Lock Waits/sec
  		   显示在当前进程完成之前强制其他进程等待的每秒锁定请求的数量。如果该值始终大于 0， 则表示事务有问题。
   
  		    
  
  SQLServer:  BuffeManage
  		   Buffer Manager  Hit Ratio
  		   计数器值依应用程序而定， 但比率最好为 90%或更高。增加内存直到这一数值持续高于 90%， 表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
   
  		    
  
  SQLServer
  SQL Statistics
  		   Batch  Requests/sec
  		   每秒收的Transact-SQL命令批数。这一统计信息受所有约束（ 如I/O、用户数、高速缓存大小、请求I/O、用户数、高速缓存大小、请求的复杂程度等） 影响。批请求数值
  高意味着吞吐量很好。
   
  		    
  
  SQL Server:
  Buffer Manager 
   
  		   Lazy Writes/sec
  		   每秒被缓冲区管理器的惰性写入器写入的缓冲区数。惰性写入器是一
  个系统进程， 其主要任务是刷新成批的老化的脏缓冲区（ 指包含更改
  的缓冲区， 这些更改必须写回磁盘， 才能使该缓冲区由其它页重新使
  用）， 并使之可由用户进程使用。惰性写入器消除了为创建可用缓冲区而频繁执行检查点的需要。
   
  		    
  
  SQL Server: 
  Buffer Manager 
   
  		   Page Reads/sec
  		   每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据
  库间的物理页读取总数。由于物理I/O 的开销大，可以通过使用更大
  的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法， 使开销减到最小。
   
  		    
  
  SQL 
  Server:Databases  
   
  		   Transactions/sec
  		   每秒为数据库启动的事务数
  		    
  

这里针对SQLServer2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL

Server 的联机文档。

6.7Network Delay
如果要监视的两台计算机在同一个局域网络内， 建议不要使用Network Delay Monitor。
因为在同一局域网内，Network Delay 会非常的小， 网络监视器会有足够的时间在每秒钟内发送成百上千的请求， 这样会导致源计算机（source machine） 的CPU 和内存超负荷工作。

默认情况下“Enabledisplay of network nodes by DNS names”选择是没有选中的， 因为

选中它会明显的降低该监视器的速度。
本帖最后由 技术狂人 于 2012-5-21 19:35 编辑 

7 分析实时监视图表
这一章仅仅介绍几个最重要的图表。
Q1 事务响应时间是否在可接受的时间内？ 哪个事务用的时间最长？ 
看Transaction Response Time 图，可以判断每个事务完成用的时间， 从而可以判断出那个事务用的时间最长，那些事务用的时间超出预定的可接受时间。
Q2 网络带宽是否足够? 
“Throughput”图显示在场景运行期间的每一秒钟，从Web Server 上接受到的数据量的值。
拿这个值和网络带宽比较，可以确定目前的网络带宽是否是瓶颈。
如果该图的曲线随着用户数的增加，没有随着增加， 而是呈比较平的直线， 说明目前的
网络速度不能够满足目前的系统流量。
Q3 硬件和操作系统能否处理高负载? 
“Windows Resources” 图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据， 可以把瓶颈定位到特定机器的某个部件。

8 经常遇到的问题

8.1VuGen的问题
在使用VuGen 中经常会遇到的问题。

8.2Controller的问题
在使用Controller 中经常会遇到的问题。
1. 在添加完Load Generators 机器时， 连接老是失败； 添加的机器明明已经安装了
loadrunner， 并且网络通讯正常。
解决方法：在安装loadrunner 的第七步骤， 应该选择第2 项， 如果选择了第一项， 
就会有这种问题。重新安装一下即可。
2. 在VuGen 中运行良好的脚本， 到Controller 中运行却出问题。
这种问题可能会遇到。为了确定问题出在Controller 中的场景，而不是脚本的问题， 
你应该在所有的Load Generators 机器上使用VuGen 运行测试脚本， 确保都能够运
行正确。因为VuGen 和Controller 运行的机制不一样。在VuGen 中运行时使用的
是完整的浏览器，而在Controller 中运行时使用的只是浏览器的基本的部分。

8.3 计数器的问题
在使用性能计数器中经常会遇到的问题。
1. 添加了Windows Resources 计数器后， 却看不到实时的数据。
解决方法：要得到监视的数据， 必须要在被监视的服务器（Web Server） 上获得管
理员权限。最简单的方法是在“网络邻居”中以administrator 身份登陆Web Server。
当然使用下面的控制台命令也可以：net use \< 机器名> 然后登陆用户名和密码即
可。（登陆的用户名必须具有管理员权限） 
2. 添加了一些默认的性能计数器后， 出现了错误。
解决方法：可能是一些LoadRunner 默认的计数器在WebServer 上已经不存在的原
因，尤其是数据库的计数器方面。简单的解决方法， 就是删除有问题的计数器，添
加比较接近的计数器（可能需要参考Windows 帮助或者数据库的帮助） 

9．结果分析
根据不同的场景设计，配置脚本后进行测试得到如下结果
测试环境
LMM:
       CPU：4x2.7G       RAM:4G  

       Websphere5.0 + IBM Http Server  

       线程池：100
JDBC连接池：100
会话超时：30分钟
       
DS:
       CPU：4x2.2          RAM:4G

       Websphere5.0 + IBM Http Server

线程池：100
JDBC连接池：100
会话超时：30分钟

DB&LDAP:
       CPU：2x2.2G        RAM:4G

       Oralce8.1.7 + LDAP


测试工具：Load Runner 7.8
用户数据：用户名test1 – test100； 口令与用户名相同。

测试用例1
测试场景描述
用户登录的lmm模块，总共登陆24个用户，所有用户都同时并发操作。 
用户点击“登记的教程”
用户点击“启动”，进行课程学习，进入DS模块
在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。
点击“返回LMS” 按钮，返回到lmm模块
点击“退出”按钮，退出系统
测试结果
LMM与DS模块CPU平均利用率在10%以下。LMM服务器CPU利用率峰值为20%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为7秒），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过5秒，所有交易成功。

测试用例2
测试场景描述
用户登陆lmm模块，总共登录48个用户，每1秒登录1个用户
用户点击“已登记教程”
用户点击“启动”，进行课程学习，进入DS模块
在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习；
点击“返回LMS” 按钮，返回到lmm模块
点击“退出”按钮，退出系统
测试结果
LMM与DS模块CPU平均利用率在5%以下。LMM服务器CPU利用率峰值为10%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为8%，其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户操作响应时间不超过3秒，所有交易成功。
测试用例3
测试场景描述
用户登录的lmm模块，总共登陆48个用户，所有用户都同时并发操作。 
用户点击“登记的教程”
用户点击“启动”，进行课程学习，进入DS模块
在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。
点击“返回LMS” 按钮，返回到lmm模块
点击“退出”按钮，退出系统
测试结果
LMM与DS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为10秒），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过10秒，所有交易成功。
测试用例4
测试场景描述
用户登录的lmm模块，总共登陆48个用户，每秒同时登录10个用户。 
用户点击“登记的教程”
用户点击“启动”，进行课程学习，进入DS模块
在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。
点击“返回LMS” 按钮，返回到lmm模块
点击“退出”按钮，退出系统
测试结果
LMM与DS模块CPU平均利用率在10%以下。LMM服务器CPU利用率峰值为10%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为2秒），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过5秒，所有交易成功。
测试用例5
测试场景描述
用户登录的lmm模块，总共登录100个用户，每1秒登录一个用户。 
用户点击“登记的教程”
用户点击“启动”，进行课程学习，进入DS模块
在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。
点击“返回LMS” 按钮，返回到lmm模块
点击“退出”按钮，退出系统
测试结果
LMM与DS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为10%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为2’20分钟），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户最大操作响应时间30秒，所有交易成功。
测试用例6
测试场景描述
用户登录的lmm模块，总共登陆100个用户，所有用户同时并发操作。 
用户点击“登记的教程”
用户点击“启动”，进行课程学习，进入DS模块
在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。
点击“返回LMS” 按钮，返回到lmm模块
点击“退出”按钮，退出系统
测试结果
LMM与DS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为3分钟），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户超时1个。
测试用例7
测试场景描述
用户登录的lmm模块，总共登陆200个用户，所有用户同时并发操作。 
用户点击“登记的教程”
用户点击“启动”，进行课程学习，进入DS模块
在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。
点击“返回LMS” 按钮，返回到lmm模块
点击“退出”按钮，退出系统
测试结果
LMM CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为5分钟），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户超时108个。
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/shengs/p/4452202.html