您的位置:时时app平台注册网站 > 彩世界网址 > 能源分享:服务器基准测量检验工具及应用才干

能源分享:服务器基准测量检验工具及应用才干

2019-09-19 07:35

彩世界网址 1

关于作者:Bill Kleyman,MBA,MISM,一名狂热的技术专家,在网络基础设施管理领域具有丰富的经验。其工程经验包括大型虚拟化环境部署以及商业网络设计与实施。目前他是World Wide Fittings公司的技术总监,该公司在中国,欧洲与美国均设有分支机构。

       相反,剖析帮助你找出你的应用程序在哪里花费了大量的时间,或者消耗了大量的资源。换句话说,基准可以回答“这种执行表现怎么样?”,而剖析可以回答“为什么它会这个样子执行?”

本篇文章将讨论关于服务器基准测试过程中所使用的工具以及技巧。
 
并没有一款单一的基准测试工具就能满足系统管理员所有测量性能的需求。管理员应该使用多个工具来进行基准测试和参数测试,并对比其获得的结果,以保证测试数据的准确性。在这篇文章中,我将概述在基准测试中进行压力测试的作用,并推荐几款测试工程师主流使用的工具。
 
压力基准测试  
压力测试,通常又称之为负载测试,是工程师测试在企业具体环境下的稳定性,但其不是把服务器放在实际生产环境里。

“上下文交换”发生在内核或操作系统核心把进程从一个切换至另一个时。需要避免上下文交换状况发生,每次上下文交换都会使处理器清空L1和L2缓存并重新填装。缓存刷新与重填将浪费宝贵的时间并降低系统性能。

       我们准备在这个章节中讲述两部分内容,基准测试和剖析。我们开始讨论基准测试的原因和对策,然后引入特定的基准测试的标杆(或者尺子)。我们先向你展示如何计划和设计基准测试,为精确的结果做设计,执行基准测试和分析结果。最后,来看看基准测试工具和如何使用它们的例子。

并没有一款单一的基准测试工具就能满足系统管理员所有测量性能的需...

Memory:Committed Bytes——该计数器显示的结果会随时间推移而变化,需要追踪记录以了解某段时间内的负载峰值活动。可以通过追踪Committed Bytes中峰值与谷值所出现的时间了解服务器是如何运行的。需确保可用内存available memory)比提交的内存committed memory)至少多4MB或5%以上。

      最好的策略就是找出最弱的环节,并加强你的应用程序链的组成。这非常有用,如果你不知道什么阻止最优性能,或者以后什么将要阻止最优性能的发挥。

在实际情况下,测试工程师应该测试以独特服务器内容为基础的服务器性能和被执行的应用程序类型。基准测试和指标测试通常是围绕将要在服务器上运行的模拟应用程序来进行作业环境下的压力测试和硬件运行效果评估。目的是为了尽可能最真实地模拟实际环境。这就需要观察用户负载、网络流量测试、处理器利用率和内存分配等等。
 
在模拟环境下测试服务器需要给测试工程师自由选择基础设施资源的空间。通常情况下,不会进行压力测试,而是将服务器放置在现场环境中进行“实际负载”测试。你不必修改生产服务器上的实时数据就能够直接进行测试。而另一方面,你也不需要去改变服务器设置,因为并不过多地依赖于此。
 
但是,请注意,这些测试都是在一个模拟的环境中运行的,因此,其结果可能与现场环境中的服务器测试结果存在较大的差距。测试工程师不应该存在这样的想法,那就是测试环境下的服务器设置与现场环境下的设置是一样的。记住最关键的一点:添加到模拟环境中的任何变量都会影响服务器的性能测试。无论是工程师给服务器增加了1GB的RAM或额外的用户,测试结果都会受到影响。

