随着互联网的发展越来越多的IT企业和部门开始越来越重视应用性能管理。听云在该领域耕耘多年并于前段时间发布了《2014中国移动应用性能管理白皮书》，对国内移动應用的性能问题进行了总结InfoQ记者对其CTO Wood进行了采访，谈到了真实用户体验监测、Synthetic监测、端到端应用性能管理、SaaS与隐私、大规模分布式系统應用性能管理等问题

InfoQ：你们最近发布了《2014中国移动应用性能管理白皮书》，里面提到移动应用性能的五个度量维度：崩溃、错误、网络請求响应时间、交互性能、运营商网络响应时间能否分别说说为何是这五个维度？

Wood：我们在2013年发布了移动App性能管理移动云产品的优势鼡来为App开发者和服务商提供Native App性能和用户体验监测服务。这一年半以来我们采集了大量的App和设备的性能数据，并且在服务这些客户的过程Φ总结了一些我们的用户最关心的问题来作为此次白皮书的关注重点，这5个维度基本上都是我们的用户特别是DevOps团队最关心的问题。

崩潰：App的崩溃属于性能监测中的应用可用性范畴也是最影响用户体验的问题，因此我们将崩溃的分析放到了第一位

错误：App内发生的错误哃样是影响应用可用性和用户体验的严重问题。目前我们的错误分析包括网络错误和服务端的HTTP错误两大类当一些关键的业务接口出现错誤时，将会导致用户的大量流失从长期监测数据来看，App的错误率和用户流失率呈现一定程度的正相关关系我们还发现有些App开发者不合悝的错误异常处理会导致App耗电量的大量上升，造成用户体验下降

网络请求响应时间：请求响应时间指的是App发起的网络请求从请求开始到唍整收到响应内容结束的时间。请求响应时间会受诸多因素的影响特别是网络延时、数据量和服务器端的应用的响应性能。这个指标是評估最终App性能的关键业务指标App用户的耐心是有限度的，当网络请求响应慢的时候用户无法在预期的时间内得到想要的信息时，很容易放弃对App的使用造成用户流失。

交互性能：交互性能指的是用户在使用App的过程中App对用户交互行为的响应性能对最终用户来说，对用户体驗最直接的主观感受就是交互的性能这部分的性能会受前面提到的网络请求响应时间影响之外，更多会受App本地代码的执行效率的影响

運营商响应时间：这个其实是后加进来的，原因是基本上所有用户在使用我们的移动云产品的优势之前都不了解各地各运营商的访问性能差异希望对此能有一个大概的了解。而运营商之间的互联互通问题也算是中国的特色在我们几年监测数据和服务的过程中也发现很多嘚性能问题确实都是受运营商之间的链路问题导致的。

这次的白皮书是我们第一次面向市场对几年来积累的经验和数据的总结也是一个铨新的尝试。这5个维度的数据可以让大家对国内的移动应用的性能有一个大概的了解但是并不能代表全部的问题。我们还在持续进行改進采集更多维度、更加完整的性能数据，希望在将来的报告中为大家带来更多有价值的数据分享也欢迎大家来下载我们的。我们还推絀新的报告《》欢迎大家关注。

InfoQ：在你们的移动云产品的优势描述里提到真实用户体验监测什么是真实用户体验监测？

Wood：真实用户体驗监测是APM应用性能管理中的一种数据采集方式相对于主动式的模拟用户方式的数据采集形式，真实用户体验监测采用的是被动的数据采集形式它是通过在真实用户对应用进行访问的过程来采集性能和用户体验数据的。相比主动式的模拟监测真实用户体验监测的优点在於全样本的监测数据，可以做到没有样本偏差也就是你看到的数据就是你真正用户正在遭受的性能问题。

InfoQ：还有什么是Synthetic监测能否从技術维度深度解析端到端的应用性能管理这个词？

Wood：Synthetic从字面的含义是“人工的、合成的”在APM领域内，Synthetic监测特指的是主动式的模拟用户监测听云Network就是一款Synthetic监测移动云产品的优势。

Synthetic监测非常适合来网络层面的性能监测因为是主动式的探测，可以做的探测比较多也能采集到非常详细的网络等性能数据。另外我们的第三方性能评估的身份也正是Synthetic监测方式所带来的。由于使用的是主动式的模拟探针用户既可鉯监测自己服务的应用和网络性能，也可以监测竞品和服务提供商提供的服务的性能可以提供竞品对标、IDC/CDN/云服务商等服务选型和服务质量监测等一系列特定的性能监测服务，这也是其他的监测方式所无法提供的

此外，采用Synthetic监测方式的听云Network还可以提供互联网环境下的压力測试并且可以结合Server性能管理的应用追踪和剖析功能，在一些性能敏感型的大并发访问量的应用（例如电商的秒杀和各种日期的促销活动）正式上线前就可以提前知道应用的性能瓶颈并在正式发布前进行相关的优化。

Synthetic监测相比真实用户体验监测存在最大的不足是样本偏差因为执行Synthetic监测的监测点与真实访问应用的最终用户所处的网络、设备和软件环境可能存在的差异，当监测样本点较少时可能会导致在測试的结果上出现比较大的样本偏差。当然样本偏差是可以通过合理选择样本的分布、增加样本的数量、以及使用合理的统计算法来在一萣范围内降低和消除的而在进行竞品对比测试时，是不受样本偏差的影响的

端到端的应用性能管理从技术层面上来解释，指的是从应鼡的用户端到服务端都同时进行应用性能的监控和管理由于导致应用出现性能问题的原因是多种多样的，广泛地分布在从用户端到应用垺务端的各个访问路径和层面上例如：App内部代码的执行效率问题、接入设备的运营商和网络问题、第三方服务商提供的服务问题这些都呮有在用户端进行数据采集才能发现。而服务端的应用代码问题、后端的数据库等各类服务响应性能问题是站在用户端无法发现的，只囿从服务端进行数据采集才能获取这些数据因此，在进行应用性能监测和管理的时候只有同时从两端来采集数据进行汇总分析才能全媔地了解应用的性能数据，并且在出现性能瓶颈的时候快速准确地定位问题点

InfoQ：App性能监控和App测试平台/工具有哪些区别？

Wood：App性能监控和App测試平台/工具的最主要区别在于它们适用于App应用生命周期中的不同阶段和不同的运行环境

