1. 利用Windows自带的性能监视器对WebService服务进行监控，通常使用哪些计数器，标准值是什么
1. 处理器对象(Processor Object)
2. 系统对象(System Object)
3. SQL Server：缓冲区管理器对象( B u ffer Manager Object)
4. SQL Server：数据库对象(Database Object)
5. SQL Server：常规统计对象(General Statistics Object)
6. SQL Server：闩对象(Latches Object)
7. SQL Server：锁对象(Locks Object)
8. SQL Server：内存管理器对象(Memory Manager Object)
9. SQL Server：S Q L统计对象(SQL Statistics Object)
10. 逻辑磁盘对象(Logical Disk Object)
11. 物理磁盘对象(PhysicalDisk Object)
12. 内存
一条经验规则是不要使你所监控的每个处理器的C P U使用率高于9 0％。峰值超过9 0％是可以接受的，但平均使用率超过9 0％则是应该避免的。
• 处理器时间百分比(％Processor Time) 处理器执行一个非空闲线程的时间百分比。用％1 0 0减去处理器空闲的总时间得出这个值。这是整个系统的C P U使用的一个好的指示器。
• 特权时间百分比(％Privileged Time) 处理器用于在特权模式下(即，执行操作系统功能和运行驱动器，如I / O )工作时间的百分比。这个时间包括C P U (或C P U )用于维护中断和延迟过程调用( D P C )的时间。
• 用户时间百分比(％User Time) 处理器用于在用户模式工作的时间百分比。这种类型的工作是由应用产生的。通常，希望极大化用户时间百分比的值，极小化特权时间百分比的值。
• 中断时间百分比(％Interrupt Time) CPU忙于维护硬件中断的时间百分比。系统中的许多硬件部件，如鼠标、网络接口卡或磁盘控制器，都可以发出处理器中断。你可以将中断看作为Windows NT正常操作的一部分发生。
• 中断数/秒(Interrupts/sec) 处理器每秒接收并处理的硬件中断的数量。它不包括系统
D P C，系统D P C单独计数。
系统对象与它的相关计数器衡量处理器上运行的线程的总计数据。虽然使用这些计数器不能观察一个特定处理器的工作负载或一个特定线程的行为，但它们提供了有关整个系统性能有价值的内部信息。系统计数器如下所示：
• 处理器队列长度(Processor Queue Length) 处理器队列中的线程的数量。换句话说，它
是等待运行的线程数。即使你的系统具有多个处理器，但只有一个队列用于处理器时间。计数器只记录那些准备执行但仍处于等待的线程，不是那些正在运行的线程。
• 环境切换/秒(Context Switches/sec) 系统上的所有处理器从一个线程切换到另一个线程的组合比率。当一个正在运行的线程自动地放弃处理器，处理器由一个高优先级的待命线程抢占时发生环境切换，或在用户模式和特权(核心)模式之间切换，以使用一个执行或子系统的服务。这是线程的总和：计算机上运行在所有处理器上的所有线程的环境切换数/秒。
缓冲区管理器计数器提供了SQL Server使用的内存缓冲区的有关信息。这些计数器如下所示：
• 高速缓存命中率( B u ffer Cache Hit Ratio) 引用当前位于高速缓存中页的需求的百分率。预先在内存中拥有页，允许SQL Server避免请求从磁盘子系统执行一次物理I / O。因为访问内存相对于访问物理I / O，代价更小，一个高的缓冲区高速缓存命中率增强了系统的性能与吞吐量。如果你的系统很好地调整过，这个命中率应该是8 0％或更高。如果具有一个低的缓冲区高速缓存命中率，你应该为SQL Server分配更多的内存。如果你已将现有的所有内存都分配给了SQL Server，那么需要增加系统中物理内存的数量。
• 高速缓存大小(页)(Cache Size) 在SQL Server缓冲区高速缓存中的页的数量。这个数量乘以8 K B，即可得到正在使用的以千字节为单位的缓存数。
• 空闲缓冲区(Free Buffer) 空闲SQL Server内存缓冲区的数量。
• 读的页/秒(Page Reads/sec) 每秒请求的物理数据页I / O的数量。
• 偷取的页计数(Stolen Page Count) SQL Server用于缓冲区高速缓存的页数，这些内存被给予系统中的另外一个进程。Windows NT回收这个内存以满足其他系统部件的需要。
• 写的页/秒(Page Writes/sec) 由SQL Server执行的每秒写的物理数据页的数量。
数据库对象计数器提供了有关SQL Server数据库的信息，包括可用的空闲日志空间量和数据库中活动事务的数量。对于系统中的每个数据库的每个计数器有一个实例。这些计数器包括如下：
• 日志刷新等待/秒(Log Flush Wait/sec) 在能够继续执行前，必须等待日志刷新的数据库提交数量。
• 日志使用的百分比(Percent Log Used) SQL Server实际使用的当前定义的日志空间的百分比。
常规统计对象含有常规服务器范围活动的有关信息，它有一个计数器：
• 用户连接数(User Connections) 系统中用户连接的当前数量。
这个对象计数器提供了在内部SQL Server资源中有效的闩的信息。计数器如下：
• 平均闩等待时间(毫秒) ( Average Latch Wait Time) 闩请求在得到服务之前必须等待的平均时间，以毫秒为单位。
• 闩等待数/秒(Latch Waits/sec) 不能立即服务，被迫等待其他资源释放的闩请求的数量。
锁对象提供了由SQL Server提出的各个锁请求的有关数据，例如锁生命周期和死锁。可以在系统上具有多个这些计数器的实例。计数器如下所示：
• 平均等待时间(毫秒) ( Average Wait Time) 每个锁请求被迫等待的平均时间量，以毫秒为单位。
• 锁到期数/秒(Lock Timeouts/sec) 在系统中过期的锁请求的数量。
• 锁等待数/秒(Lock Wa i t s / s e c )不能立即满足，需要调用线程在给予锁之前处于等待状态的锁请求的数量。
• 死锁数/秒(Number of Deadlocks/sec) 导致产生死锁的锁请求的数量。
内存管理器对象含有有关SQL Server内存使用的信息，包括SQL Server正在使用的高速缓
存内存的数量。这个对象下的计数器如下所示：
• 内存授权挂起(Memory Grants Pending) 等待授予工作空间内存的进程的当前数量。
• S Q L高速缓存内存(KB)(SQL Cache Memory) SQL Server用于动态SQL 高速缓存的动态
内存数量。
• 目标服务器内存( K B ) ( Ta rget Server Memory) SQL Server将会消耗的动态内存的总额。
• 总的服务器内存( K B ) ( Total Server Memory) SQL Server当前消耗的动态内存的总额。
这个对象提供了系统上正在执行的S Q L查询的有关信息，包括查询编译和重新编译的数量的数据。它有如下计数器：
• 批请求/秒(Batch Requests/sec) 服务器接收到的S Q L批请求的数量。
• SQL 编译/秒(SQL Compilations/sec) SQL Server每秒执行的S Q L语句编译的数量。
• S Q L重新编译/秒(SQL Re-Compilations/sec) SQL Server每秒执行的S Q L语句重新编译的数量。
逻辑磁盘对象提供了有关逻辑磁盘I / O性能的信息。逻辑磁盘计数器与Windows NT磁盘
系统管理员分配给逻辑磁盘驱动器的字母相关。这个对象含有如下计数器：
• 磁盘读时间百分比(％Disk Read Time) 选中的逻辑磁盘忙于服务读请求总共用去时间的
百分比。
• 磁盘写时间百分比(％Disk Write Time) 选中的逻辑磁盘忙于服务写请求总共用去时间
的百分比。
• 磁盘时间百分比(％Disk Time) 选中的逻辑磁盘忙于服务读请求或写请求总共用的时间
的百分比，是磁盘写时间百分比与磁盘读时间百分比的和。
• 空闲时间百分比(％Idle Time) 逻辑磁盘在采样时间间隔中处于空闲状态的时间百分比。
• 平均磁盘队列长度( Avg. Disk Queue Length) 在采样的时间间隔中，选中的逻辑磁盘读请求和写请求排队的平均数量。
• 平均磁盘读队列长度( Avg. Disk Read Queue Length) 在采样的时间间隔中，对选中的逻辑磁盘读请求排队的平均数量。
• 平均磁盘写队列长度( Avg. Disk Write Queue Length) 在采样的时间间隔中，对选中的逻辑磁盘写请求排队的平均数量。
• 平均磁盘秒数/读( Avg. Disk sec/Read) 从逻辑磁盘读数据的平均时间，以秒为单位。
• 平均磁盘秒数/写( Avg. Disk sec/Write) 向逻辑磁盘写数据的平均时间，以秒为单位。
• 平均磁盘秒数/传输( ( Avg. Disk sec/Transfer) 从逻辑磁盘进行传输的平均时间，以秒为单位。
• 磁盘读/秒(Disk Reads Bytes/sec) 逻辑磁盘上每秒读字节。
• 磁盘读/秒(Disk Writes Bytes/sec) 逻辑磁盘上每秒写字节。
• 磁盘读/秒(Disk Reads/sec) 逻辑磁盘上的读操作比率。
• 磁盘写/秒(Disk Writes/sec) 逻辑磁盘上的写操作比率。
• 磁盘传输/秒(Disk Transfers/sec) 逻辑磁盘上的读和写操作的比率。
物理磁盘对象提供了有关物理磁盘I / O性能的信息。它的磁盘计数器与系统中的物理驱动器有关，并且只有当运行了D i s k P e r f服务时，它才被激活。这个对象下的计数器如下所示：
• 磁盘读时间百分比(％Disk Read Time) 选中的物理磁盘忙于服务读请求总共用的时间的百分比。
• 磁盘写时间百分比(％Disk Write Time) 选中的物理磁盘忙于服务写请求总共用的时间的百分比。
• 磁盘时间百分比(％Disk Time) 选中的物理磁盘忙于服务读请求或写请求总共用的时间的百分比，是磁盘写时间百分比与磁盘读时间百分比的和。
• 空闲时间百分比(％Idle Time) 物理磁盘在采样时间间隔中处于空闲状态的时间百分比。
• 平均磁盘队列长度( Avg. Disk Queue Length) 在采样的时间间隔中，选中的物理磁盘读请求和写请求排队的平均数量。
• 平均磁盘读队列长度( Avg. Disk Read Queue Length) 在采样的时间间隔中，选中的物理磁盘读请求排队的平均数量。
• 平均磁盘写队列长度( Avg. Disk Write Queue Length) 在采样的时间间隔中，选中的物理磁盘写请求排队的平均数量。
• 平均磁盘秒数/读( Avg. Disk sec/Read) 从物理磁盘读数据的平均时间，以秒为单位。
• 平均磁盘秒数/写( Avg. Disk sec/Write) 向物理磁盘写数据的平均时间，以秒为单位。
• 平均磁盘秒数/传输( Avg. Disk sec/Transfer) 从物理磁盘进行传输的平均时间，以秒为单位。
• 磁盘读/秒(Disk Reads Bytes/sec) 物理磁盘上每秒读字节。
• 磁盘读/秒(Disk Writes Bytes/sec) 物理磁盘上每秒写字节。
• 磁盘读/秒(Disk Reads/sec) 物理磁盘上的读操作比率。
• 磁盘写/秒(Disk Writes/sec) 物理磁盘上的写操作比率。
• 磁盘传输/秒(Disk Transfers/sec) 物理磁盘上的读和写操作的比率。
内存在任何系统中都是一个非常有价值的资源。Windows NT不只允许过量使用内存，而且鼓励你过量使用内存。Windows NT提供了一种透明机制，允许应用“相信”它们具有比系统中可用的物理内存更多的内存。当Windows NT处理应用时，它将不使用的内存页调出(交换出)到磁盘上的页文件中。在大多数系统中，页调度是正常的，但过量的页调度会削弱整个系统的性能。下面的计数器允许你监控系统的页调度。
• 失效的页/秒(Page Faults/sec) 每秒由处理器处理的失效页的全部数量。当一个进程需
要的代码或数据不在它的工作区(它的空间在物理内存中)中时，发生失效页。这个计数
器包括硬的页失效(那些需要磁盘访问的)和软的页失效(在物理内存的其他地方发现了失
效页)。
• 读的页/秒(Page Reads/sec) 读取磁盘以解决硬的页失效所需要的时间数(当一个进程需要的代码或数据不在其工作区或内存中的其他地方，必须从磁盘提取这些代码和数据时，发生硬的页失效)。这个计数器包括为满足在文件系统高速缓存(通常是应用请求的)以及在非高速缓存映像内存文件中的失效而进行的读。
• 写的页/秒(Page Writes/sec) 将页写向磁盘以释放物理内存空间的时间数。只有当页在物理内存中被改变的时候，将页写入磁盘，这样，它们更有可能含有数据，而不是代码。
• 页/秒(Pages/sec) 为解决硬的页失效，所需要读或写磁盘的时间数。它是读的页/秒与写的页/秒的计数器的和。
2. windows自带性能监控器问题
你要滴在任务管理器里全部都有 ALT +DEL+ CTRL
Windows 性能监视器工具
如果需要在一台计算机上监视多个 Report Server 实例，可以同时或单独监视这些实例。选择要包括的实例是计数器添加过程的一部分。有关使用 Windows 附带的性能工具的更多信息，请参见微软 Windows 产品文档。
若要访问性能工具
• 从“开始”菜单上选择“运行”。
• 在“打开”文本框中输入“perfmon”，然后单击“确定”。
• 在性能监视器工具中，在左侧窗格里选择 System Monitor 对象，然后右击“性能”图表。
• 选择“添加计数器”。
现在，可以开始选择这些对象和要监视的计数器了。
ASP.NET 应用程序性能计数器
有关 ASP.NET 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 ASP.NET 应用程序（包括 Reporting Services）性能的重要计数器。
性能对象 计数器 实例 描述
Processor（处理器）
% Processor Time（处理器时间百分比）
__Total
“% Processor Time”监视运行 Web 服务器的计算机的 CPU 利用率。低 CPU 利用率或者无法最大化 CPU 利用率（无论客户端负载为多少）都表明 Web 应用程序中存在对资源的争用或锁定。
Process（进程）
% Processor Time（处理器时间百分比）
aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）
由 ASP.NET 工作进程所使用的处理器时间所占的百分比。在将标准负载情况下的性能与先前捕获的基准进行对比时，如果此计数器的值出现下降，则说明降低了对处理器的需求，因此也提高了伸缩性。
Process（进程）
Working Set（工作集）
aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）
由 ASP.NET 主动使用的内存数量。虽然应用程序开发人员对应用程序使用的内存数量拥有最大的控制权，但系统管理员也可通过调整会话的超时期限来显着影响这一点。
Process（进程）
Private Bytes（专有字节）
aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）
Private Bytes 是当前分配给该进程且不能由其他进程共享的内存数量（以字节计）。不时出现的尖峰表明某些地方存在瓶颈，会导致工作进程继续持有不再需要的内存。如果此计数器突然下降为接近 0 的值，则可能表示 ASP.NET 应用程序由于无法预料的问题进行了重启。为了验证这一点，请监视“ASP.NET Application Restarts”计数器。
ASP.NET Applications（ASP.NET 应用程序）
Requests/ Sec（每秒的请求数）
__Total
允许您检验请求的处理速度是否于发送速度相适应。如果每秒请求数的数值低于每秒产生的请求数，则会出现排队现象。这通常意味着已经超过了最大请求速度。
ASP.NET Applications（ASP.NET 应用程序）
Errors Total（总错误数）
__Total
在执行 HTTP 请求期间发生的错误总数。包括任何分析器、编译或运行时错误。此计数器是“Errors During Compilation”（编译错误数）、“Errors During Preprocessing”（预处理错误数）和“Errors During Execution”（执行错误数）计数器的总和。运转正常的 Web 服务器不应产生任何错误。如果错误发生在 ASP.NET Web 应用程序中，它们的存在可能会让实际的吞吐量结果产生偏差。
ASP.NET
Request Execution Time（请求执行时间）
显示了呈现所请求页面并将其传送给用户所需的时间（以毫秒计）。跟踪此计数器通常要比跟踪页面呈现时间效果更好。此计数器可以更全面地衡量从开始到结束的整个请求时间。在与基准进行对比时，如果此计数器的平均值较低，则说明应用程序的伸缩性和性能均得到了改善。
ASP.NET
Application Restarts（应用程序重新启动）
应用程序在 Web 服务器生存期间发生重新启动的次数。每次发生 Application_OnEnd 事件时，应用程序的重新启动次数都会增加。应用程序进行重新启动的原因可能是：更改了 Web.config 文件、更改了存储在应用程序的 \bin 目录下的程序集、或者 Web Forms 页面中发生了太多的更改。如果此计数器的值出现意料之外的增加，说明某些不可预知的问题导致 Web 应用程序被关闭。在这种情况下，应该认真调查问题原因。
ASP.NET
Requests Queued（排队的请求数）
在队列中等待服务的请求数。如果此数字随着客户端负载的增加而呈现线性的增长，则说明 Web 服务器计算机已经达到了它能够处理的并发请求极限。此计数器的默认最大值为 5,000。您可以在计算机的 Machine.config 文件中更改此设置。
ASP.NET
Worker Process Restarts（工作进程重新启动）
工作进程在服务器计算机上重新启动的次数。如果出现意料之外的故障或者被有意回收，则工作进程会重新启动。如果此计数器的值出现意料之外的增加，应认真调查问题原因。
除了上表中介绍的这些核心监视要素之外，在您试图诊断 ASP.NET 应用程序具有的特定性能问题时，下表中的性能计数器也可对您有所帮助。
性能对象 计数器 实例 描述
ASP.NET Applications（ASP.NET 应用程序）
Pipeline Instance Count（管线实例计数）
__Total
指定 ASP.NET 应用程序的活动请求管线实例的数量。由于只有一个执行线程可以在管线实例内运行，所以此数值反映了为特定应用程序处理的并发请求的最大数量。大多数情况下，在存在负载的情况下此数值较低为佳，这表明处理器得到了很好的利用。
.NET CLR Exceptions（.NET CLR 异常）
# of Exceps Thrown（引发的异常数）
显示应用程序中引发的异常数。如果此数值出现意料之外的增加，说明可能存在性能问题。如果仅仅存在异常，则并不需要担心，因为异常对于某些代码路径来说是正常工作的一部分。例如，HttpResponse.Redirect 方法通过引发一个不可捕获的异常 ThreadAbortException 来完成工作。同样，对 ASP.NET 应用程序跟踪此计数器也更加有用。使用“Errors Total”计数器确定该异常是否将导致应用程序出现意料之外的错误。
System（系统）
Context Switches/ sec（每秒的上下文切换次数）
测量 Web 服务器计算机上所有处理器切换线程上下文的速度。如果此计数器的值很高，可能表示对锁的争用频繁发生，或者在线程的用户模式和内核模式之间切换频繁。使用采样优化程序和其他工具执行进一步调查可证实上述猜测。
Reporting Services 性能计数器
Reporting Services 包括一组它自己的性能计数器，用于收集有关报告处理和资源消耗方面的信息。可通过 Windows 性能监视器工具中出现的两个对象来监视实例和组件的状态和活动：MSRS 2005 Web Service 和 MSRS 2005 Windows Service 对象。
MSRS 2005 Web Service 性能对象包括一组用来跟踪 Report Server 处理过程的计数器，这些处理过程通常通过在线交互式报告浏览操作而引发。这些计数器在 ASP.NET 停止该 Web 服务后被重设。下表列出了可用于监视 Report Server 性能的计数器，并描述了它们的目的。
性能对象：RS Web Service
计数器 描述
Active Sessions（活动会话数）
活动会话的数量。此计数器反映了尚未过期的所有浏览器会话总数。这并不是同时处理的请求数，而是存储在 ReportServerTempDB 数据库中的会话数量。
Cache Hits/Sec（每秒缓存命中次数）
每秒从目录中取得的报告请求的数量。如果此值增加，而“Memory Cache Hits”的值不增加，则说明报告数据没有被重新处理，但是页面被重新呈现。将此计数器与 Memory Cache Hits/Sec 计数器一同使用，可以确定用于缓存、磁盘或内存的资源是否充足。
Cache Misses/Sec（每秒缓存未命中数）
每秒未能从目录中（与内存中相对）返回报告的请求数量。将此计数器与 Memory Cache Misses/Sec 计数器一同使用，可以确定用于缓存、磁盘或内存的资源是否充足。
First Session Requests/Sec（每秒的首次会话请求数）
每秒中从 Report Server 缓存中启动的新的用户会话数量。
Memory Cache Hits/Sec（每秒内存缓存命中数）
每秒中从内存中的缓存里取得报告的次数。内存中缓存是 Reporting Services 缓存的一部分，用于在内存或临时文件中保存已呈现过的报告。这样可以为请求提供最佳的性能，因为无需执行任何处理工作。如果使用内存中缓存，报告服务器将不会通过查询 SQL Server 来获得缓存的内容。
Memory Cache Misses/Sec（每秒内存缓存未命中数）
每秒中未能从内存中的缓存里取得报告的次数。
Next Session Requests/Sec（每秒的下一次会话请求）
每秒在现有会话中请求打开报告的次数。
Report Requests（报告请求）
当前处于活动状态并且将由 Report Server 进行处理的报告数量。
Reports Executed/Sec（每秒执行的报告数）
每秒成功执行的报告的数量。此计数器提供了有关报告处理量的统计信息。综合使用此计数器和 Request/Sec，比较可从缓存中返回的报告请求的执行情况。
Requests/Sec（每秒的请求数）
每秒向 Report Server 发出的请求数。此计数器跟踪由 Report Server 处理的所有类型的请求。
Total Cache Hits（缓存命中总数）
自服务启动以来，从缓存中获得报告的请求总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。
Total Cache Misses（总的缓存未命中数）
自服务启动以来，不能从缓存中获得报告的总次数。此计数器在 ASP.NET 停止该 Web 服务后被重设。可使用此计数器确定磁盘空间和内存是否充足。
Total Memory Cache Hits（总的内存缓存命中数）
自服务启动以来，从内存中缓存里返回的已缓存报告的总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。内存中缓存是在 CPU 内存中存储报告的那部分缓存。如果使用内存中缓存，报告服务器将不会通过查询 SQL Server 来获得缓存的内容。
Total Memory Cache Misses（总的缓存未命中数）
自服务启动以来，针对内存中缓存的缓存未命中总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。
Total Processing Failures（处理故障总数）
自服务启动以来，发生的所有报告处理故障的总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。处理故障可能来自报告处理器，也可能来自任何扩展。
Total Reports Executed（执行的报告总数）
自服务启动以来得到成功执行的报告的总数。
Total Requests（总请求数）
自服务启动以来，向 Report Server 发送的所有请求的总数。
RS Windows Service 性能对象包括一组用于跟踪报告处理过程的计数器，这些处理过程是通过预定操作而引发的。预定操作可能包括订阅和交付、报告执行快照以及报告历史。微软的工作负载中并不包含任何预定操作或交付操作，此处列出这些性能计数器仅是便于您进行参考。
可使用此性能对象监视 Report Server Windows 服务。如果您准备在一个横向伸缩配置中运行 Report Server，那么这些计数器应用于所选的服务器，而不是应用于横向伸缩配置整体。这些计数器在应用程序域回收之时将被重设。下表列出了可用于监视预定和交付操作的计数器，并描述了它们的目的。
性能对象：RS Windows Service
计数器 描述
Cache Flushes/Sec(每秒缓存刷新次数)
每秒刷新缓存的次数。
Cache Hits/Sec（每秒缓存命中数）
每秒获取到缓存报告的请求数量。
Cache Misses/Sec（每秒缓存未命中数）
每秒未能从缓存中获得报告的请求的数量。
Delivers/Sec（每秒交付数）
每秒从各种交付扩展交付的报告的数量。
Events/Sec（每秒事件数）
每秒处理的事件数量。被监视的事件，包括 SnapshotUpdated 和 TimedSubscription。
Memory Cache Hits/Sec（每秒内存缓存命中数）
每秒中从内存中的缓存里取得报告的次数。
Memory Cache Misses/Sec（每秒内存缓存未命中数）
每秒中未能从内存中的缓存里取得报告的次数。
Report Requests（报告请求数）
当前处于活动状态并且将由 Report Server 进行处理的报告数量。可使用此计数器评估缓存策略。向特定呈现扩展提交的请求数。请求的数量可能比执行的报告数量多许多。
Reports Executed/Sec（每秒执行的报告数）
每秒成功执行的报告的数量。
Snapshot Updates/Sec（每秒快照更新数）
每秒报告执行快照的预定更新数量。
Total App Domain Recycles（应用程序域回收总数）
自服务启动以来回收的应用程序域总数。
Total Cache Flushes（缓存刷新总数）
自服务启动以来，Report Server 的缓存更新总数。
Total Cache Hits（缓存命中总数）
自服务启动以来，从缓存中获得报告的请求总数。
Total Cache Misses（总的缓存未命中数）
自服务启动以来，不能从缓存中获得报告的总次数。
可使用此计数器确定是否需要更多磁盘空间或内存。
Total Deliveries（总交付数）
由 Scheling and Delivery Processor 交付的报告总数（对于所有交付扩展）。
Total Events（总事件数）
自服务启动以来发生的事件的总数。
Total Memory Cache Hits（总的内存缓存命中数）
自服务启动以来，从内存中缓存里返回的已缓存报告的总数。
Total Memory Cache Misses（总的缓存未命中数）
自服务启动以来，针对内存中缓存的缓存未命中总数。
Total Processing Failures（处理故障总数）
自服务启动以来，发生的所有报告处理故障的总数。处理故障可能来自报告处理器，也可能来自任何扩展。
Total Rejected Threads（被拒绝的线程总数）
拒绝执行异步处理后在同一线程中作为同步过程在以后进行处理的数据处理线程总数。
Total Report Executions（报告执行总数）
已执行报告的总数。
Total Requests（请求总数）
自服务启动以来得到成功执行的报告的总数。
Total Snapshot Updates（快照更新总数）
自服务启动以来，报告执行快照进行更新的总数。
如果您打算排除 Reporting Services 存在的性能问题，记录以下性能计数器通常很有帮助：ASP.NET、ASP.NET Applications、Process、System、Memory、Physical Disks、.NET Exceptions、.NET Memory、.NET Loading、.NET CLR Locks and Threads 以及 .NET CLR Data。
可选的 Reporting Services 性能计数器
以下列出了一些适用于 RS Web Service 但在默认情况下并未安装的性能计数器。但是，在执行性能优化工作时，可以通过这些计数器来改善您洞察性能的能力。为实现这个目的，请在命令提示符中执行以下语句：
installutil.exe /u ReportingServicesLibrary.dll
然后再执行：
installutil.exe ReportingServicesLibrary.dll
为了成功执行该语句，您可能首先需要修改您的路径，在路径中包含 Microsoft .NET Framework 的安装目录。在路径修改完毕后，请从包含 ReportingServicesLibrary.dll 文件的目录下执行先前语句。默认情况下，该文件安装在 C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL.instance\Reporting Services\ReportServer\bin 目录下。这些计数器没有进行彻底的本地化。
Active Database Connections（活动数据库连接）
某个时间处于活动状态的数据库连接的数量。只统计指向 Report Server 目录的连接。
Active Datasource Connections（活动数据源连接）
某个时间处于活动状态的数据库连接的数量。只统计由当前运行的报告打开的数据源连接。
Active Threads（活动线程）
当前处于活动状态的线程数量。在 Web 服务中，它包含一些为请求提供服务的线程。在交付服务中，它包含工作线程以及维护和轮询线程。
Byte count（字节计数）
对于上一次请求，在呈现当前报告时向客户端返回的字节数量。这与对应的执行日志条目相类似。
Row Count（行计数）
对于上一次请求，由当前报告返回的行的数量。这与对应的执行日志条目相类似。
Time in Compression（压缩时间）
对于上一次请求，在快照和 PDF 报告压缩上花费的时间（以毫秒计）。
Time in data source access（数据源访问时间）
对于上一次请求，在获取报告的数据源信息上花费的时间（以毫秒计）。其中包括执行查询和取回结果所需的时间。这与对应的执行日志条目相类似。
Time in database（数据库时间）
对于上一次请求，在获取 Report Server 目录信息上花费的时间（以毫秒计）。
Time in processing（处理时间）
对于上一次请求，在报告处理上花费的时间（以毫秒计）。这与对应的执行日志条目相类似。
Time in rendering（呈现时间）
对于上一次请求，在呈现报告上花费的时间（以毫秒计）。这与对应的执行日志条目相类似。
3. 如何通过WebView监控提升WebAPP性能
相对于需要专业移动开发人员的原生应用（Native APP），基于HTML5/CSS/JavaScript的WebAPP凭借开发者门槛低、迭代迅速、支持跨平台发布等特点，成为电商、银行等网络服务、浏览类应用的首选，然而由于页面渲染导致的性能差距是WebAPP与原生应用无法抗衡的最大原因，因此针对WebView组件的性能优化就显得至关重要。
为什么是WebView
WebAPP所显示的Web页面都是由一个叫做WebView的组件渲染出来的，每个网页都有一个链接即URL，首先将URL转换成NSURLRequest，然后用加载网页的类WebView加载Request，使用 - (void)loadRequest:(NSURLRequest *)request这个方法，就能将网页加载显示出来。
目前iOS中有两个加载网页的类，分别是UIWebView和WKWebView，UIWebView是UIKit框架中的一个类，而WKWebView是WebKit框架中的类，从性能上来说WKWebView的性能高、稳定性好、占用内存小，完全优于UIWebView。但由于WKWebView是iOS8提供的组件，因此系统版本低于iOS 8.0的iPhone/iPad用户就无法正常使用WKWebView组件开发出来的APP。所以目前大部分开发人员还在使用性能、稳定性并不理想的UIWebView进行WebAPP开发，而本文所说的云智慧透视宝WebView性能监控也是以UIWebView为主要优化目标。
要进行性能监控必须获得WebAPP页面加载全过程的性能数据，透视宝是通过向当前加载链接的html5、jsp、php网页代码中注入获取数据的JS代码，然后通过OC与JS交互，将数据传递给OC，然后再将数据整理发送到透视宝后端。
监控哪些WebView性能数据
透视宝能监控四大类数据：
行为数据：抓取用户在移动端网页点的行为操作，也就是点击网页的内容，分析用户的行为
时间相应数据：分解一个链接从加载开始到完成这段时间内，每个阶段的耗时
Ajax请求数据：抓取终端用户响应时间，响应数据下载时间，数据响应成功的callback执行时间和ajax错误数据
JS错误数据：抓取加载链接的代码错误信息
① 时间响应数据及数据计算公式
（图片来源：51cto技术博客）
参见上图，JS传给透视宝的时间响应数据就是这些字段，其中navigationStart是起点，所有的计算都需要依赖于它。分析移动端H5性能数据，其实就是测算HTML5、JSP、PHP等网页元素在iOS上加载的时间长短，通过这些性能数据前段开发人员能够准确发现性能问题并及时解决，下表是透视宝定义的响应时间分解数据及计算方案：
② 资源时序数据
每一个网页都是有很多资源组成的，包括.js、.png、.jpg、.css、script等，每一个元素的加载都需要加载时间，资源时序数据就是准确记录每一个元素的加载时间及类型，并把这些数据通过JS的performance接口直接获得并传给OC，不需要计算。
③ JS错误及ajax请求数据
JS错误指的是抓取网页代码的错误，包括错误类型及堆栈信息，直接定位错误。ajax请求的数据有请求的链接、uri、 终端用户响应时间，响应数据下载时间，数据响应成功的callback执行时间和ajax错误数据。JS错误和ajax请求数据都是有JS代码直接获取到，不需要处理。
JS代码注入
想要准确监测网页性能就需要进行代码注入，而只有拿到网页的代码才能注入， UIWebView这个类里面除了三个加载链接的方法和4个代理方法，就没有其他内容了，而这些方法并不能获取到内容，所以我们就需要考虑其他方法。UIWebView在加载拦截的时候会进入NSURLProtocol这个类，而恰好这个类能拿到当前加载链接NSURLRequest，而且会走进这个类的 - (void)startLoading方法，这个方法在页面load完成之前，页面刚加载之后，所以就是我们所需要的。
创建一个类，继承NSURLProtocol这个类，重写startLoading方法，由于能拿到链接的request，所以我们就对这个链接发送请求，用原生态的NSURLConnection或者NSURLSession都可以，我们用的NSURLConnection这个类发送请求并设置代理，方法是这个 - (nullableinstancetype)initWithRequest:(NSURLRequest*)request delegate:(nullableid)delegate startImmediately:(BOOL)startImmediately，
NSURLConnection的代理方法中有一个能接受请求链接数据的方法， - (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data，得到的NSData是16进制的字节流数据，通过utf8转码将字节流转换成字符串，然后发现这个字符串正好是这个当前加载网页的代码，
网页代码都是由标签组成，都会有<head>这个标签，我们就把JS代码注入到<head>标签之下，放在自己添加的<script>标签中;代码实现就是获取字符串中<head>这个字符的位置，然后在其下面插入用<script>包装的js代码，然后转回成新的NSData的字节流数据。
由于页面还没有加载，我们已经改动代码了，就需要把注入JS代码的重新记载一次，需要用NSURLProtocol的代理属性NSURLProtocolClient，用NSURLProtocolClient这个中的这个方法- (void)URLProtocol:(NSURLProtocol*)protocol didLoadData:(NSData*)data，将新的NSData加载一次，转回成NSData是因为这个方法需要的是NSData数据。
当然上面只是介绍主要实现的一些方法，还需要用到NSURLConnection的其他代理方法，只是这些方法不需要添加什么，按照常规处理就行了，就不一一介绍了。
性能数据获取
加载链接过程中JS代码就会通过performance接口获取数据，然后获取的这些数据需要传给移动端，如何传递数据呢，传递数据的过程也叫OC与JS交互的过程。
获取数据的时机：
由于不清楚什么时候JS能拿到数据，所以从最开始就需要进行交互的监控，也就是加载链接的时候，因为透视宝SDK用来监控的所以我们不能直接使用这个方法，需要用到OC的运行时，动态加载机制，又叫hook。首先通过添加UIWebView的类目，添加类目是将UIWebView类的实现分散出来，每个类都是由NSbject继承下去，所以每个类都有 (void)load方法，而且这个方法的执行是最早的，我们就在这个方法中使用OC的运行时runtime，使用一个方法交换UIWebView加载链接的三个方法的指针，这样就会在执行加载方法之前执行我们交换出来的方法，在这个方法里面我们传递一个与JS匹配的标识，通过标识相同来获取数据，这样做的目的就是能从最开始就监控数据的传递。
4. 基于web技术的远程监控的方式有哪些
希望这篇文章能对你有帮助：
Web Service使用可扩展标记语言(XML)作为基本的数据表示方式，消除了使用不同组件模型、操作系统和编程语言的系统之间所存在的差异。简单对象访问协议(SOAP，Simple Object Access Protocol)是用于交换XML编码信息的轻量级协议。它的主要作用是为各类XML消息，提供一个简单统一的传输机制。Web Service使用SOAP来包装XML数据，通过HTTP(或MSMQ、SMTP、TCP/IP)作为传输协议，在不同平台、不同软件、不同组织之间进行传递。Web Service的描述语言为WSDL。它提供了一种描述服务接口的标准方法，定义了一种描述接口的抽象语言，使服务的接口定义独立于底层协议和编码方式。通用描述、发现和集成(UDDI)是Web Service的信息注册的标准规范，用来对服务提供动态的注册功能。
可见，Web Service采用XML、SOAP、HTTP、WSDL、UDDI等标准协议。这些协议与特定的操作系统、对象模型和编程语言无关。因此，利用Web Service来建立远程监控系统时
(1) 由于采用标准的协议，不受特定的开发者、平台、语言和数据编码格式的限制;
(2) 开发的Web Service可以供不同的客户调用;
(3) HTTP作为传输协议可以穿过防火墙，提供在Internet上的连接和访问[8];
(4) 如果知道Web Service的地址并具有相应权限，就可以在网络的任何地方进行调用。
3 远程监控系统结构
为了实现工业过程的远程监控，基于Web Service技术的远程监控系统结构如图4所示。
图4 基于Web Service的远程监控系统结构
3.1 基于Web Service的远程监控系统结构
传统的远程监控系统多使用OPC技术来获取各种现场设备的数据，包括实时采样值、历史数据、报警数据等等。该系统也使用OPC来与现场设备进行数据交换。图4中的OPC服务器由设备供应商提供。OPC技术是以Microsoft的OLE/COM 技术为基础。因此，与其他组件技术一样，它不是防火墙友好的，难以通过防火墙从OPC服务器获取所需的数据。即使在同一局域网内，位于不同计算机上的OPC客户端要连接到OPC服务器都需要经过复杂的DCOM和安全性设置，这增加了系统开发的难度，为此要对OPC服务器的数据进行封装。通过网关(命名为“过程网关”)的形式来为各个系统提供数据。过程网关作为OPC客户端从OPC服务器获取各种过程数据，将这些数据按照一定规则重新组织，并封装在Web Service内，过程网关也从已有的控制系统中获取所需的数据，并以服务的形式暴露给各种应用。
Web已被广泛用于监控系统中，它可以提供统一的人机界面，并且操作简单友好。该系统结构使用Web来建立监控系统，Web监控系统通过过程网关获取现场设备的数据，将这些数据以Web的形式提供给远程用户。远程用户通过PC、PDA、笔记本电脑或手机访问Web页，将各种控制数据送回Web监控系统。Web监控系统再将这些控制数据通过过程网关传送给现场设备，这样就完成了对现场设备的远程监控。
当然，远程的用户也可以通过直接访问过程网关来实现远程的监控。由于Web监控系统以HTML的形式来传送消息和过程网关提供的Web Service的防火墙友好性，因此不管使用那种方式来进行远程监控，都不会受到防火墙的限制。
3.2 过程网关
过程网关是现场设备与监控系统的桥梁，起着重要的数据中转作用，其结构如图5所示。
图5 过程网关与监控应用
(1) 数据获取
过程网关需要获取
来自现场的实时数据，以对工业过程进行及时的监控;
来自其他控制系统的数据，以允许监控应用与这些系统进行数据交互。
目前主要的自动化设备生产厂家，如Rockwell、Siemens等，都提供了对OPC技术支持，通过OPC来获取现场设备的数据。OPC服务器通过各种现场设备的驱动程序，直接从设备中取得数据，再将这些数据提供给OPC客户端。OPC有几种协议，分别有不同用途。例如，OPC客户端通过OPC DA获取设备或SCADA系统的数据;通过OPC AE获取报警和事件信息;通过OPC HDA获取过程控制中的历史数据。
现场控制系统将各种数据存入数据库中，过程网关通过访问这些数据库来获取控制系统的数据。获取这些数据的目的在于使远程控制系统可以与已有的控制系统进行交互，方便地将这些系统集成到新的系统中，使其获得新的生命周期。成熟的中间件技术，如ODBC、ADO等，为数据库的访问提供了简单快捷的方法。
(2) 数据的Web Service封装
通过4.2.1获取的数据需要封装为Web Service，以便Web监控系统和远程用户能够进行调用。在进行数据封装时，按照功能需求确定需要暴露给调用者的接口(类似于编程语言中的函数接口)，然后通过开发工具来开发这些Web Service。这些工具有Microsoft的Visual Studio.NET、IBM的WebSphere、Borland的JBuilder等等。数据封装为Web Service后可以提供WSDL，方便调用者进行调用。
(3) 安全审查
过程网关的某些Web Service可能涉及到保密的数据，因此需要考虑数据传输的安全性，并对客户端的访问进行限制。可用多种方法来提供所需的安全性
采用WS-Security标准[9];
使用SSL进行加密和签名;
使用传输层安全性(Transport Layer Security，TLS)、IPSec[10]等确保数据的安全传输;
使用服务器，如IIS，的身份验证功能;
提供用户的角色定义和权限分配。
(4) 服务调用
开发监控应用时，通过查找操作从本地或服务注册中心检索服务描述，然后进行Web监控系统的开发。而开发完成后的系统可以位于网络的任意位置。Web监控系统与过程网关提供的Web Service进行绑定，通过服务的调用实现数据的交互，由于Web监控系统的数据是通过纯HTTP协议传输的，因此是防火墙友好的。
3.3 Web监控系统
监控系统可以有多种形式。传统的监控系统通过各种组态软件开发，如InTouch,iFix、RSView32等等，但这种监控系统一般是针对集散控制系统或现场总线控制系统的，不利于进行远程的监控。每一种应用都需要相应的运行环境，这将增加用户的投资，如采用基于Web的监控系统，就可以提供统一的人机界面，有利于进行远程监控。
(1) Web监控
远程的用户可以通过浏览器访问现场的运行画面，掌握现场数据。同时可以通过浏览器发送控制命令，控制现场设备的运行。Web监控程序还可以实现数据存档、报表打印、故障报警、统计图表及曲线的显示等[11]。在开发Web监控程序时，首先要获取过程网关提供的WSDL(通过在服务注册中心查找获取，或直接通过过程网关Web Service所在的URL获取)。在开发过程中，Web Service的使用与一般的API函数类似。为了提高性能，应尽量使用异步调用的方式。ASP.NET、JSP等都可以用来进行Web监控程序的开发。由于终端设备的性能差异，需要为手机、PDA等设备开发不同于PC的Web监控程序。
(2) 冲突避免
如果多个用户同时进行监控，可能会导致冲突，因此需要限制同时操作的用户数量。当一个用户访问Web监控系统时，如果此时已经达到了允许的最大访问数，则必须进行等待。此时，允许用户查看各种数据，但屏蔽用户的控制操作。当有其他的用户断开连接后，取消对该用户控制操作的屏蔽，可允许其进行相应的控制。
(3) 权限管理
权限管理为每个用户分配不同的权限，只允许用户进行授权范围内的操作。至少应将用户分为三个级别:管理员:主要负责对Web监控系统的管理和维护，对用户进行管理;高级操作员:可以浏览各种数据，并进行相应的控制操作;一般操作员:只具有浏览数据的权利，不能进行修改。
不同的用户登录系统后具有不同的操作权限，这样可以防止控制操作的滥用，增强系统的安全性。
(4) 日志管理
日志可以记录系统的运行情况以及用户进行的各种操作，特别要记录系统运行中出现的故障。对于用户操作产生的日志需要包括用户名、所进行的操作、时间和IP地址。这样可以掌握用户所进行的各种操作，也便于在出现错误时进行追踪和修复。
5. 如何保证Web服务器安全
不但企业的门户网站被篡改、资料被窃取，而且还成为了病毒与木马的传播者。有些Web管理员采取了一些措施，虽然可以保证门户网站的主页不被篡改，但是却很难避免自己的网站被当作肉鸡，来传播病毒、恶意插件、木马等等。笔者认为，这很大一部分原因是管理员在Web安全防护上太被动。他们只是被动的防御。为了彻底提高Web服务器的安全，笔者认为，Web安全要主动出击。具体的来说，需要做到如下几点。一、在代码编写时就要进行漏洞测试 现在的企业网站做的越来越复杂、功能越来越强。不过这些都不是凭空而来的，是通过代码堆积起来的。如果这个代码只供企业内部使用，那么不会带来多大的安全隐患。但是如果放在互联网上使用的话，则这些为实现特定功能的代码就有可能成为攻击者的目标。笔者举一个简单的例子。在网页中可以嵌入SQL代码。而攻击者就可以利用这些SQL代码来发动攻击，来获取管理员的密码等等破坏性的动作。有时候访问某些网站还需要有某些特定的控件。用户在安装这些控件时，其实就有可能在安装一个木马(这可能访问者与被访问者都没有意识到)。 为此在为网站某个特定功能编写代码时，就要主动出击。从编码的设计到编写、到测试，都需要认识到是否存在着安全的漏洞。笔者在日常过程中，在这方面对于员工提出了很高的要求。各个员工必须对自己所开发的功能负责。至少现在已知的病毒、木马不能够在你所开发的插件中有机可乘。通过这层层把关，就可以提高代码编写的安全性。二、对Web服务器进行持续的监控 冰冻三尺、非一日之寒。这就好像人生病一样，都有一个过程。病毒、木马等等在攻击Web服务器时，也需要一个过程。或者说，在攻击取得成功之前，他们会有一些试探性的动作。如对于一个采取了一定安全措施的Web服务器，从攻击开始到取得成果，至少要有半天的时间。如果Web管理员对服务器进行了全天候的监控。在发现有异常行为时，及早的采取措施，将病毒与木马阻挡在门户之外。这种主动出击的方式，就可以大大的提高Web服务器的安全性。 笔者现在维护的Web服务器有好几十个。现在专门有一个小组，来全天候的监控服务器的访问。平均每分钟都可以监测到一些试探性的攻击行为。其中99%以上的攻击行为，由于服务器已经采取了对应的安全措施，都无功而返。不过每天仍然会遇到一些攻击行为。这些攻击行为可能是针对新的漏洞，或者采取了新的攻击方式。在服务器上原先没有采取对应的安全措施。如果没有及时的发现这种行为，那么他们就很有可能最终实现他们的非法目的。相反，现在及早的发现了他们的攻击手段，那么我们就可以在他们采取进一步行动之前，就在服务器上关掉这扇门，补上这个漏洞。 笔者在这里也建议，企业用户在选择互联网Web服务器提供商的时候，除了考虑性能等因素之外，还要评估服务提供商能否提供全天候的监控机制。在Web安全上主动出击，及时发现攻击者的攻击行为。在他们采取进一步攻击措施之前，就他们消除在萌芽状态。 三、设置蜜罐，将攻击者引向错误的方向 在军队中，有时候会给军人一些伪装，让敌人分不清真伪。其实在跟病毒、木马打交道时，本身就是一场无硝烟的战争。为此对于Web服务器采取一些伪装，也能够将攻击者引向错误的方向。等到供给者发现自己的目标错误时，管理员已经锁定了攻击者，从而可以及早的采取相应的措施。笔者有时候将这种主动出击的行为叫做蜜罐效应。简单的说，就是设置两个服务器。其中一个是真正的服务器，另外一个是蜜罐。现在需要做的是，如何将真正的服务器伪装起来，而将蜜罐推向公众。让攻击者认为蜜罐服务器才是真正的服务器。要做到这一点的话，可能需要从如下几个方面出发。 一是有真有假，难以区分。如果要瞒过攻击者的眼睛，那么蜜罐服务器就不能够做的太假。笔者在做蜜罐服务器的时候，80%以上的内容都是跟真的服务器相同的。只有一些比较机密的信息没有防治在蜜罐服务器上。而且蜜罐服务器所采取的安全措施跟真的服务器事完全相同的。这不但可以提高蜜罐服务器的真实性，而且也可以用来评估真实服务器的安全性。一举两得。 二是需要有意无意的将攻击者引向蜜罐服务器。攻击者在判断一个Web服务器是否值得攻击时，会进行评估。如评估这个网站的流量是否比较高。如果网站的流量不高，那么即使被攻破了，也没有多大的实用价值。攻击者如果没有有利可图的话，不会花这么大的精力在这个网站服务器上面。如果要将攻击者引向这个蜜罐服务器的话，那么就需要提高这个蜜罐服务器的访问量。其实要做到这一点也非常的容易。现在有很多用来交互流量的团队。只要花一点比较小的投资就可以做到这一点。 三是可以故意开一些后门让攻击者来钻。作为Web服务器的管理者，不仅关心自己的服务器是否安全，还要知道自己的服务器有没有被人家盯上。或者说，有没有被攻击的价值。此时管理者就需要知道，自己的服务器一天被攻击了多少次。如果攻击的频率比较高，管理者就高兴、又忧虑。高兴的是自己的服务器价值还蛮大的，被这么多人惦记着。忧虑的是自己的服务器成为了众人攻击的目标。就应该抽取更多的力量来关注服务器的安全。四、专人对Web服务器的安全性进行测试 俗话说，靠人不如靠自己。在Web服务器的攻防战上，这一个原则也适用。笔者建议，如果企业对于Web服务的安全比较高，如网站服务器上有电子商务交易平台，此时最好设置一个专业的团队。他们充当攻击者的角色，对服务器进行安全性的测试。这个专业团队主要执行如下几个任务。 一是测试Web管理团队对攻击行为的反应速度。如可以采用一些现在比较流行的攻击手段，对自己的Web服务器发动攻击。当然这个时间是随机的。预先Web管理团队并不知道。现在要评估的是，Web管理团队在多少时间之内能够发现这种攻击的行为。这也是考验管理团队全天候跟踪的能力。一般来说，这个时间越短越好。应该将这个时间控制在可控的范围之内。即使攻击最后没有成功，Web管理团队也应该及早的发现攻击的行为。毕竟有没有发现、与最终有没有取得成功，是两个不同的概念。 二是要测试服务器的漏洞是否有补上。毕竟大部分的攻击行为，都是针对服务器现有的漏洞所产生的。现在这个专业团队要做的就是，这些已发现的漏洞是否都已经打上了安全补丁或者采取了对应的安全措施。有时候我们都没有发现的漏洞是无能为力，但是对于这些已经存在的漏洞不能够放过。否则的话，也太便宜那些攻击者了。
6. 如何用java实现web服务器的监控
Hyperic HQ集成了强大的监测和管理功能，它有开源版本，您可以直接使用它用来对web服务器进行监控。
如果您想自己写代码实现，Hyperic HQ提供了一个服务器各种性能指标采集的API，这个API包本身提供了各种平台(linux/MAC/window等)的兼容。
7. 在LoadRunner中监控WebSphere，关心的是哪些性能指标
不过TPV本来就并非定位为专业的监控工具，它提供的功能虽简单，但能满足我们分析过程中80%的需求。这个系列将介绍一些WebSphere下的监控和实时分析工具，希望能对TPV是个补充。这次介绍的是Mercury出品的Loadrunner。
“LoadRunner 是一种适用于各种体系架构的自动负载测试工具，通过模拟实际用户的操作行为和实施实时性能监测，来帮助用户排查和发现问题。”我们使用Loadrunner都是作为压力测试工具，单用来作为监控工具有点大材小用。但在做压力测试时，WebSphere的运行情况是重要的观察对象之一。通过在Loadrunner中监控WebSphere，同时监控操作系统的资源占用情况、Web服务器的运行情况，可以对比各个时间点、时间段的应用表现。
8. 如何搭建 Web 前端性能监控系统的
网站性能优化时有很多网站专门做这个东西的你可以付费让他们给你监控网站的运行情况和新增情况和网站在全国各地访问情况有情况还会给你预警
9. 如何监控web服务器主要性能指标
可以使用软件开监控，拓建试试监控宝。会详细记录服务器的数据指标
10. 有什么好用的基于Web的Linux系统监控开源工具
可以用一些命令来实现你说的功能的。
请看下文，请采纳。谢谢。
一、基于命令行的性能监控工具
1.dstat - 多类型资源统计工具
该命令整合了vmstat，iostat和ifstat三种命令。同时增加了新的特性和功能可以让你能及时看到各种的资源使用情况，从而能够使你对比和整合不同的资源使用情况。通过不同颜色和区块布局的界面帮助你能够更加清晰容易的获取信息。它也支持将信息数据导出到cvs格式文件中，从而用其他应用程序打开，或者导入到数据库中
2.atop - 相比top更好的ASCII码体验
这个使用ASCII码显示方式的命令行工具是一个显示所有进程活动的性能监控工具。它可以展示每日的系统日志以进行长期的进程活动分析，并高亮显示过载的系统使用资源。它包含了CPU，内存，交换空间，磁盘和网络层的度量指标。所有这些功能只需在终端运行atop即可。
3.Nmon - 类Unix系统的性能监控
Nmon是Nigel's Monitor缩写，它最早开发用来作为AIX的系统监控工具。如果使用在线模式，可以使用光标键在屏幕上操作实时显示在终端上的监控信息。使用捕捉模式能够将数据保存为CSV格式，方便进一步的处理和图形化展示。
4.slabtop - 显示内核slab缓存信息
这个应用能够显示缓存分配器是如何管理Linux内核中缓存的不同类型的对象。这个命令类似于top命令，区别是它的重点是实时显示内核slab缓存信息。它能够显示按照不同排序条件来排序显示缓存列表。它同时也能够显示一个slab层信息的统计信息的题头。
5.sar - 性能监控和瓶颈检查
sar 命令可以将操作系统上所选的累积活动计数器内容信息输出到标准输出上。其基于计数值和时间间隔参数的审计系统，会按照指定的时间间隔输出指定次数的监控信息。如果时间间隔参数为设置为0，那么sar命令将会显示系统从开机到当时时刻的平均统计信息。有用的命令如下：
# sar -u 2 3
# sar -u -f /var/log/sa/sa05
# sar -P ALL 1 1
# sar -r 1 3
# sar -W 1 3
6.Saidar - 简单的统计监控工具
Saidar是一个简单且轻量的系统信息监控工具。虽然它无法提供大多性能报表，但是它能够通过一个简单明了的方式显示最有用的系统运行状况数据。你可以很容易地看到运行时间、平均负载、CPU、内存、进程、磁盘和网络接口统计信息。
Usage: saidar [-d delay] [-c] [-v] [-h]
-d 设置更新时间（秒）
-c 彩色显示
-v 显示版本号
-h 显示本帮助
7.top - 经典的Linux任务管理工具
作为一个广为人知的Linux工具，top是大多数的类Unix操作系统任务管理器。它可以显示当前正在运行的进程的列表，用户可以按照不同的条件对该列表进行排序。它主要显示了系统进程对CPU和内存的使用状况。top可以快速检查是哪个或哪几个进程挂起了你的系统
8.Sysdig - 系统进程的高级视图
Sysdig是一个能够让系统管理员和开发人员以前所未有方式洞察其系统行为的监控工具。其开发团队希望改善系统级的监控方式，通过提供关于存储，进程，网络和内存子系统的统一有序以及粒度可见的方式来进行错误排查，并可以创建系统活动记录文件以便你可以在任何时间轻松分析。