“科学”的服务器性能基准测试

      3.测试标杆

      在有个大致了解的情况下,让我们转向怎样设计和执行基准测试上来。在我们讨论如何把基准测试做好之前,先让我们看下一些常见的错误,这些错误能导致不能用或者不精确地结果:

  • 使用真实数据大小的子集,例如,当应用程序不得不处理好几百G的数据时,我们只使用其中的1G数据;或者当你准备扩大你的应用程序时,使用现在的数据集
  • 使用错误的数据分布,例如当真实系统数据中的“热点”规则的数据分布(随机生成的数据通常是不切实际的分布)。
  • 使用不切实际的分布参数,例如,假设所有用户的配置文件同样地被浏览。
  • 在多用户应用中,使用单用户场景。
  • 在单台服务器上测试分布式应用。
  • 和真实用户的行为错误地比较,例如web页面上的“思考时间”。真实用户请求并阅读它;他们不会一个接一个没有停顿地点击链接。
  • 在一个循环里执行相同的query语句。真实的query语句是不同的,所以它们会引起缓存未命中的情况。相同的query语句将会在某种级别全部或者部分被缓存。
  • 未能检查错误。如果一个基准测试的结果没有意义-例如,如果一个慢操作突然非常快地完成,那么就该检查错误。你就能测试出在一个SQL查询时,MySQL能多快地探测到语法错误!原则性来说,每次测试完后都应该检查错误日志。
  • 当系统还没有变热的时候,忽略系统是怎样执行的,例如,系统刚刚重启后。有时你需要知道你的服务器重启后,需要多长时间达到承载能力,所以你需要在热启动期间注意观察。相反地,如果你想研究它的正常性能,你需要关心,如果你的测试正好在重启后,许多缓存将被冷冻,那么测试结果将不会反映,在缓存在变热后,在负载下得到的结果。
  • 使用默认的服务设置。

     仅在避免这些错误上就会花费你很长时间来改进你的结果质量。

     对于别的所有事情都是同样的,你应该在尽可能真实的环境中做测试。尽管有时,使用一个稍微不真实的测试也是明智的。例如,假如说你的应用程序在不同的主机上。使用相同的配置执行测试,将会更接近真实情况,但是这样做就会增加更多变量,例如,网络负载多少,多快。在单节点上测试往往很简单,然而在某些情况下,将会更精确。什么时候使用最合适,完全取决于你的判断。

       设计和规划测试

*   *规划测试的第一步就是确定问题和目标。然后,决定是否使用标准的测试还是你自己设计。

      如果你使用标准测试,要保证你选用的测试符合你的需求。例如,不要使用TCP测试你的电子商务系统。用TCP自己的话说,TCP“”。所以对于OLTP系统来说,不是一个合适的测试。

      设计你自己的测试是一个复杂的反复的进程。开始,使用你生产环境中的数据集的快照。确保你能为后来的运行恢复这些数据集。

      然后,你需要在数据里运行query语句。你可以在基本测试里添加单元测试套件,多次执行,但是这和你怎样真实地使用数据库,不大可能匹配。一个比较好的方法是在一个典型的时间框架内,记录你生产环境中的所有的query语句,例如,在峰值负载内的一个小时,或者一整天。如果你在很短的时间框架内,记录了query语句,你可能需要选择几个时间框架。这将会使你覆盖所有系统活动,例如,每周报告query语句,或者在低峰值的时期,执行计划任务。

      你可以在不同等级下记录query语句。例如,如果你需要全栈测试的话,你就可以记录WEB服务器上的HTTP请求。你也可以启用MySQL的查询日志,但是如果你重放查询日志,要确保重新创建单独的线程,代替线性地重放每条query语句。在日志里为每个连接创建一个单独的线程也是非常重要的,避免线程间的query阻塞。查询日志显示了哪个连接执行了哪条query语句。

       即使你还没有构建自己的测试,你可以写下你的测试计划。你可以使测试跑很多遍,你需要重新精确地构建你的测试。也为将来打算。你可能不是下次执行这个测试的人,即使你是,你可能也不太记得你第一次是怎么执行它的。你的计划应该包括测试数据,安装系统的步骤和热启动计划。

     设计一些规范参数和结果的方法,并详细地记录每次执行。你的文档方法可能如电子表格或者笔记那么简单,也可能如定做的数据库那么复杂(但是要记住,你要写一些脚本来帮助分析测试结果,所以没有比打开电子表格和文本文件更容易的方法了)。

     你可能会发现创建一个测试目录,包含每次执行的结果的子目录,会很有用。在相应地的子目录,你可以放结果,配置文件,和每次执行的笔记。如果你的测试比你预想的多,而且你也很感兴趣,无论如何记录额外的数据。错过记录重要的数据总比不需要的数据要好,可能以后你会发现额外数据非常有用。在测试期间尽可能多地记录附加信息,如CPU的使用情况,磁盘I/O,和网络流量统计;SHOW GLOBAL STATUS的计数器,等等。

     ***获得精确结果


     获得精确结果的最好方法是,设计你的测试来回答你想要的问题。你有选择正确的测试吗?你捕捉到你需要的答案的数据了吗?你的测试有错误的标准吗?例如,你有运行一个计算密集型的测试来预测I/O密集型的应用程序的性能吗?

     接着,确保你的测试结果可以重复的。尽量确保你的系统在每次开始执行的时候,是处在相同状态的。如果测试很重要,你应当在每次执行后重启系统。如果你需要一个预热过的服务器,正常来讲,你也应当确保你的系统已经有足够长的预热。例如,如果预热过程包含了随机query查询,那么你的测试结果将会不可重复。

     如果测试改变了测试数据或数据库模式,在每次执行的时候,用快照重新设置它。向一个表中插入一千行记录和向一个表中插入一百万行记录,不会给出相同的的结果。在磁盘上的数据存储和分布也会使结果不可重复。一个方法是确保物理布局相近,做一个快速的格式和文件拷贝分区。

     当心额外负载,优化和监控系统,详细记录日志,计划任务,以及其它因素能使你的结果发生偏移。

     

 