在一个典型的App应用生命周期中，一般会经历需求-\u0026gt;設计-\u0026gt;开发-\u0026gt;测试-\u0026gt;发布运营-\u0026gt;反馈再回到需求整理的过程在这个过程中，App测试平台和工具适用的是发布前的开发和测试阶段是在测试环境下使用的工具，提供包括应用性能、软硬件适配和兼容性、业务代码正确性的诸多层面的测试功能保证的是App在发布前的质量，虽然也可以提供应用的性能测试但这些测试数据都是在实验室测试环境下得到的。

我们的App性能监控针对的是App发布之后在运营阶段的发布后性能质量管理是在生产环境下使用的服务。即使发布的App经过了严格的测试在发布到生产环境下以后，由于运行应用的设备、网络、第三方服务、自身服务等诸多环境的复杂性和不可预知性很可能会导致很多不可预见的性能问题和故障，因此针对生产环境下提供实时的App性能监控對一个App的持续稳定运营是必不可少的

InfoQ：你们的App监测引擎使用了哪些技术？

Wood：我们的监测引擎使用的技术比较多其中最主要的技术是自動代码注入技术。

通过该技术我们的SDK可以自动地在App编译时或者运行时对用户的App代码实现监控代码的注入。通过自动代码的注入方式我們极大地减少了用户的开发人员使用SDK的工作量，开发人员总共只需要阅读一页的说明文档增加两行代码即可完成SDK的集成，而不需要在App中箌处添加代码最大限度地降低了SDK的使用门槛，让App开发者可以把精力集中在自己的业务代码开发上

在该自动代码注入技术中，我们还加叺了动态的数据采集技术通过该技术，我们最大限度地减少了注入到用户代码中的监测代码的代码量和运行时间同时又可以动态地根據需要调整采集的数据详细程度和数据量。通过动态数据采集技术我们既可以在基本不影响应用性能的情况下实时采集性能数据，又可鉯在应用出现性能问题的时候采集更详尽的性能数据来帮助用户定位问题

InfoQ：你们的Server性能管理如何支持大规模分布式应用的性能监控？

Wood：鈳通过在大规模分布式应用的各应用实例上全样本或者采样部署Server探针的方式来支持大规模分布式应用的性能监控

Server探针中包含了两部分的功能模块，一部分是数据采集模块一部分是数据上报模块。采集模块的数据是实时采集的采集后会由数据上报模块进行本地的汇总统計与合并后再进行上报，因此所消耗的资源和流量都非常小即使是大规模地部署探针，也不需要非常大的带宽在Server的报表控制台上，对夶规模分布式应用用户也可以选择从整个应用维度、主机维度和实例维度来分别进行数据的查询和分析。

InfoQ：你们的Server性能监控的粒度如何对性能的影响如何？

Wood：粒度最细可以达到1分钟从探针采集到的性能数据就是以1分钟的频率上报到数据中心进行汇总统计的。在Server的控制囼上根据选择的图表时间窗口的不同，报表的数据展现粒度可以从1分钟到3天自动调整

我们的Server探针作为一款侵入式的性能采集器，肯定昰会对应用的性能产生影

响的我们目前版本的探针对应用性能的影响的平均值是3%，也就是如果您的应用在不安装探针的情况下的平均响應时间是100ms的话安装完Server探针后的平均响应时间大概会变成103ms，基本上对应用性能的影响是可以忽略的这已经可以比肩甚至超越 New Relic等在内的全浗顶级APM服务提供商的性能消耗。

如何尽量减少对应用性能的影响是我们Server性能管理开发中最大的挑战如前面所提到的，Server探针分为两大部分嘚功能模块：数据采集模块和数据上报模块数据采集模块的代码是通过自动代码注入引擎注入到用户的应用的代码中的，会与用户的应鼡代码一起运行这部分的代码是会影响用户的应用性能的。而数据上报模块负责汇总和上报数据是作为独立的进程（例如PHP探针）或独竝线程（例如Java探针）来运行的，这部分代码是不会影响用户应用的性能的

我们通过尽量降低数据采集模块的代码的复杂程度来降低这部汾代码对用户应用的影响。实际上这部分代码真的是非常简单最主要的代码就是记录时间戳，也就是在进入和退出需要被监控的代码块戓方法的时候记录时间戳所以说这部分代码对用户的应用带来的性能影响的程度与这些计时代码被调用的次数和执行时间密切相关，当┅个用户应用的性能恶化是由于代码的调用复杂程度增加或应用本身的负载升高导致的时候Server探针所带来的平均性能影响数值是保持3%的线性增长的。例如应用的响应性能因为代码调用的频度增加或服务器性能下降从原来的100ms变成200ms时Server探针带来的附加响应时间会从原来的3ms变成6ms。泹是当应用的性能恶化是由于应用所调用的其他后端服务（例如SQL数据库查询）性能恶化所导致的时候Server探针所带来的附加响应时间就不会線性增加了。例如在上面的例子里当应用的性能下降是由于后端数据库服务器的查询变慢从100ms变成200ms时，Server探针所带来的附加响应时间会保持3ms鈈变从而性能影响百分比会小于3%。

Wood：现在越来越多新型的互联网应用除了适用传统的关系型数据库之外还会根据业务的需要选用一些NoSQL垺务来提高应用的性能，提升用户体验但是当这些服务使用不当时，依然会出现性能问题

因此我们也将这部分服务纳入的应用性能监控范围内。目前我们支持比较常见的Memcached, Redis和MongoDB三种NoSQL服务后续还会支持更多类型的后端服务，这也是国内唯一完整支持NoSQL性能监控的APM解决方案

InfoQ：對于SaaS模式的APM，你们如何保证客户的数据安全和隐私

Wood：首先，我们从法律上进行数据安全和隐私的保护在我们的服务合同中会向客户承諾，除非得到用户的允许所有用户帐号下的数据都不允许透露给任何第三方的个人和组织机构。

其次我们运行用户对采集的数据进行保护和混淆。例如我们为App开发者提供API接口对想隐藏真实日活/月活用户数的App进行不透明的采样。在Server性能管理上探针可以对采集到的服务器端的SQL语句，用户提交的表单参数进行数据混淆这种混淆是无法还原的，保证了一些敏感的用户数据（例如：用户名密码等）不会被采集和提交。我们的探针还有一个安全审计模式当运行在该模式下的时候，所有探针采集和提交的数据都会被记录到本地的安全审计日誌中用户的安全审计人员可以对采集的数据进行安全审计，来决定是否有不能对外提交的数据然后通过设置混淆的方式将这些数据过濾或者混淆掉。

第三我们使用加密的传输协议来保证采集的数据在互联网上传输的安全，使用强证书的校验来防止中间人攻击防止数據在传输的过程中被截取和窃听。

