&&>&&&&>&&
重庆移动利用监控工具优化网络　 来源：人民邮电报-中国信息产业网　 作者：李媛婧 谭文贵为提升网络运维质量和效率，日前，重庆移动充分利用监控工具的技术功能特性，开展专题优化工作。实现了“全网设备按机房节点监控，关键业务按业务逻辑流程监控”的目标，所有监控界面均设为可视化展示。
本次专题优化工作主要体现在以下三方面：首先，全网设备按机房节点监控。在本次优化专题中，将支撑网的全网设备按照机房位置进行分别展示，实现全部核心机房最终在一张总图上展示，一旦有告警将在总图上进行颜色区别，并发出警告声进行提醒。运维人员将根据大图告警展示，可点击进相应的机房进行告警查看。其次，关键业务按业务逻辑流程监控。在本次优化专题中，根据业支系统的关键业务进行梳理，目前梳理出3条核心逻辑业务链路，分别是：外网VPN到4A链路、集团一级链路、网厅门户链路。通过将梳理出的逻辑链路中出现的网络设备全部展现在监控平面上，一旦出现由于链路导致业务异常，便可快速查找相应的链路问题。由于根据业务逻辑展示，所以在展示的时候是跨多机房展示，运维人员可以快速判定业务出现问题的链路在哪个机房，快速定位。最后，增加首页重要性能指标TOP10展示功能。展示的重要指标有：CPU利用率、设备响应时间、内存利用率、接口输出带宽利用率、设备不可达比例、接口输入带宽利用率。运维人员在首页就能清晰准确地掌握全网网络设备的性能情况，为性能问题定位和后期性能优化提供数据支撑。
通过网络监控新工具专题优化工作，运维人员每日登录监控平台即可掌握全网运行状态，既准确又高效，保障了基础网络平台的稳定。从前期实施效果来看，运维人员初步评估，运维效率提升30%，故障原因定位效率提升50%。关键词：链路 运维 重庆移动 网络设备 快速判定　　【摘要】 对LTE无线网络优化现阶段所主要涉及的接入类、保持类、移动类、业务类和服务完整性类五大类关键性能指标的含义、" />
免费阅读期刊
论文发表、论文指导
周一至周五
9：00&22：00
LTE无线网络优化关键性能指标的分析与研究
2015年21期目录
&&&&&&本期共收录文章20篇
　　【摘要】 对LTE无线网络优化现阶段所主要涉及的接入类、保持类、移动类、业务类和服务完整性类五大类关键性能指标的含义、计算公式、相关信令流程和影响因素等进行了分析与研究，对深入研究LTE无线网络优化技术和获得高质量的网络性能具有指导作用。【关键词】 关键性能指标 网络优化 无线网络Analysis and Research on KPI of LTE Wireless Network Optimization 中国论文网 /1/view-7205784.htm　　Gao Zhou-jun1，Cui Yan-song2（1.Shandong Post and Telecom Engineering CO.LTD， Shandong .Tianjin Vocational Institute， Tianjin 300410） 　　Abstract Analysis and research are carried out on the implication， formulas， signaling procedures concerned and influence factors 　　of five categories of KPIs of LTE wireless network optimization at the present， including accessing KPI， maintaining KPI， mobile KPI， 　　services KPI and service integrity KPI. Guiding function is played in researching in-depth on LTE wireless network optimization and 　　then achieving high-quality network performance. 　　Keyword KPI； Network Optimization； Wireless Network 　　前言 　　LTE网络同以往的2G、3G网络相比，有着不同的体系架构、组网方式、关键技术等，因而其关键性能指标（KPI）和无线网络优化方法也有所不同。移动通信网络的关键性能指标是对网络质量的最直观反映，是无线网络优化工程最主要的工作依据。分析与研究LTE网络的KPI对深入研究其无线网络优化技术和获得高质量的网络性能具有指导作用。 　　与无线网络优化相关的LTE网络KPI分为无线网络KPI和服务KPI两大类，前者关注于无线网络性能，后者更关注用户体验。这两大类KPI又可分为若干小类，具体如表1所示。下面对表中现阶段所涉及的KPI进行具体分析。 　　一、接入类KPI 　　接入类KPI反映了用户成功接入到网络中并发起业务的概率，主要包括RRC建立和E-RAB建立。接入KPI又分为小区级和簇级，其中簇级KPI是通过同一簇中所有小区的计数和集得到的。 　　1.1 RRC建立成功率 　　RRC连接建立（RRC Connection Setup）是指用户设备与基站高层（RRC层）建立的连接，是用户能够成功接入网络、实现业务的第一个关键性步骤，因此，RRC连接建立成功率直接影响了用户使用网络的业务体验感受。RRC连接建立成功的信令流程如图1所示。 　　可能导致RRC连接建立失败的原因有： 　　空口信号质量过差； 　　定时、功率控制等参数配置不当； 　　有强的干扰； 　　网络拥塞； 　　设备故障。 　　1.2 E-RAB建立成功率 　　E-RAB是承载用户业务数据的接入层承载，E-RAB连接建立指用户设备与核心网侧的MME/SGW设备之间建立的连接。E-RAB在小区内的建立成功率，直接反映了小区为用户提供E-RAB承载建立的能力。 　　可能导致E-RAB连接建立失败的原因有： 　　无线资源不足； 　　因干扰、弱覆盖等导致的无线层问题； 　　因干扰、弱覆盖等导致的未收到用户设备响应问题； 　　因故障、参数设置不当等导致的传输层问题； 　　因参数设置不当、对用户开卡限制等核心网侧问题。 　　二、保持类KPI 　　保持类KPI用来评估网络中处于连接态的用户保持业务持续性的能力，也分为小区级和簇级。这是一类非常重要的KPI，表征系统是否可以将服务质量维持在某个水平上。其中，最重要的是业务掉话率KPI。 　　业务掉话率KPI是通过监控某种业务E-RAB异常释放比率计算得到的。 　　E-RAB释放过程是用户接入层业务承载资源的释放过程，反映了小区为用户释放接入层业务数据承载资源的能力。E-RAB正常释放和异常释放的几种情况的信令流程分别如图2和图3所示。由图可见，每个E-RAB都跟QoS信息紧密关联。 　　可能导致E-RAB异常释放的原因有： 　　网络拥塞；
　　因干扰、弱覆盖等导致的无线层问题； 　　切换流程失败； 　　因故障、参数设置不当等导致的传输层问题； 　　因参数设置不当等核心网侧问题。 　　三、移动类KPI 　　移动类KPI用来评估E-UTRAN网络的移动性能，它直接体现了用户体验的好坏。根据切换类型可分为：同基站同频切换、同基站异频切换和异基站间切换。其中现阶段最重要的KPI是同频切换出成功率。 　　图4所示为同基站内基于X2接口切换的信令流程。 　　LTE系统中影响切换成功率的原因有： 　　无线环境（RSRP、SINR等指标）差； 　　PCI冲突（如源小区里有多个PCI相同的情况）； 　　切换参数设置不当。 　　四、业务类KPI 　　业务类KPI用来测量整个LTE无线网络的业务量情况。此类KPI中最主要的有：无线承载数和上/下行业务数据量。业务量KPI的影响因素比较复杂，包括网络架构、组网方式、关键技术、业务类型等。 　　4.1无线承载数 　　表2 九种QCI 　　无线承载数可以用来评估小区或者簇建立的平均承载数，由十个子KPI组成：一个总无线承载个数和对应九个服务质量等级标识（QCI）的承载个数。九种QCI对应的典型业务及特性如表2所示。 　　4.2上/下行业务数据量 　　上/下行业务数据量（单位：bit）的相关统计在PDCP层执行，也由十个子KPI组成：一个为总上/下行业务数据量和九个对应九个QCI下的业务数据量。 　　五、服务完整性类KPI 　　此类KPI用来表征E-UTRAN中终端用户的服务质量情况，分为小区级和簇级。其中，最重要的是上/下行业务平均吞吐率，它包括九个子KPI，分别对应九个QCI。上/下行业务平均吞吐率的影响因素有：系统帧配置（TDD-LTE）、空间复用的层数、调制方式、编码效率等。 　　六、结语 　　自2013年12月和2014年6月工信部分别正式发放了TDD-LTE和FDD LTE牌照之日起，4G LTE网络建设和网络优化一直在紧锣密鼓的进行中。分析与研究LTE网络的KPI，对深入研究其无线网络优化技术和获得高质量的网络性能具有指导作用。 　　参考文献 　　[1] 李峻洋等.LTE无线网络优化关键性能指标研究[J].邮电设计技术，2014（4）：83-86. 　　[2] 何 凌.LTE无线网络优化关键性能指标探讨[J].网络安全技术与应用，2014（8）：48，50. 　　[3] 李正茂，王晓云.TD-LTE应用与实践[M].北京：人民邮电出版社，9. 　　[4] Jari Ryynanen，张文果.LTE网络规划和优化的特点及路测实例[J].电信网技术，2011（5）：88-91.
转载请注明来源。原文地址：
【xzbu】郑重声明：本网站资源、信息来源于网络，完全免费共享，仅供学习和研究使用，版权和著作权归原作者所有，如有不愿意被转载的情况，请通知我们删除已转载的信息。
xzbu发布此信息目的在于传播更多信息，与本网站立场无关。xzbu不保证该信息（包括但不限于文字、数据及图表）准确性、真实性、完整性等。程序有很多，你做论坛可以选择DZ，博客...
谈到东莞，我想很多人对2013东莞扫黄记...
香港idc机房有香港新世界机房...
天气转凉，但小编为广大网友排忧解难...
经常有人问网通服务器托管和联通服务...
welcome to nginx!字面解释欢迎Nginx...
24小时客服热线：&&景安企业QQ：&29561人阅读
LoadRunner性能测试（23）
浅谈软件性能测试中关键指标的监控与分析
一、软件性能测试需要监控哪些关键指标？
软件性能测试的目的主要有以下三点：
?& 评价系统当前性能，判断系统是否满足预期的性能需求。
?& 寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。
?& 判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。
而对于用户来说，则最关注的是当前系统：
?& 是否满足上线性能要求？
?& 系统极限承载如何？
?& 系统稳定性如何？
& & & &因此，针对以上性能测试的目的以及用户的关注点，要达到以上目的并回答用户的关注点，就必须首先执行性能测试并明确需要收集、监控哪些关键指标，通常情况下，性能测试监控指标主要分为：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。
性能测试监控关键指标说明：
?& 资源指标
CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。
内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。
磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。
网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。
?& 系统指标：
并发用户数：某一物理时刻同时向系统提交请求的用户数。
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。
平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。
事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，如下图所示：
单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般以事务成功率来度量，计算公式如下所示：
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。
二、如何监控关键指标？
?& 资源指标监控
主要针对各服务器系统平台（Windows、Linux、Unix等）资源使用进行监控。
可以使用系统自带的性能监控工具或者第三方工具进行监控，如Windows系统自带的“系统性能监视器”，如下图所示：
Linux系统下，free、vmstat、sar、iostat等命令监控内存、CPU、磁盘IO等的使用情况，如下图所示：
第三方监控工具，如spotlight，spotlight是quest公司开发的一款可以针对多种系统平台及数据库进行监控的可视化工具，如下图所示：
Nmon是IBM提供的监控AIX和Linux系统资源的免费工具，可以对收集的资源信息通过Excel进行统计分析形成直观的统计图，如下图所示：
?& 系统指标监控
系统指标监控一般通过性能测试工具（如LoadRunner、Jmeter等）以图形化方式监控，如下图所示，并发用户数与平均响应时间关系图。
三、如何分析监控的关键指标？
通过第二部分监控收集到性能度量关键指标，如何进行分析，并判断是否存在性能瓶颈呢？以下主要从资源指标与系统指标两方面进行阐述。
?& &资源指标分析
判断CPU是否是瓶颈的方法：一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈，比如Linux总是试图要CPU尽可能的繁忙，使得任务的吞吐量最大化，即CPU尽可能最大化使用。因此，一般判断CPU为瓶颈，主要从两方面：一是CPU空闲持续为0，二是运行队列大于CPU核数（经验&#倍），即可判定存在瓶颈，对于CPU高消耗主要由什么引起的，可能是应用程序不合理造成，也可能是硬件资源不足，需要具体问题具体分析，比如问题SQL语句引起，则需要跟踪并优化引起CPU使用过高的SQL语句。
判断内存是否是瓶颈的方法：一般至少有10%可用内存，内存使用率可接受上限为85%。当空闲内存变小时，系统开始频繁地调动磁盘页面文件，空闲内存过小可能是内存不足或内存泄漏引起，需要根据系统实际情况监控分析。
判断磁盘I/O是否是瓶颈的方法：磁盘I/O对于数据库服务器、文件服务器、流媒体服务器系统来说，更容易成为瓶颈，一般从以下几个方面对磁盘I/O进行分析判断：
①&&& 计算每磁盘I/O数
每磁盘I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈，每磁盘I/O计算方法如下表：
(Reads+Writes)/Numbers of Disks
(Reads+2*Writes)/2
[Reads+(4*Writes)] /Numbers of Disks
[Reads+(2*Writes)] /Numbers of Disks
②&&& 监控磁盘读写，如果磁盘长时间进行大数据量读写操作，且cpu等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读写性能。
判断网络带宽是否是瓶颈的方法：判断网络带宽是否是系统运行性能瓶颈的首要条件是网络带宽是否会影响系统交易执行性能。例如：减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；或者增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高。
在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过ping应用服务器IP或网关IP，如果出现网络严重延迟或丢包，则说明网络不稳定，需要检查网络。
通过对资源指标四个指标的分析，实际上各个方面都是互相依赖的，不能孤立的单从某个方面进行排查。当一个方面出现性能问题时，往往会引发其他方面的性能问题，例如，大量的磁盘读写势必消耗CPU和IO资源，而内存的不足会导致频繁地进行内存页写入磁盘、磁盘写到内存的操作，造成磁盘IO瓶颈，同时，大量的网络流量也会造成CPU过载，所以，在分析性能问题时，需要从各个方面进行考虑。
?& 系统指标分析
并发用户数：系统能够支持的用户数是系统容量的重要标志，并发用户数用于度量系统在高并发量访问下，系统的并行处理能力，一般如果系统中存在死锁、资源争用，在并发访问下，由于请求处于队列等待中，系统响应就会随着时间变慢。
一般情况下，选用高吞吐量、高数据库I/O、高商业风险的业务功能进行并发用户访问测试。
判断系统能够承受的最大并发用户数，通常以满足以下条件为准：
1、业务功能操作平均响应时间在合理范围之内
2、事务成功率在合理范围之内
3、 系统运行无故障（无异常宕机）
4、系统资源指标使用在合理范围内
平均响应时间：对于客户端用户来说，最直观的体验就是访问该页面快或者慢，即响应时间的长短。比如在持续并发性能测试过程中，客户感知访问应用很慢，监控到的平均响应时间也逐渐变长，这时就需要先借助于监控到的资源指标，首先排除资源方面的限制因素，再从应用本身进行定位，如可以采用页面细分工具（如httpwatch、Loadrunner Anaysis中的页面组件细分）分析响应比较慢的页面。
事务成功率、超时出错率：事务成功率越高，则表明系统处理能力越大；而失败事务主要由于系统响应慢，导致访问业务功能超时，或者系统业务功能异常，不能正常访问等，需要根据事务错误提示信息，具体分析。
综上所述，软件性能测试是执行、监控—〉分析—〉调优不断进行的过程，即监控是为分析提供更多的参考数据，分析是为了进行调优，调优是解决当前系统存在的性能瓶颈，为用户提供更好、更快的客户体验。由于分析、调优需要根据具体问题进行具体分析，本文未做过多说明，只对通用的关键指标进行监控分析，建议在实际工作中可从资源指标与系统指标两个方面，层层检测、步步排查，性能问题就无处藏身，一旦找到出现问题的原因，性能问题也就迎刃而解！
【注】文章中有部分来自网络或其它书籍中的资料进行了综合整理。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：289681次
积分：3983
积分：3983
排名：第6279名
原创：143篇
转载：30篇
评论：21条
(1)(1)(1)(1)(1)(1)(6)(3)(5)(2)(1)(2)(9)(1)(2)(7)(10)(8)(4)(7)(8)(6)(4)(5)(6)(5)(1)(12)(14)(16)(1)(7)(3)(1)(2)(1)(4)(1)(1)(4)966,690 十二月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
ASP.NET性能监控和优化入门
ASP.NET性能监控和优化入门
注意: 挥一挥衣袖，带走满满干货，关注，时不时发福利呦！
虽然在网上可以搜索到一些性能优化的资料，但它们通常都是关于Jit、垃圾回收、SQL查询优化、ORM陷阱等这样一些特定主题的。考虑到实现优化的美好前景是诱人的，这里冒出了这样的一个问题：针对当前的性能问题，如何知道所选定的优化方法将会切实地产生好的结果？
无疑在这个工作中的某一环是有所缺失的。我们需要能可持续地找到性能问题所在的方法。通过使用该方法，我们能发现系统中较慢的部分，并有切实措施支持我们对性能问题的诊断。掌握了性能问题所在，我们就可以进一步地确定是否需要进行性能改进，并对利益相关者解释所有这一切。
对于所发现的上述性能问题，进行准确地甄别是更有效的处理方法。问题在一开始可能并非是一个网页加载慢的问题。在存在超时的情况下（例如负载均衡器可能几秒后才会为连接提供服务），完全无法被区分开这是一个死锁问题或是响应时间慢的问题，因为这两个问题导致了同样的结果，就是产生了超时。这需要数据去找到导致问题的真正原因。
相关厂商内容
相关赞助商
QCon北京-18日，北京&国家会议中心，
为了阐明准确甄别性能问题的重要性，下面列举了一些导致Web应用响应慢的可能问题排查点：
JavaScript响应慢；
资源加载中的产生了阻塞；
用户端存在代理；
ISP或网络问题；
交换机和路由器；
负载均衡器；
应用代码（包括第三方软件库）；
HTTP服务器（例如有时是ASP.net或IIS）；
第三方服务，例如：支付服务提供商、地图服务提供商等；
子系统，包括：SQL Server、Redis、Elasticsearch、Rabbit MQ等。
还可以罗列出更多的性能问题排查点，这取决于需处理系统的复杂度和规模。在如此之多的系统组件都可影响性能优化问题的情况下，如何才能确诊性能问题呢？答案概括为一个词：数据。你需要来自于每个系统组件的、相关且有意义的数据。对于Web应用响应慢的问题，数据可以证明每个系统组件是对问题是有影响的还是完全无关的。
数据在手，就可以开始从上述列表中按你的思路去抽取问题排查点进行分析，这类似于在排序树中进行查找。每次在树中向下走一层，就越接近于性能问题的细节和实质，依次甄别性能问题是否存在于：
客户端，服务器端或是两者之间的某处？
响应慢的JavaScript、渲染或是资源阻塞？
负载均衡器、Web服务器、任一子系统或是第三方软件？
在这样树中逐层下行时，性能问题会变得越来越清晰。对于每个层次上的问题排查点，定位性能问题所需的数据必须要与对应的问题精度相匹配。这时有必要去使用性能分析工具或SQL执行计划这样的工具。
为有效地利用时间，很有必要重申一下Amdahl定律：
无论一个任务改进的程度如何，该任务中没有从改进中受益的部分限制了理论上的任务加速。
例如在一个Web请求中，假定需要100毫秒的服务器处理时间和5秒的SQL查询时间。即使你可以将服务器处理时间优化到低于1毫秒，但是这对整体响应时间的改进很小，也就是从5.1秒变成5秒。改进SQL处理所需的5秒时间是潜在收益最大的优化。
这种逐层厘清优化问题所在的自顶向下方法，对于局限在单一页面中的优化问题具有很好的效果。那么应用于跨越多个页面的优化问题上时效果又如何呢？例如，一些页面所存在的间歇性地打开慢问题，是由于子系统跟不上整体工作节奏，或是由于系统中存在某个再次重启可能就无法继续工作的老旧网络交换机。
这种情况下，侧重于应用的监控方法显示出它的局限性所在。这需要更多的软件层面和硬件层面上的指标，用于对系统中的每个组件进行评估。
在硬件层面，首先所能想到就是web服务器和数据库服务器，但它们只是冰山的一角。必须要识别和监控所有系统中的硬件组件，这包括：服务器、网络交换机、路由器、负载均衡器、防火墙、SAN等。
鉴于系统管理员的常规工作就是硬件监控，可能对于系统管理员而言上述的所有指标是显而易见的。但是这里有个重要警告：如果将这些硬件指标从软件指标中分离处理，那么从性能角度看所有这些硬件指标中的大部分是毫无用处的。换句话说，指标只有置于相应的环境中才能发挥最大作用。
例如，在一些情况下可能在数据库服务器上CPU占用率平均达50%是完全正常的，但是对于其它服务器而言这就是个定时炸弹。50%的CPU占用率，如果是在峰值时刻这意味着仍有很大空间去运行更繁重的任务。但如果是在闲暇时间段中而50%的CPU占用率频繁发生，这就意味着应用可能无法承受传入请求的突发峰值。
底线就是，为评估系统的健康度，CPU、内存和磁盘等全系统范围指标必须要与应用指标相关联。为给出更完全的系统健康状况视图，可以对请求吞吐量这样的应用指标和CPU占用率这样的系统指标进行可视化。
应用性能管理（Application Performance Management，APM）工具
APM工具提供数据采集、数据存储和数据可视化这些基础性操作。通常是由代理负责采集数据并将数据发送给数据存储，并使用Web界面以集中在Web请求上的仪表盘方式对数据进行可视化。
APM可用于：
对Web应用性能做整体可视化；
对特定的Web请求性能进行可视化；
在Web应用性能变差时或者多个错误出现时，自动发送告警；
在业务量大时，对应用的响应方式进行验证。
在给出了实例。
下面并非详尽地列出了支持对ASP.NET和IIS开箱即用的APM工具清单：
基础设施监控工具
基础设施监控工具在主机层面采集指标，这可更完整地反映性能。这些指标是在硬件和软件层面采集的。
轻量级分析工具
轻量级分析工具为特定Web请求提供了高层次的指标，并在开发人员浏览Web页面时就可提供实时反馈。这些工具可用于所有的环境类型中（包括开发环境、QA验证、模拟环境、生产环境等），因此非常适合于对特定页面性能的快速评估。
与相应的具有完全功能的分析工具相比，轻量级分析工具的本质差异在于它们并非附属于过程，这意味着在使用轻量级分析工具时无需操心它们所产生的开销。
在开发环境中，轻量级分析工具对当前正编写的代码提供了实时反馈。这对于发现N+1或响应时间慢等问题是非常有用的，因为响应时间总是显示在页面的一角上。
用性能计数器填补空白
Windows系统中的性能计数器（Performance counter）提供了硬件和软件层次上不同方面的指标。监控工具通常以性能计数器为报告方式，例如CPU和内存占用情况。但是通常会缺失一些有用的计数器，例如垃圾回收时间等。最切实可行的入门方法是使用并在迭代中添加必要的相关计数器。此外，使用对性能计数器进行实时地采集和可视化是可行的。在很多情况下，将用户定制指标或插件与APM工具进行集成也是可行的。
由于在很多应用中普遍地使用了数据库，持久层（即SQL数据库）常常成为性能的瓶颈。用于SQL监控的专业工具可提供资源使用指标，以及一些特定的指标，例如等待时间、每秒编译次数等，在这里仅列举几个。
在提供下列数据情况下，可以发现一些类型的问题并可对性能进行改进：
在一个或数个查询上存在过度的吞吐量；
过度的CPU占用，这暗示了查询问题的存在或者是索引的缺失；
可被缓存的高吞吐量查询。
SQL监控工具包括：
其它的持久系统
所有子系统都需要在某种程度上进行监控。对于低吞吐量或非关键的系统，简单的数据采集和可视化即足矣。在此外的情况下则需要更加高级的、专业的监控。
代码分析工具
当已确诊某个特定页面或代码段检测是响应慢的，代码分析工具可为性能问题鉴定提供最详尽的视图。代码分析工具还可为数据库查询和Web请求这样的外部调用提供了精准视图。
分析工具：
内存分析工具
内存监控和垃圾回收指标有助于潜在问题的检测。但这些指标在显示了存在问题的同时，通常并未给出问题的所在。如果需要队内存和垃圾回收问题进行深入地探究，内存分析工具就可派上用场。
分析工具：
用户端分析工具
性能问题也可能来自于前端。当前这个问题十分常见，因为以JavaScript主导的单页应用的大量涌现。所有的主流浏览器都已嵌入了诸如代码分析和内存分析这样的工具。显示事件和请求的序列的工具有利于一眼就确定问题是源于前端还是后端。
工具：Tools:
页面分析工具
高层次客户端工具为发现并解决性能问题的提供了便利着手点。这些工具可以针对响应时间问题的产生根源提供高层次的视图，并给出一些相应的建议。例如Google的就是这样的一个免费工具。
系统性能相关的因素和工具的数量是非常之多，这看上去似乎十分复杂。但是它们可以用一个词进行概括：数据。对系统有一个清晰的和准确的视图，这使得推理性能问题成为可能。这也使你可以在现场学习如何去解决性能问题，因为性能指标和图表将会引导你去发现到底是什么影响了系统性能。
Pierre-Luc Maheu 是一位软件开发人员，过去五年中先后供职于VoIP、cloud hosting和e-commerce。现供职于Amilia公司，一家提供在线注册管理SaaS平台的公司。他当前的兴趣在于监控、性能和规模化及F#。在闲暇时间喜欢去做室内攀岩、Animal Flow运动和剑道，这样有利于清空大脑。
查看英文原文：
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。