Memory:Page Faults/sec——该计数器记录某应用程序尝试从被标识为“不存在not present)”的虚拟内存位置读取数据时产生的页面错误。大多数情况下,0是最理想的测量结果。任何高于0的测量值都意味着响应时间的延迟。记住,Memory:Page Faults/sec测量值为硬页面错误和软页面错误总和。硬页面错误发生在当某个文件需要从硬盘而不是虚拟内存中获取时。与此相反,软页面错误发生在某已解决的页面错误,数据在物理内存的其他位置被找到,虽然有中断处理器,但对性能的影响微乎其微。

    测试什么?

    在你开始基准测试之前,甚至是在你设计测试之前,你需要确定你的目标。你的目标将会决定你的工具和技术,以便得到精确地有意义的结果。用问题来设计你的目标,比如“CPU是多的好吗?”或者“新的索引是不是比现在的索引执行的更快?”

    它不可能是显而易见的,这就需要你用不同的方法来测试不同的事情,例如:延迟和吞吐量需要不同的基准测试。

    考虑以下几个量度和它们如何完善你的性能目标:

   单位时间的交易量

    这是一个经典的历史为基准的数据库应用程序。标准化测试,如TPC-C标准(见)被广泛引用,很多数据库提供商,工作非常努力以使它们工作的好。这些基准测试在线处理(OLTP)性能,这些基准最适合多用户交易应用程序。通常的测量单位是每秒交易量。

    吞吐量这个词通常的意思是等同于单位时间内的交易量(或者工作的其它单元)。

    响应时间或延迟 

    这测量了一个任务需要的总时间。依赖你的应用,你可能需要测量毫秒,秒或者分钟。从这里你可以得出平均响应时间,最小响应时间和最大响应时间。

    最大响应时间是很少有用的度量,因为基准测试运行时间越长,可能最大响应时间越大。它并不总是能重复的,这就可能会在运行的过程中拉大差距。正是因为这个原因,很多人使用百分比的响应时间。例如,如果95%的响应时间是5毫秒,你就可以知道任务可以在总时间的95%内少于5毫秒完成。

    画出基准测试的结果,为图形或者线性图(例如,平均值和95%百分比)或者是散列图,将是非常有帮助的,因为这样你就可以看到结果的分布情况。通过这些图形,可以看出在长时间运行过程中,基准测试是怎样执行的。

   假设你的系统每小时做一分钟检测。在检测期间,系统“抛锚”,没有交易完成。95%的响应时间不会显示峰值,所以结果会掩盖这个问题。然而,一个图形会显示响应时间内的周期性峰值。图2-1会阐述这点。

   图2-1显示了每分钟的交易量。线条显示了象征性的超过平均值的峰值。第一个峰值是因为服务器的缓存被冷冻了,另一个峰值显示了服务器刷新脏页稳定性到磁盘花费的时间。如果没有图形我们很难看到这些差异。

   稳定性

   对于系统来说,稳定性测试非常重要,因为系统需要在变化的工作负载下保持性能。

   “在一个变化的工作负载下保持性能”是一个很抽象的概念。性能是可以被度量的,例如,吞吐量和响应时间;工作负载随着数据库大小,当前连接数,或者硬件不同,可能会存在差异。

    稳定性测试,对于评估系统承载能力来说是好的,因为它能展示出你的应用中的薄弱环节,而在其它基准测试中不会展示。

