商务带宽问题

o℃的浪漫

公司的商务网站有视频这一模块，现在希望得到关于网络带宽的数据，即在有限的带宽下 能够并发多少用户点击视频而使响应时间在预期范围内。请问该怎样测试呢

piaolingxue423

同问如上

阿七

可以使用loadruner测试
先录制用户点击视频的脚本  然后设置场景  模拟用户的操作
可以先假定个值  如1000人   如果不可以通过  则用折半的方法减少  如500     500还不行就250   如果250通过了 就取250 与500的半值   只到找到适合的结果

阿七

至于网络带宽的数据  可以通过loadrunner的一些计数器 查看到  ,而上面我说说的"通过"  就是在你预先定的目标内
比如   你想得到N个人   在你的网络情况下 点播视频     成功率80%   cpu<80%  内存不泄露 使用率<80%  等等
哪你用loadrunner跑    看多少个人的时候   这几个指标和你预定的差不多了   那么你的网站能承载的人数就是这个数了

阿七

贴出来 一些常用的计数器




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

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％

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

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％则处理器可能负载过重，并发生中断

Processor Interrupts/sec %DPC Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断处理器一次， 形成了间15%， 则处理隔活动的后台。器可能负荷过重， 并发生中断。判断应用程序是否存在处理器瓶颈的方法： 如果Processor Queue Length 显示的队列长度保持不变（>=2） 个并且处理器的利用率%Processor Time 超过90%， 那么很有可能存在处理器瓶颈。
如果发现Processor Queue 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 SQL Server这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考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 进行应力测试。
SQLServerocks	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 Serveratabases	Transactions/sec	每秒为数据库启动的事务数

这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL
Server 的联机文档。
6.7 Network Delay如果要监视的两台计算机在同一个局域网络内， 建议不要使用Network Delay Monitor。
因为在同一局域网内，Network Delay 会非常的小， 网络监视器会有足够的时间在每秒钟内发送成百上千的请求， 这样会导致源计算机（source machine） 的CPU 和内存超负荷工作。
默认情况下“Enable display of network nodes by DNS names” 选择是没有选中的， 因为
选中它会明显的降低该监视器的速度。
7 分析实时监视图表这一章仅仅介绍几个最重要的图表。
Q1
事务响应时间是否在可接受的时间内？ 哪个事务用的时间最长？
看Transaction Response Time 图， 可以判断每个事务完成用的时间， 从而可以判断出那个事务用的时间最长， 那些事务用的时间超出预定的可接受时间。
Q2 网络带宽是否足够?
“Throughput”图显示在场景运行期间的每一秒钟， 从Web Server 上接受到的数据量的值。
拿这个值和网络带宽比较， 可以确定目前的网络带宽是否是瓶颈。
如果该图的曲线随着用户数的增加， 没有随着增加， 而是呈比较平的直线， 说明目前的
网络速度不能够满足目前的系统流量。
Q3
硬件和操作系统能否处理高负载?
“Windows Resources” 图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据， 可以把瓶颈定位到特定机器的某个部件。

[ 本帖最后由 阿七 于 2008-9-23 09:29 编辑 ]

o℃的浪漫

原帖由 阿七 于 2008-9-23 09:26 发表
至于网络带宽的数据  可以通过loadrunner的一些计数器 查看到  ,而上面我说说的"通过"  就是在你预先定的目标内
比如   你想得到N个人   在你的网络情况下 点播视频     成功率80%   cpu

请问阿七 这个视频下载完成后  录制完脚本 ，如果期间有用户的视频时断时续  这是不是通过了呢？  当我并发200个用户时，发现全都失败了 我不知道问题处在哪里·~~

tianlixian_deng

啊七介绍的解决方法,对我将要进行的性能测试非常有用.在这里谢谢了.
,
太让人感动了,孜孜不倦的为人们解答.,,,在这里对给你说一声,辛苦了.你一定会有福报..

阿七

原帖由 o℃的浪漫 于 2008-9-23 12:09 发表

请问阿七 这个视频下载完成后  录制完脚本 ，如果期间有用户的视频时断时续  这是不是通过了呢？  当我并发200个用户时，发现全都失败了 我不知道问题处在哪里·~~

先  你录制单个用户的操作  会出错吗?  就是录制1个用户 在点播视频   这个期间肯定是先会下载 缓冲 ,然后才播放撒    一直到你停止  ,这个过程会出错吗?

阿七

原帖由 tianlixian_deng 于 2008-9-23 15:32 发表
啊七介绍的解决方法,对我将要进行的性能测试非常有用.在这里谢谢了.
,
太让人感动了,孜孜不倦的为人们解答.,,,在这里对给你说一声,辛苦了.你一定会有福报..

感谢 感谢 大家一起加油 进步哈

阿七

要不  这样
你先录制单个的用户操作,保障单个用户录制的过程是正确的,录制的过程,loadrunner没有报错.
然后你在运行并发的时候,使用
1 同时并发
2 梯度增加并发
从少开始往上加  
像你200用户没有成功的    哪肯定就向下减   100  咯  50咯    找到成功率>预期 的临界值   比如我 定成功率最少要60%      那就看  多少用户的时候   失败的比例<40%    那么这个值就是目前只能承受的人数了    那么接下来 就要看你预定的目标是多少人了  比如现在我得出视频点播只能承受100,但我设计时的目标是200人,那么你就要再次设计并发为200的情况,对比100和200的计算器,假设200的计算器指标是100的2倍,那么用200的指标于100的2倍(不是很准啦,可能是几何指数,具体问题具体分析)数据对比分析,找出瓶颈,再根据瓶颈,该加CPU 就加CPU  ,该加内存就加内存,改加带宽,加带宽.

o℃的浪漫

谢谢阿7 啦

阿七

piaolingxue423

谢谢阿七了  嘿嘿

lvxjsheng0508

学习学习。