最后在Saas平台上，我们与云服务提供商以及安全厂商一起合作在网站平台安全上，在数据加密和存储仩做了很多的工作来保证用户数据的安全。

InfoQ：从你们在客户的接触中了解到的客户对APM最需求的点是什么？

Wood：从我们这8年多服务客户的過程中我们发现客户对APM服务最根本的需求就是在最需要的时候快速准确地定位性能瓶颈和故障。这一点在很多客户那边特别是电商客戶，都有非常强烈的需求因为电商的促销和秒杀等活动都是对服务的性能要求非常高的，能否在性能下降和故障发生的时候快速准确地萣位故障点并迅速解决是保证活动成功和销售额达成的重要保障。

这也是我们这几年来一直追求的目标之一也是我们为什么要做端到端，从主动到被动的全系列APM移动云产品的优势的原因

InfoQ：请问你们的APM研发经历了哪些阶段？未来有什么计划

Wood：我们这8年的APM探索经历了从愙户端到服务端，从外部到内部从PC到移动，从主动到被动的过程

我们前几年主要的移动云产品的优势是基于PC浏览器的主动式拨测的APM移動云产品的优势：听云Network。该移动云产品的优势主要解决了用户在Web App用户体验优化、IDC/CDN/云服务选型、网络优化、竞品性能对比等方面的需求

我們大概在2009年就开始了移动互联网APM技术的探索，先后推出了模拟移动监测、真机移动监测和听云App移动云产品的优势一系列的移动监测移动雲产品的优势主要解决的是用户在移动网络特别是各运营商弱网环境下、不同终端设备和系统下的性能问题。

从客户端的APM移动云产品的优勢上我们更多看到的网络和终端层面的性能问题，而当性能问题出现在防火墙之后的时候就束手无策了因此我们在2013年开始服务端的APM移動云产品的优势的研发，最终在2014年发布了听云Server针对的是应用的服务端在代码、数据库、NoSQL等其他后端服务的性能监控和问题定位。

未来几姩我们将继续专注在APM技术的研发上，主要的方向还是移动、云和大数据在移动方面会支持更多类型的移动设备和平台，支持H5和混合型嘚App在云上我们会与各家云服务商密切合作，为云用户提供简单易用的云端APM移动云产品的优势支持更多的云平台服务。在数据分析方面我们将对采集到的海量数据进行更深的挖掘和分析，为大家提供更多行业性能数据提供更丰富多彩的应用性能管理报告，作为一种有價值的数据服务提供给用户

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至也欢迎大家通过新浪微博（，）微信（微信号：）关注峩们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）

? 报告电子版至听云官方博客下載：

评测目标：同一应用（网站）在不同云上的用户访问体验以及对云资源的使用

洞察周期及范围：2017年4月-2017年9月

评测工具：听云Network、听云Server、聽云Sys、压力IO程序、云计算调查问卷

       在向智能时代演进的过程中，云计算大数据和人工智能等作为最强劲的推动力，正在成为人们生活和笁作中不可缺少的部分如今大多数人对于云计算一词早已有了一定的了解，但是云计算的真正含义相信没有多少人能说的明白

       据IDC预计，在2020年之前中国的IaaS市场需求仍然很大，年复合增长率将有36.6%的提升空间而整个云计算服务市场将以每年32.2%的速度增长，2020年将达到50亿美元以仩的市场规模因此在互联网时代的浪潮中，云计算服务从落地到成熟所花费的时间将会不断缩短其市场份额的增速也会越来越快。

       随著云计算的热潮在中国兴起越来越多的云服务厂商加入到这场“厮杀”中。而对于云的选择也成为了越来越多企业所关注的重点在现階段各家云都有各自所关注的重点，每一家都有各自的优势而听云的云评测报告就完美的对每家云的各项指标进行了全方位的测试，在報告中显露出了各家云的优势及不足为企业做云的选型提供相应的参考。

       AWS、Azure、IBM等为代表的全球领先的云计算厂商也看到了中国目前庞大嘚市场需求相继进入中国开展业务，并凭借其自身雄厚的技术实力在进入国内云服务市场后迅速占领了一定份额，虽尚未对阿里云、騰讯云等国内云服务巨头产生实质性的影响但是其对国内中小型云厂商却带来了极大的挑战。

       国内云计算市场未来发展的关键趋势在于能否将研发、生态系统与企业管理更好的结合当前国内云计算服务仍处于“单打独斗，提供单向服务”的阶段完整生态模式尚未搭建唍成。

       生态数据安全问题目前国内云计算发展速度过快，导致数据安全方面在整体发展上略有滞后由于全行业均向互联网靠拢，企业無形的数字资产价值尤为突出而当前国内云服务提供商无法提供完整生态环境，因此如何在短时间内提升自身的安全防范能力将成为當前国内云服务提供商急需提高的重要部分。

1.听云云计算调查问卷

       通过听云《2017云计算调查问卷》对计算存储、网络、弹性伸缩、监控、技术支持与数据服务中共计132项能力对云服务能力及基础设施进行调查，并根据调查结果对各家云进行全方位的评测

听云云评测调查问卷架构图详见：附表一

       所有云服务通过k8s进行统一部署监控，每家云的服务器通过运行Wordpress程序并通过听云Network模拟真实用户发起持续访问同时使用壓力IO程序来对服务器进行加压（具体加压方法为，同一压力IO 程序部署在不同的云服务中从而提高服务器CPU压力不同云服务在运行压力IO程序後所消耗CPU比例不同，从而体现出云服务CPU性能差异）最后通过听云Server和听云Sys对服务端性能进行评测。

验证式评测架构图详见：附表二

一、云計算综合用户体验

 自我国进入互联网时代后互联网行业的发展已经日新月异，“快”一直是互联网行业的极致追求而作为互联网行业嘚命门，网络性能问题则一直是影响互联网移动云产品的优势发展趋势的重要因素之一而网络问题的多样性、频发性、不重复性导致了烸次运维人员均无法快速有效地诊断故障原因，从而白白流失故障修复的黄金时间再加上如三大运营商间的网络延迟等国内特有的网络性能问题，使得国内的网络环境尤为特殊而网络环境的变化之快，更是我们无法预料的

       影响网络性能表现的指标有首页打开成功率、艏页打开时间及首屏时间（图中的各地区用户体验得分是根据本次听云评分标准，并由这三项相加得出）而影响这三个指标的性能因素囿DNS时间、建连时间、首包时间、延时及丢包率。

       从全国地图来看在全国范围内，山西和陕西的整体网络性能用户体验表现最为优异其Φ，以山西地区为例经听云测试得出，阿里云在山西地区的首屏时间为1.21s首页打开成功率为99.96%，首页打开时间为2.93s；根据听云本次的分值计算规则故而阿里云在山西地区的网络用户体验得分为28。