彩世界网址 2

图2-1 30分钟运行的结果

     例如,在单链接(不好的测试策略)的情况下做响应时间测试,你设计的系统性能良好;但是在任何等级的并发下,你应用可能会表现糟糕。一个测试关注的是在不断增加的连接下的持续响应时间,这样才可以看到设计的瑕疵。

     有一些活动,例如搜集颗粒数据创建总结性数据表的周期性批量作业,仅仅需要快速响应时间。单纯地测试响应时间是好的,但是也要关心他们和其它活动是怎么交互(相互影响)的。批量作业可能会导致交互的query语句表现较差,反之亦然。

      并发

      并发是很重要的,但是很多时候都被滥用和被错误地衡量。例如,有一种很流行的说法,有多少用户在同时浏览网站。然而,HTTP是无状态的,大多数用户只是简单地阅读浏览器展示的内容,所以这并不能转化为web服务器的并发。同样地,在web服务器上的并发并不一定转化到数据库服务器上。有直接关联的就是你的会话存储机制能处理多少数据。一个更精确的测试web服务器的并发的方法是在峰值的时候,用户每秒请求的次数。

       你也可以在应用程序的不同地方测试并发。在web服务器上的并发越高,可能引起更高的数据库并发等级。但是语言和工具套件可能影响它。例如,Java的连接池可能会比持续连接的PHP,会降低MySQL服务器的并发连接。

      更重要的是在一个给定时间内运行query语句的并发数量。一个很好的设计应用程序可能会打开MySQL服务器的数以百计的并发,但是其中的一少部分应该会同时执行query语句。这样,一个“50,000用户同时在线”的web站点,可能在MySQL服务器上只需要10~15个同时执行query语句。

      换句话说,你要真正关心的基准测试就是工作并发,或者线程数量,或者同时工作连接。测试当并发增加的时候,性能掉下来多少。如果是这样的话,你的应用程序可能就无法处理高负载下的峰值。

      你也需要确保性能不会很快地降下来,或者设计应用程序,这样就不会在应用程序的各个部分产生不能处理的高并发了。在通常情况下,你要设计限制MySQL服务器的并发,如应用队列。

      并发不能完全等同于响应时间和稳定性:它并不是一个结果,而是你怎样建立基准测试的一个属性。你应该在不同的并发水平下测试应用程序的性能,而不是测试你的应用程序的能达到的并发。

      总之,你应该测试对用户来说重要的东西。测试衡量性能,但是“性能”对不同的人意味着不同的东西。收集一些关于系统应当怎样测量的需求(正式或非正式的),能接受的响应时间,期望的并发类型,等等。然后,尝试设计你的测试来解释所有的需求,而不是“井底之蛙”排除其他东西关注某项东西。

...

1. 为什么需要基准?

      很多大中型的MySQL部署有专门的标杆用在基准测试里。然而,每个开发者和DBA也应该熟悉基础的基准测试和操作,因为它们非常有用。下面是基准测试可以帮助你的一些事情:

  •  测量你的应用程序当前是怎样执行的。如果你不知道你的应用程序当前执行多快,你不能确定哪些改变有用。你还可以用历史基准结果,来诊断比不能预期的问题。
  • 证实你系统的可扩充性。你可以用基准测试来模仿比你的生产环境能处理的多得多的负载,比如成千上百倍的增加用户。
  • 计划增长。基准测试能帮助你评估将来你的预计负荷需要多少硬件,网络容量和其它资源。这能在升级或者大量应用程序改变的时候,帮助减少风险。
  • 测试你的应用程序在一个变化的环境里的承受能力。例如,你可以找出你的应用程序,在并发下不定时的峰值或者不同的服务器的配置的情况下,是怎样执行的,或者你可以看到在不同的数据分布下它是怎样处理的。
  • 测试不同的硬件、软件和操作系统配置。对于你的系统来说,是RAID5还是RAID10更好?当你从ATA磁盘切换到SAN存储的时候,随机写的性能是怎样变化的?2.4的Linux内核比2.6的更好吗?MySQL的升级有助于提高性能吗?对于你的数据,不同的存储引擎有影响吗?你可以用不同的基准来回答这些问题。

      对于其他目的,你也可以用基准测试,例如,为你的应用程序创建一个单元测试套件,但是在这里我们仅仅关注性能相关方面。

Thread:% Processor Time:Inetinfo =>Thread #——测量Inetinfo进程所属线程消耗的处理器时间总量。

    2.基准策略

     有两条基本的基准测试策略:你可以对应用程序作为一个整体,或者隔离MySQL,用基准问题测试。这两种策略分别以全栈和单组件基准测试闻名。有以下几点测试整个应用程序而不仅仅是MySQL:

  • 你测试整个应用程序,包括web服务,应用程序代码和数据库。这非常有用,因为你不仅仅关注MySQL的性能,更关心整个应用程序。
  • MySQL并不总是应用的瓶颈,全站基准测试可以证明这一点。
  • 只有测试整个应用,你才能知道每个部分的缓存行为。
  • 基准测试在某种程度上是好的,因为它反映了你的应用的真正行为,当你单独测试某个模块的时候,很难发现的行为。

   另一方面,应用程序基准测试很难创建,甚至很难正确地安装。如果你的基准测试设计的很糟糕,你就会得出错误的结论,因为结果不能反映真实情况。

   然而,有时你不想了解整个应用。在最初阶段,可能你只想了解MySQL基准测试。下面的基准测试是有用的:

  • 你想比较不同的模式或者query语句
  • 你想测试应用中一个特殊的问题
  • 相比长篇大论的基准测试来说,你更倾向短的基准测试,能向你展示标记和测量改变的快的“循环时间”。

    当你在真实数据集的环境中,一次又一次的重复你的应用query语句时,基准测试MySQL是非常有用的。数据集本身和数据集的大小都必须是真实的。如果可能的话,做一个生产环境中的数据快照。

    不幸的是,建立一个真实的基准,是非常复杂和耗时的;如果你能得到生产环境中的数据集的复制品,算你走运。当然,这有可能是不可行的。比如,你可能开发了一个新的应用程序,只有少数的用户和数据。如果你想知道,如果它变得庞大时,将会有什么问题发生,除了模拟更大应用数据和负载,你没得选择。

1、观察:我们假设系统管理员购买了一台服务器,现在看看它的最佳性能。第一步是确定服务器预期任务。其将作为一个虚拟平台还是运行一个专门的应用程序?确定这些问题之后,就可以开始基准测试了。切记,测量标准和基准测试将根据测试内容和使用的设备而有所变化。例如,如果作为数据库系统可能会强调处理器测试,而用于网络服务系统的话可能会突出网络性能。

      基准测试和剖析是两条基本的找出瓶颈的方法。它们是有关联的,但是它们又不完全相同。基准测试你的系统的性能。这将有助于确定系统的承受能力,向你展示哪些改变有用哪些没用,或者显示在不同的数据下你的应用程序的性能。

内存分配与一般内存设置

       剩下的章节讲述如何优化应用程序和MySQL。我们将会详细地展示我们已经应用于生产帮助分析应用程序的性能,真实的优化代码。我们也会展示怎样记录MySQL的query语句,分析日志,使用MySQL的状态计数器,以及用来查看MySQL和你的query语句怎样做的其它工具。

2、假设:在这个步骤,工程师设定一个基准目标。假设什么或者测试需要完成什么?简单地进行一个度量测试将得出一些试验结果,但是没有方向或明确的目标的话,这些结果可能是无用的。为测试创建一个基本的目标,并且所有的测试方法都围绕这个目标。例如,工程师可能会设法测试其占用的内存以让应用程序处于最佳运行状态。他或她可能因此推测,给定“X”内存大小可以达到最佳工作负载。这可以立足于以前的研究,供应商提供的基准或其他的来源。确保你的假设是可测试的。也就是说,不要提出一个只是基于数据的而基准测试却无法证实的假设。

      有些时候,我们需要优化MySQL。那我们要对MySQL进行哪些改进呢?一条特殊的query?数据库模式?服务器硬件?唯一的办法是测量你的系统在做什么,在各种条件下测量它的性能。这就是我们下面要学习的。