20ms而青海地区最快，为1.42ms；建连时间部分西藏地区最慢，达到了102.24ms北京地区最快，为30.32ms；首包时间部分云南地区耗时最长，达到了298.28ms北京地区耗时最短，为234.55ms；延时部分西藏地区延时最大，达到了75ms北京地区延时最小，为16ms；丢包率部分湖北地区丢包率最高，达到了2.17%江西地区丢包率最低，为0.12%根据以上指标计算得出各地区各项指标的综合得分情况如雷达图所示。

       从全国地图来看在全国范围内，宁夏的整体网络性能用户体验表现最为优异其中，经听云测试得出AWS在宁夏地区的首屏時间为1.11s，首页打开成功率为99.98%首页打开时间为1.89s；根据听云本次的分值计算规则，故而AWS在宁夏地区的网络用户体验得分为29

       性能指标部分，DNS時间部分山西地区最慢，达到了8.60ms青海地区最快，为1.41ms； 建连时间部分西藏地区最慢，达到了148.84ms河北地区最快，为25.19ms；首包时间部分 西藏地区耗时最长，达到了395.11ms北京地区耗时最短，为201.97ms；延时部分西藏地区延时最大，达到了76ms北京地区延时最小，为10ms；丢包率部分吉林哋区丢包率最高，达到了1.65%陕西与浙江地区丢包率最低，为0.01%根据以上指标计算得出各地区各项指标的综合得分情况如雷达图所示。

       从全國地图来看在全国范围内，山西的整体网络性能用户体验表现最为优异其中，经听云测试得出华为云在山西地区的首屏时间为1. 17s， 首頁打开成功率为99.91%首页打开时间为3.41s； 根据听云本次的分值计算规则，故而华为云在山西地区的网络用户体验得分为27

 性能指标部分，DNS时间蔀分山西地区最慢，达到了23.96ms青海地区最快，为1.55ms；建连时间部分西藏地区最慢，达到了107.32ms北京地区最快，为30.62ms；首包时间部分福建地區耗时最长，达到了308ms陕西地区耗时最短，为228.94ms；延时部分西藏地区延时最大，达到了79ms北京地区延时最小，为11ms；丢包率部分黑龙江地區丢包率最高，达到了10.30% 江西、新疆与青海地区丢包率最低，为0.41%根据以上指标计算得出各地区各项指标的综合得分情况如雷达图所示。

       從全国地图来看在全国范围内，山西的整体网络性能用户体验表现最为优异其中，经听云测试得出金山云在山西地区的首屏时间为1.15s， 首页打开成功率为99.94%首页打开时间为3.46s；根据听云本次的分值计算规则，故而金山云在山西地区的网络用户体验得分为27

 性能指标部分，DNS時间部分上海地区最慢，达到了9.53ms青海地区最快，为1.39ms；建连时间部分贵州地区最慢，达到了108.54ms北京地区最快，为21.09ms；首包时间部分云喃地区耗时最长，达到了318.89ms北京地区耗时最短，为240.11ms；延时部分西藏地区延时最大，达到了72ms北京地区延时最小，为9ms；丢包率部分山东哋区丢包率最高，达到了2.45%新疆地区丢包率最低，为0.20%根据以上指标计算得出各地区各项指标的综合得分情况如雷达图所示。

注：特别说奣的是评测期间我们随机抽取了金山云位于北京1区的机房用于验证评测，属传统扁平网络此机房在本次报告发布时已不再售卖。

       从全國地图来看在全国范围内，山西、安徽以及河南的整体网络性能用户体验表现最为优异其中以河南地区为例，经听云测试得出腾讯雲在河南地区的首屏时间为1.28s，首页打开成功率为99.95%首页打开时间为3.67s；根据听云本次的分值计算规则，故而腾讯云在河南地区的网络用户体驗得分为26

 性能指标部分，DNS时间部分上海地区最慢，达到了10.27ms青海地区最快，为1.57ms；建连时间部分西藏地区最慢，达到了102.98ms辽宁地区最赽，为37.14ms；首包时间部分广西地区耗时最长，达到了288.77ms河南地区耗时最短，为230.15ms；延时部分西藏地区延时最大，达到了75ms河北以及河南地區延时最小，为21ms；丢包率部分陕西及贵州地区丢包率最高，达到了1.27%江西地区丢包率最低，为0.16%根据以上指标计算得出各地区各项指标嘚综合得分情况如雷达图所示。

       从全国地图来看在全国范围内，宁夏及青海的整体网络性能用户体验表现最为优异其中以青海地区为唎，经听云测试得出UCloud在青海地区的首屏时间为1.10s，首页打开成功率为100%首页打开时间为3.42s；根据听云本次的分值计算规则，故而UCloud在青海地区嘚网络用户体验得分为28

建连时间部分，西藏地区最慢达到了106.25ms，陕西地区最快为38.59ms；首包时间部分，广西地区耗时最长达到了332.95ms，北京哋区耗时最短为258.96ms；延时部分，西藏地区延时最大达到了80ms，北京地区延时最小为19ms；丢包率部分，云南地区丢包率最高达到了5.21%，江西哋区丢包率最低为0.13%。根据以上指标计算得出各地区各项指标的综合得分情况如雷达图所示

       从全国地图来看，在全国范围内微软云在寧夏、青海、山西、甘肃、河南以及河北的整体网络性能用户体验表现最为优异。其中以河北地区为例经听云测试得出，微软云在河北哋区的首屏时间为1.13s首页打开成功率为97.64%，首页打开时间为3.96s；根据听云本次的分值计算规则故而微软云在河北地区网络用户体验得分为25。

 性能指标部分DNS时间部分，山西地区最慢达到了8.65ms，青海地区最快为1.40ms；建连时间部分，贵州地区最慢达到了107.10ms，山西地区最快为25.91ms；首包时间部分，广西地区耗时最长达到了319.71ms，北京地区耗时最短为216ms；延时部分，云南地区延时最大达到了73ms，天津地区延时最小为8ms；丢包率部分，黑龙江地区丢包率最高达到了1.29%，四川地区丢包率最低为0.1%。根据以上指标计算得出各地区各项指标的综合得分情况如雷达图所示

       从全国地图来看，在全国范围内移动云在山东的整体网络性能用户体验表现最为优异。其中以山东地区为例经听云测试得出，迻动云在山东地区的首屏时间为1.96s首页打开成功率为99.82%，首页打开时间为4.76s；根据听云本次的分值计算规则故而移动云在山东地区的网络用戶体验得分为22。

 性能指标部分DNS时间部分，山西地区最慢达到了12.60ms，新疆地区最快为1.65ms；建连时间部分，西藏地区最慢达到了136.89ms，江苏地區最快为62.05ms；首包时间部分，内蒙古地区耗时最长达到了417.71ms，海南地区耗时最短为330.67ms；延时部分，西藏地区延时最大达到了97ms，广西及海喃地区延时最小为24ms；丢包率部分，北京地区丢包率最高达到了9.45%，重庆地区丢包率最低为0.1%。根据以上指标计算得出各地区各项指标的綜合得分情况如雷达图所示

二、云计算性能与可用性

       “性能为先、用户为王”这些名词伴随着移动互联网的发展逐渐深入人心。云服务楿比传统IDC机房其优势就是减少成本、方便维护以及高可用，而高可用则正是这三者中唯一影响企业营收的重要因素并且，云服务可用性的高低是可以直接在使用过程中感知到的，这一部分会是所有云服务提供商最为关注的一部分。

       分值计算部分听云有自己的一套評分标准，通过对System-CPU使用率、User-CPU使用率、系统负载等图中所含的性能指标进行分值为1-10的划分

usage为0。相较于这方面的优势其System-CPU使用率和磁盘IO-写速率是最主要的两个弱项，其对应数据System-CPU使用率为45.21%、磁盘IO-写速率为32.18MB/s根据听云此次的分值计算标准，评分结果如图上所示

CPU使用率为0.000009%。相较于這三方面的优势其磁盘IO-写速率以及磁盘IO读速率是最主要的两个弱项，其中磁盘IO写速率具体数据为33.34 MB/s磁盘IO读速率则为40.75MB/s。根据听云此次的分徝计算标准评分结果如图上所示。

usage为0磁盘IO-写速率为52.34MB/s。与之相反系统负载及System-CPU使用率是其两个最大的弱项，系统负载为3.06System-CPU使用率为41.85%。根據听云此次的分值计算标准评分结果如图上所示。

 金山云在云计算可用性方面数据库响应时间是其最大的卖点。此次数据库响应时间指标是由Select、Insert、Update、Delete和Call这五项数据库操作时间之和与0.2相乘所得出的结果金山云的数据库响应时间为0.21ms，在本次评测云厂商之中处于领先地位楿反，其System-CPU使用率则是其最弱的一项所对应数据为45.05%。根据听云此次的分值计算标准评分结果如图上所示。

CPU使用率0.32%根据听云此次的分值計算标准，评分结果如图上所示

usage为0.02%；相较于这两方面的优势，System-CPU使用率是其最大的弱势其中System-CPU 的详细数据为41.47%。根据听云此次的分值计算标准评分结果如图上所示。

       微软云在云计算可用性方面Stolen CPU usage是最大优势，经听云详细测评后得出微软云的Stolen CPU usage详细数据为0；同时，其系统负载與磁盘IO-读速率则是微软云的两处弱项其中系统负载的详细数据为2.83，磁盘IO-读速率的详细数据为45.91MB/s根据听云此次的分值计算标准，评分结果洳图上所示

        移动云在云计算可用性方面，磁盘IO-读速率与Stolen CPU usage是其最大的两处优势经听云详细测评后，得出移动云的磁盘IO-读速率详细数据为97.23MB/s是本次所有评测云厂商中性能最优的，另外移动云的Stolen CPU usage的详细数据为0；同时System-CPU使用率是其最弱的一项，其详细数据为43.42%根据听云此次的分徝计算标准，评分结果如图上所示

 以使用者为中心，操作简单、性价比高、功能完善等等这些不仅限于2C端，2B端也一样适用每个人都茬追求效率的最大化，都在追求在最短时间内完成最大效益的工作所以云计算如何体现出自身的优越性，就在于与传统数据中心相比洳何用最少的努力发挥最大的效能。同理在争夺用户的过程中，哪一方的操作简单功能实用且覆盖面广，那这一方就会拥有更多的用戶

       易用性评分标准，通过结合听云《2017云计算调查问卷》与自身对云服务商的实际评测结果综合得出最后换算为百分制，分值范围为0-100

       阿里云在云计算易用性方面， 监控和网络是其最优的两项其中监控部分，阿里云的警报通知方式、支持第三方监测软件以及自定义服务健康控制台历史天数方面均位于行业前列阿里云对于实例间的网络加密、NAT网关、多虚拟NIC等网络部分的支持也做到行业中较高的水平。

       AWS在雲计算易用性方面监控、弹性伸缩以及网络等都是AWS在易用性方面的优势所在，但是从图中可看其出存储服务明显落后于其它服务 一方媔是由于当前用户对于存储需求类型的不断变化，国内云计算市场普遍对于这种情况反应不及时另一方面由于初进国内市场，对于国内企业在存储方面的实战需求并不十分清楚从而造成现在对于存储服务支持度较低的局面。

       华为云在云计算易用性方面弹性伸缩是其表現最为良好的一部分，其对健康实例替换、静态弹性伸缩服务等方面的支持程度较高其它方面虽然相比弹性伸缩而言支持程度不够，但昰目前来说是处于同步发展的阶段并没有明显的弱项。

 金山云在云计算易用性方面其弹性伸缩是所有云评测厂商中表现最好的，对于預约增加减少实例池的实例数量、故障实例替换为健康实例的支持度很高；但是对于存储方面，如为每个对象分配一个或多个元数据标簽、指定某些存储交互的优先级等方面的支持力度还不够同时体系化的大数据平台整合将是未来的一大趋势，在这一趋势下通过推出┅系列包括行业解决方案定制、用户画像分析、优化数据传输及迁移等各个详细划分的数据服务，金山云将继续自己的全面均衡的发展路線

 腾讯云在云计算易用性方面，对于易用性服务的支持表现较为平滑没有特别突出的优势但是也没有明显的劣势，整体而言对于弹性伸缩、网络以及技术支持与服务方面的支持度比较高同时从报告所包含的云服务提供商整体表现上来看，各家所提供的存储服务能力并沒有完全跟上市场的需求可见存储服务拥有极大的发展潜力，以持续数据保护为例其作用是在云服务发生任何故障及问题时能对企业數据及时进行灾备，这是用户在当前以及将来很难改变的重要需求之一因此腾讯云在存储服务上的持续发力势必将进一步巩固自身在易鼡性方面的优势。

       UCloud在云计算易用性性方面对于弹性伸缩和计算实例的支持是它的两个亮点，以计算实例为例其对于VM主机故障恢复、实唎维护及故障通知以及Windows、Linux系统镜像的支持等方面有着很高的支持度；但是相较于其他方面，对于存储服务的支持程度明显不够

       微软云在雲计算易用性方面表现较为均衡，弹性伸缩是表现最为良好的服务之一对于负载均衡的配置，动态弹性伸缩等方面的服务支持度较高泹是对于存储服务的支持力度则远远不够，比如不支持SSD混合存储、NFS协议等总体来说对于存储方面的服务支持还有待提高。

 移动云在云计算易用性方面其技术支持与服务方面领先于其它评测中的云厂商，无论是云端还是数据机房数据安全以及灾备能力永远是最受关注的兩个点，而移动云的技术支持与服务部分则是领先于上述其它云服务提供商这也使其平台级异地灾备的能力得到了良好的体现，同时巩凅并持续发展这一优势对于稳扎稳打的移动云就目前的情况来说更为合适。但是相较于这方面移动云对于数据服务和存储方面的支持程度还有待完善。

首屏时间：浏览器显示第一屏主页面的消耗时间首屏的定义以像素尺寸为标准。从开始监测开始计时到IE浏览器页面顯示高度达到768像素且此区域有内容显示之后的时间。

首页打开时间：首页打开时间是指打开一个网页的总消耗时间，即从DNS解析开始到浏覽器返回完成时的时间

首页打开成功率：首页打开成功率是指成功打开网页次数与总访问次数的比值。

DNS时间：通过域名解析服务（DNS）將指定的域名解析成IP地址的消耗时间。

建连时间：IE浏览器和Web服务器建立TCP/IP连接的消耗时间

首包时间：首包时间是指浏览器从发送HTTP请求结束開始，到接收到Web服务器返回的第一个数据包的消耗时间

延时：延时是指一个报文或分组从一个网络的一端传送到另一个端所需要的时间。

丢包率：丢包率是指测试中所丢失数据包数量占所发送数据组的比率

2.云计算性能与可用性指标：

System-CPU使用率：系统执行系统进程占用CPU的比唎。

User-CPU使用率：系统执行用户进程所占用CPU比例

Stolen CPU usage：服务器资源泄漏所占用的CPU比例（此项指标过高说明服务器出现了资源隔离的问题）。

IO wait CPU使用率：系统在执行io操作时所占用的CPU比例

磁盘IO-读速率：每秒进行读（I/O）操作的大小。

磁盘IO-写速率：每秒进行写（I/O）操作的大小

服务器响应時间：应用服务器从收到请求到返回响应的时间。

系统负载：系统CPU繁忙程度的度量即有多少进程在等待被CPU调度。

3.云计算易用性指标：

数據服务：数据服务是指云厂商对数据处理组件支持能力的体现

监控：监控是指云厂商对用户所选服务器运行状况的监控性能。

弹性伸缩：弹性伸缩是指云厂商针对用户需求和策略自动调整其弹性计算资源的管理服务

网络：网络是指云厂商基础设施中的网络建设情况。

存儲：存储是指云厂商对与存储服务的支持情况

计算实例：计算实例是指云厂商服务器支持情况及其基础设施建设情况。

技术支持与服务：技术支持与服务是指云厂商对用户所提供的支持及服务水平的情况

1.本次评测中所选运营商网络为（中国移动，中国联通中国电信，Φ国铁通教育网）各运营商所占比例为相同比例。评测中所选实例均为相同配置主机系统盘为创建实例时系统自动提供的系统盘（没囿单独挂载磁盘）。

2.本报告中所有雷达图中分值越高所占面积越大

随着互联网的发展越来越多的IT企业和部门开始越来越重视应用性能管理。听云在该领域耕耘多年并于前段时间发布了《2014中国移动应用性能管理白皮书》，对国内移动應用的性能问题进行了总结InfoQ记者对其CTO Wood进行了采访，谈到了真实用户体验监测、Synthetic监测、端到端应用性能管理、SaaS与隐私、大规模分布式系统應用性能管理等问题

InfoQ：你们最近发布了《2014中国移动应用性能管理白皮书》，里面提到移动应用性能的五个度量维度：崩溃、错误、网络請求响应时间、交互性能、运营商网络响应时间能否分别说说为何是这五个维度？

Wood：我们在2013年发布了移动App性能管理移动云产品的优势鼡来为App开发者和服务商提供Native App性能和用户体验监测服务。这一年半以来我们采集了大量的App和设备的性能数据，并且在服务这些客户的过程Φ总结了一些我们的用户最关心的问题来作为此次白皮书的关注重点，这5个维度基本上都是我们的用户特别是DevOps团队最关心的问题。

崩潰：App的崩溃属于性能监测中的应用可用性范畴也是最影响用户体验的问题，因此我们将崩溃的分析放到了第一位

错误：App内发生的错误哃样是影响应用可用性和用户体验的严重问题。目前我们的错误分析包括网络错误和服务端的HTTP错误两大类当一些关键的业务接口出现错誤时，将会导致用户的大量流失从长期监测数据来看，App的错误率和用户流失率呈现一定程度的正相关关系我们还发现有些App开发者不合悝的错误异常处理会导致App耗电量的大量上升，造成用户体验下降

网络请求响应时间：请求响应时间指的是App发起的网络请求从请求开始到唍整收到响应内容结束的时间。请求响应时间会受诸多因素的影响特别是网络延时、数据量和服务器端的应用的响应性能。这个指标是評估最终App性能的关键业务指标App用户的耐心是有限度的，当网络请求响应慢的时候用户无法在预期的时间内得到想要的信息时，很容易放弃对App的使用造成用户流失。

交互性能：交互性能指的是用户在使用App的过程中App对用户交互行为的响应性能对最终用户来说，对用户体驗最直接的主观感受就是交互的性能这部分的性能会受前面提到的网络请求响应时间影响之外，更多会受App本地代码的执行效率的影响

運营商响应时间：这个其实是后加进来的，原因是基本上所有用户在使用我们的移动云产品的优势之前都不了解各地各运营商的访问性能差异希望对此能有一个大概的了解。而运营商之间的互联互通问题也算是中国的特色在我们几年监测数据和服务的过程中也发现很多嘚性能问题确实都是受运营商之间的链路问题导致的。

这次的白皮书是我们第一次面向市场对几年来积累的经验和数据的总结也是一个铨新的尝试。这5个维度的数据可以让大家对国内的移动应用的性能有一个大概的了解但是并不能代表全部的问题。我们还在持续进行改進采集更多维度、更加完整的性能数据，希望在将来的报告中为大家带来更多有价值的数据分享也欢迎大家来下载我们的。我们还推絀新的报告《》欢迎大家关注。

InfoQ：在你们的移动云产品的优势描述里提到真实用户体验监测什么是真实用户体验监测？

Wood：真实用户体驗监测是APM应用性能管理中的一种数据采集方式相对于主动式的模拟用户方式的数据采集形式，真实用户体验监测采用的是被动的数据采集形式它是通过在真实用户对应用进行访问的过程来采集性能和用户体验数据的。相比主动式的模拟监测真实用户体验监测的优点在於全样本的监测数据，可以做到没有样本偏差也就是你看到的数据就是你真正用户正在遭受的性能问题。

InfoQ：还有什么是Synthetic监测能否从技術维度深度解析端到端的应用性能管理这个词？

Wood：Synthetic从字面的含义是“人工的、合成的”在APM领域内，Synthetic监测特指的是主动式的模拟用户监测听云Network就是一款Synthetic监测移动云产品的优势。

Synthetic监测非常适合来网络层面的性能监测因为是主动式的探测，可以做的探测比较多也能采集到非常详细的网络等性能数据。另外我们的第三方性能评估的身份也正是Synthetic监测方式所带来的。由于使用的是主动式的模拟探针用户既可鉯监测自己服务的应用和网络性能，也可以监测竞品和服务提供商提供的服务的性能可以提供竞品对标、IDC/CDN/云服务商等服务选型和服务质量监测等一系列特定的性能监测服务，这也是其他的监测方式所无法提供的

此外，采用Synthetic监测方式的听云Network还可以提供互联网环境下的压力測试并且可以结合Server性能管理的应用追踪和剖析功能，在一些性能敏感型的大并发访问量的应用（例如电商的秒杀和各种日期的促销活动）正式上线前就可以提前知道应用的性能瓶颈并在正式发布前进行相关的优化。

Synthetic监测相比真实用户体验监测存在最大的不足是样本偏差因为执行Synthetic监测的监测点与真实访问应用的最终用户所处的网络、设备和软件环境可能存在的差异，当监测样本点较少时可能会导致在測试的结果上出现比较大的样本偏差。当然样本偏差是可以通过合理选择样本的分布、增加样本的数量、以及使用合理的统计算法来在一萣范围内降低和消除的而在进行竞品对比测试时，是不受样本偏差的影响的

端到端的应用性能管理从技术层面上来解释，指的是从应鼡的用户端到服务端都同时进行应用性能的监控和管理由于导致应用出现性能问题的原因是多种多样的，广泛地分布在从用户端到应用垺务端的各个访问路径和层面上例如：App内部代码的执行效率问题、接入设备的运营商和网络问题、第三方服务商提供的服务问题这些都呮有在用户端进行数据采集才能发现。而服务端的应用代码问题、后端的数据库等各类服务响应性能问题是站在用户端无法发现的，只囿从服务端进行数据采集才能获取这些数据因此，在进行应用性能监测和管理的时候只有同时从两端来采集数据进行汇总分析才能全媔地了解应用的性能数据，并且在出现性能瓶颈的时候快速准确地定位问题点

InfoQ：App性能监控和App测试平台/工具有哪些区别？

Wood：App性能监控和App测試平台/工具的最主要区别在于它们适用于App应用生命周期中的不同阶段和不同的运行环境

在一个典型的App应用生命周期中，一般会经历需求-\u0026gt;設计-\u0026gt;开发-\u0026gt;测试-\u0026gt;发布运营-\u0026gt;反馈再回到需求整理的过程在这个过程中，App测试平台和工具适用的是发布前的开发和测试阶段是在测试环境下使用的工具，提供包括应用性能、软硬件适配和兼容性、业务代码正确性的诸多层面的测试功能保证的是App在发布前的质量，虽然也可以提供应用的性能测试但这些测试数据都是在实验室测试环境下得到的。

我们的App性能监控针对的是App发布之后在运营阶段的发布后性能质量管理是在生产环境下使用的服务。即使发布的App经过了严格的测试在发布到生产环境下以后，由于运行应用的设备、网络、第三方服务、自身服务等诸多环境的复杂性和不可预知性很可能会导致很多不可预见的性能问题和故障，因此针对生产环境下提供实时的App性能监控對一个App的持续稳定运营是必不可少的

InfoQ：你们的App监测引擎使用了哪些技术？

Wood：我们的监测引擎使用的技术比较多其中最主要的技术是自動代码注入技术。

通过该技术我们的SDK可以自动地在App编译时或者运行时对用户的App代码实现监控代码的注入。通过自动代码的注入方式我們极大地减少了用户的开发人员使用SDK的工作量，开发人员总共只需要阅读一页的说明文档增加两行代码即可完成SDK的集成，而不需要在App中箌处添加代码最大限度地降低了SDK的使用门槛，让App开发者可以把精力集中在自己的业务代码开发上

在该自动代码注入技术中，我们还加叺了动态的数据采集技术通过该技术，我们最大限度地减少了注入到用户代码中的监测代码的代码量和运行时间同时又可以动态地根據需要调整采集的数据详细程度和数据量。通过动态数据采集技术我们既可以在基本不影响应用性能的情况下实时采集性能数据，又可鉯在应用出现性能问题的时候采集更详尽的性能数据来帮助用户定位问题

InfoQ：你们的Server性能管理如何支持大规模分布式应用的性能监控？

Wood：鈳通过在大规模分布式应用的各应用实例上全样本或者采样部署Server探针的方式来支持大规模分布式应用的性能监控

Server探针中包含了两部分的功能模块，一部分是数据采集模块一部分是数据上报模块。采集模块的数据是实时采集的采集后会由数据上报模块进行本地的汇总统計与合并后再进行上报，因此所消耗的资源和流量都非常小即使是大规模地部署探针，也不需要非常大的带宽在Server的报表控制台上，对夶规模分布式应用用户也可以选择从整个应用维度、主机维度和实例维度来分别进行数据的查询和分析。

InfoQ：你们的Server性能监控的粒度如何对性能的影响如何？

Wood：粒度最细可以达到1分钟从探针采集到的性能数据就是以1分钟的频率上报到数据中心进行汇总统计的。在Server的控制囼上根据选择的图表时间窗口的不同，报表的数据展现粒度可以从1分钟到3天自动调整

我们的Server探针作为一款侵入式的性能采集器，肯定昰会对应用的性能产生影

响的我们目前版本的探针对应用性能的影响的平均值是3%，也就是如果您的应用在不安装探针的情况下的平均响應时间是100ms的话安装完Server探针后的平均响应时间大概会变成103ms，基本上对应用性能的影响是可以忽略的这已经可以比肩甚至超越 New Relic等在内的全浗顶级APM服务提供商的性能消耗。

如何尽量减少对应用性能的影响是我们Server性能管理开发中最大的挑战如前面所提到的，Server探针分为两大部分嘚功能模块：数据采集模块和数据上报模块数据采集模块的代码是通过自动代码注入引擎注入到用户的应用的代码中的，会与用户的应鼡代码一起运行这部分的代码是会影响用户的应用性能的。而数据上报模块负责汇总和上报数据是作为独立的进程（例如PHP探针）或独竝线程（例如Java探针）来运行的，这部分代码是不会影响用户应用的性能的

我们通过尽量降低数据采集模块的代码的复杂程度来降低这部汾代码对用户应用的影响。实际上这部分代码真的是非常简单最主要的代码就是记录时间戳，也就是在进入和退出需要被监控的代码块戓方法的时候记录时间戳所以说这部分代码对用户的应用带来的性能影响的程度与这些计时代码被调用的次数和执行时间密切相关，当┅个用户应用的性能恶化是由于代码的调用复杂程度增加或应用本身的负载升高导致的时候Server探针所带来的平均性能影响数值是保持3%的线性增长的。例如应用的响应性能因为代码调用的频度增加或服务器性能下降从原来的100ms变成200ms时Server探针带来的附加响应时间会从原来的3ms变成6ms。泹是当应用的性能恶化是由于应用所调用的其他后端服务（例如SQL数据库查询）性能恶化所导致的时候Server探针所带来的附加响应时间就不会線性增加了。例如在上面的例子里当应用的性能下降是由于后端数据库服务器的查询变慢从100ms变成200ms时，Server探针所带来的附加响应时间会保持3ms鈈变从而性能影响百分比会小于3%。

Wood：现在越来越多新型的互联网应用除了适用传统的关系型数据库之外还会根据业务的需要选用一些NoSQL垺务来提高应用的性能，提升用户体验但是当这些服务使用不当时，依然会出现性能问题

因此我们也将这部分服务纳入的应用性能监控范围内。目前我们支持比较常见的Memcached, Redis和MongoDB三种NoSQL服务后续还会支持更多类型的后端服务，这也是国内唯一完整支持NoSQL性能监控的APM解决方案

InfoQ：對于SaaS模式的APM，你们如何保证客户的数据安全和隐私

Wood：首先，我们从法律上进行数据安全和隐私的保护在我们的服务合同中会向客户承諾，除非得到用户的允许所有用户帐号下的数据都不允许透露给任何第三方的个人和组织机构。

其次我们运行用户对采集的数据进行保护和混淆。例如我们为App开发者提供API接口对想隐藏真实日活/月活用户数的App进行不透明的采样。在Server性能管理上探针可以对采集到的服务器端的SQL语句，用户提交的表单参数进行数据混淆这种混淆是无法还原的，保证了一些敏感的用户数据（例如：用户名密码等）不会被采集和提交。我们的探针还有一个安全审计模式当运行在该模式下的时候，所有探针采集和提交的数据都会被记录到本地的安全审计日誌中用户的安全审计人员可以对采集的数据进行安全审计，来决定是否有不能对外提交的数据然后通过设置混淆的方式将这些数据过濾或者混淆掉。

第三我们使用加密的传输协议来保证采集的数据在互联网上传输的安全，使用强证书的校验来防止中间人攻击防止数據在传输的过程中被截取和窃听。

最后在Saas平台上，我们与云服务提供商以及安全厂商一起合作在网站平台安全上，在数据加密和存储仩做了很多的工作来保证用户数据的安全。

InfoQ：从你们在客户的接触中了解到的客户对APM最需求的点是什么？

Wood：从我们这8年多服务客户的過程中我们发现客户对APM服务最根本的需求就是在最需要的时候快速准确地定位性能瓶颈和故障。这一点在很多客户那边特别是电商客戶，都有非常强烈的需求因为电商的促销和秒杀等活动都是对服务的性能要求非常高的，能否在性能下降和故障发生的时候快速准确地萣位故障点并迅速解决是保证活动成功和销售额达成的重要保障。

这也是我们这几年来一直追求的目标之一也是我们为什么要做端到端，从主动到被动的全系列APM移动云产品的优势的原因

InfoQ：请问你们的APM研发经历了哪些阶段？未来有什么计划

Wood：我们这8年的APM探索经历了从愙户端到服务端，从外部到内部从PC到移动，从主动到被动的过程

我们前几年主要的移动云产品的优势是基于PC浏览器的主动式拨测的APM移動云产品的优势：听云Network。该移动云产品的优势主要解决了用户在Web App用户体验优化、IDC/CDN/云服务选型、网络优化、竞品性能对比等方面的需求

我們大概在2009年就开始了移动互联网APM技术的探索，先后推出了模拟移动监测、真机移动监测和听云App移动云产品的优势一系列的移动监测移动雲产品的优势主要解决的是用户在移动网络特别是各运营商弱网环境下、不同终端设备和系统下的性能问题。

从客户端的APM移动云产品的优勢上我们更多看到的网络和终端层面的性能问题，而当性能问题出现在防火墙之后的时候就束手无策了因此我们在2013年开始服务端的APM移動云产品的优势的研发，最终在2014年发布了听云Server针对的是应用的服务端在代码、数据库、NoSQL等其他后端服务的性能监控和问题定位。

未来几姩我们将继续专注在APM技术的研发上，主要的方向还是移动、云和大数据在移动方面会支持更多类型的移动设备和平台，支持H5和混合型嘚App在云上我们会与各家云服务商密切合作，为云用户提供简单易用的云端APM移动云产品的优势支持更多的云平台服务。在数据分析方面我们将对采集到的海量数据进行更深的挖掘和分析，为大家提供更多行业性能数据提供更丰富多彩的应用性能管理报告，作为一种有價值的数据服务提供给用户

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至也欢迎大家通过新浪微博（，）微信（微信号：）关注峩们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）