Memory::Available Bytes——该计数器显示操作系统可使用物理内存与服务器进程及应用程序运行所需内存总和比较的结果。

我们都使用Windows任务管理器,看看某个应用程序或进程影响着我们的内存或CPU使用率。这是度量测试,尽管在一个非常简单的水平。与Windows任务管理器的问题是,它并没有说明如何一台机器的真正效果。分层缓存子系统,自定义应用程序,定制硬件,海量数据库,非统一内存和同时多线程处理器已经作出了现代计算系统的性能产生巨大影响。

服务器性能是不能凭主观意识去判定的,即使一台服务器状态良好,IT工程师们也需要一台机器测量,明确衡量标准,和衡量其性能。几乎在每一种情况下,基准都是用来测量和监测服务器性能的。本文提供了一个服务器指标和基准测试的概述。

3、预测:接下来,对服务器基准测试做一个大体预测。假设该设备将被作为一个专门的应用服务器。系统管理员能够预测,为工作负载增加额外的核心,设备性能将提升,同样,应用程序的性能也将会改善。在某些情况下,工程师甚至可以预测改善的比例,并希望通过基准测试进行验证。

关键在于意识到每个环境都是独一无二的,都有属于自己的特定需求集。利用如PerfMon一类的工具进行指标测试,是个持续的过程,其中涉及大量参数,这些参数都可以在很大程度上影响测试数据的结果。通过规划测试方案并遵循严谨的科学方法,测试管理员可以更加准确地评估硬件与软件的运行状况。如果进展顺利,一个好的基准测试分析所提供的信息对改进服务器架构与性能可以起到很大的帮助。

基准测试线程与进程监控

在利用PerfMon进行服务器基准测试时,可利用以下计数器来验证内存分配是否影响到服务器整体性能:

测试工程师应该可以通过以上这些分组,获得可靠的基准测试结果,并利用这些数值对整个服务器环境加以改善优化。

6、推论和结论:进行测试并确认应用程序的实际性能以及给定预计资源或设置后的性能。例如,在只有一半数量的预期核心后,确定应用程序的最佳运行效果。从这点起,确定核心与其他当前变量(所需的内存大小、当前运行的应用程序数量、软件升级/服务包等)结合给服务器提供的最佳性能。注意,任何变量的改变都需要进一步实验。

  • 内存管理
  • 网络容量
  • 处理器性能
  • 磁盘优化

Process:Thread Count:Inetinfo——记录由Inetinfo进程所创建的线程数并显示最新数值。

服务器测量标准和基准测试技术并非新的概念,其实早在许多年前就已提出来,并用于测试早期的一些计算机系统。但是,设计基准测试以衡量服务器性能其本身就是一门完整的科学。我们的想法是这样的:对服务器的预期工作负载执行一个模拟运行过程。在执行运行过程并计时。然后在不同的系统上执行完全相同的测试并对比结果。

服务器性能通常不会由一个因素的影响,因此服务器的性能进行测试应类似于一个科学实验位。最好的方式来进行服务器的性能测试之一是利用在分析的科学方法。这个方法是一个六步的过程,包括观察,初步假设,预测,测试/控制和测试的最终结果即一个理论和结论。那么结论是支持最好的证据收集在运行测试集。无论是最佳和最小的服务器性能水平也得到了同样的证据,是在这个过程中收集的。

3、留心基准测试服务提供商。如果你正计划将基准和指标测试进行外包,确保你已经做了足够详尽的调查。很多时候,即使是最著名的咨询公司也会无视或不遵循基本的科学方法。这包括但不限于,小型服务器与应用程序样本大小,缺乏变量控制,结果的重复性有限以及软件硬件上的数值偏差。查找极端数值,如SQL Server测试后发现数值比预期的还高,这很可能与测试采用的硬件有关。模糊的硬件需求定义也是个陷阱。如果产商列出硬件却没有提供任何详细清单——如双核CPU,4GB内存,512MB显卡——你需要对此额外留心。在弄清基准测试的微小细节时,每个变量都很重要。在这种情况下,该用那种类型的处理器?需要使用哪种型号的内存以及何种型号的显卡?所有这些细节都大有不同。

在服务器环境中完成的任何测试,相关基准测试与指标评价报告通常都会附带一些注意事项。

服务器性能基准测试的概念十分简单,但如何进行基准测试并获得有价值的数据,就是另外一回事了。微软的Performance MonitorPerfMon),是款十分灵活的基准测试工具,但其内置的供各种丰富计数器和设置参数可能让测试变得更加复杂,甚至使测试结果难以解释。通过本文,我们将介绍PerfMon在基准测试中最常用的计数器,并深入了解它们是如何影响实际测试的。

原文:

注意留心处理器的几个重要计数器,尤其在当你尝试最大化每个CPU的线程数时。留心“上下文交换context switches)”发生的次数。

由于服务器体系结构先进,它变得更加难以在不同的计算机系统通过简单地分析确定其性能,因此,度量和基准测试开始出现了。

5、测试:变量都设置好之后,现在开始进行测试。从基准线开始进行测试(已知的起点),并有系统地调整服务器设置。每个测试序列都会有一个结果,记录结果以便以后引用。在这种情况下,一个测试序列可看做是一次硬件设置更改。每应用一次新的设置,都必须重新进行测试并记录结果。一旦有足够的运行周期,工程师应该有一份完整的数据以完成他们的推论。

4、环境控制:变量设置。例如,可能要给服务器分配一些核心。此时,管理员每次应只更改一个设置,直到他或她能够接受在此基础上的性能变化。工程师可能需要给服务器设置为6GB的内存,并测试其与其他设备相互配合的情况(CPU、影像、硬盘以及相关联的设备)。设置不同的变量,包括修改处理器设置,但其他设置都处于最初状态。

2、永远不要只关注一项测试指数。在进行服务器基准测试时,因尽可能的涉及多种组件。不要只关注其中一项因素,如CPU速度。关注服务器中各项组件的行为,可以让工程师更为全面的了解整体系统在不同环境下是如何运行,这样可以便于在未来快速定位与修正性能问题。

了解基准测试所面临的挑战

Thread:Context Switches:sec:Inetinfo =>Thread#——测量每处理器或线程池的最大线程数。监控这个计数器十分重要,可以防止因过多上下文交换而的造成内存损失,如果内存损失过高,增加线程的优势也将不复存在,这里存在一个平衡点,一旦打破平衡,系统性能将不会提升,反而会降低。

不幸的是,进程与服务器指标有着异常广泛的内容——我们无法在此文中一一例举。尽管如此,就大部分情况下,系统性能和指标测试可被划分为以下几类:

如果给某个应用程序分配过多内存,可能影响到服务器上其它进程的性能。实际上,内存利用不当将给整体系统性能带来消极影响。

基准测试的测量与分析

1、警惕供应商所提供的基准测试结果。供应商们倾向于将产品按一般照行业标准进行基准测试。这意味着官方提供的基准测试文档或白皮书可能不适用你所处的环境。例如,我们假设某IT经理计划采购一款软件,以实现将用户数据信息库存储在服务器上。有参数显示该软件在Windows Server 2008上运行的稳定,而且响应也很迅速。虽然这听起来不错,但未必适合当前的环境。举个例子,如果该指标是供应商在一台独立并增强配置的服务器上进行测试的结果,而你的环境却是共享宿主资源的虚拟机,会发生什么情况呢?记住,供应商的目的是把软件卖给你,所以他们会利用一些“作弊”手段,让基准测试的分数看起来很美好。这样做可以提高书面上的数据,但可能会让事情在真实环境中变得更糟。虽然大型硬件和软件供应商不屑于此,但某些规模较小的销售公司确实会在这些数据上做些手脚。举例来说,某台硬件号称能够满足通过WAN实现VPN连接,并能获得较理想的速度,因为系统已经经过基准测试并进行了优化。但在实际部署上线后,该设备在速度性能上却明显下降了20%-30%。所以,对那些依赖性高,承载关键任务的设备或软件,需要进行严谨和尽职的调查。

了解服务器的度量和基准测试

本文由时时app平台注册网站发布于彩世界网址,转载请注明出处:能源分享:服务器基准测量检验工具及应用才干

关键词: