因而感知真实用户体验(Real User Experience)，将用户访问量，每个页面访问量的变化，应用的错误率，平均响应时间等指标作为网站运营的基本 KPI 已经是势在必行。利用真实用户体验工具对应用、网站进行性能检测和业务分析已经成为运营一个对外提供服务的应用的基础要求。真实用户体验监测(Real User Experience Monitoring)通过采集应用或者网站的全部访问数据，记录每个用户与网站的交互，从而完成用户终端类型分析，用户访问量分析，不同页面功能访问量分析，不同页面功能的平均响应，错误率等指标分析等。
真实用户体验工具有不同的实现方案：日志，浏览器端脚本嵌入，移动 APP 的 SDK 插码，交换机镜像流量数据采集等。如果应用由多个应用开发商合作完成，日志和移动 APP SDK 形式的真实用户体验分析对应用的开发提出了较高的要求。浏览器插码方式对于代码书写不规范的应用又存在一定风险。相比较来说采用交换机镜像流量采集的方式既安全又省心。
与脚本植入或者 SDK 形式的数据采集不同，旁路方式无法感知用户的动作，无法明确区分页面、页面元素与 AJAX 的关系。所以一般的旁路式 RUM 产品要么是逃避这个问题采用只按照 URL 进行性能统计的方式，这种方式不区分页面和页面里的资源以及 AJAX 调用，这种方式对故障排查有一定价值，但却不能体现用户的真实体验而且完全没有将客户端设备的卡顿和网络耗时计算在内,通过这个方式统计出来的应用平均响应时间比用户体验到的达到降低。 高级些的 RUM 产品能够推算出页面与元素之间的关联关系，但需要客户指定一个页面的最后一个元素，从而将异步 AJAX 请求排除在用户响应时间之外，但是现代应用大部分都使用了 AJAX 调用，每个页面都如此配置对使用和实施人员来说太费时间。
OneAPM NI 基于旁路镜像数据的真实用户体验监控 技术分享
OneAPM NI 通过分析浏览器与服务器之间的报文字段，根据 Session，页面之间的关联关系，页面与 AJAX 调用的时间关系等推算出页面的构成以及与异步 AJAX 请求间的关系，从而能够计算出与用户在浏览器端发送页面请求到看到页面全部内容非常接近的用户响应时间值。
OneAPM NI 首先将 URL 调用根据内容类型区分为页面和 WebService 调用。只有页面类型的才纳入用户体验的计算范畴。一个页面是由一个 URL 群构成，包含静态资源，脚本和 AJAX 调用。页面的耗时是从页面的第一个元素请求开始到最后一个元素下载结束之间的时间。这个过程包含了浏览器对中间元素的处理时间，它与在浏览器端看到的时延差异在于没有将浏览器对最后元素的渲染时间计算在内。有了 Ni 的页面及元素瀑布图后，我们就可以对用户侧缓慢的问题做基础的判断，判断性能问题发生在哪个应用，哪个页面，哪个元素，在网络侧，应用侧还是浏览器侧。
本文系 OneAPM 工程师编译整理。OneAPM 能为您提供端到端的应用性能监控解决方案。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
]]>OneAPM 自2016年9月9日起，不再提供 Ai、Bi、Mi、Ct 的无限制、无期限的免费版使用。新用户还可以通过试用方式享受15天免费使用。如果您需要继续使用 OneAPM 产品，请点击这里申请购买（值此OneAPM [股票代码：838699] 新三板挂牌之际，公司推出了优惠活动）或者延长试用期，我们会尽快给您答复。
产品的具体调整方案如下：
产品
新用户
老用户
Ai
有15天试用期，到期付费使用
2016年9月9日起停止免费使用，付费继续使用
Bi
申请试用或直接购买使用
2016年9月9日起停止免费使用，付费继续使用
Mi
有15天试用期，到期付费使用
2016年9月9日起停止免费使用，付费继续使用
Ct
有15天试用期，到期付费使用
2016年9月9日起停止免费使用，付费继续使用 ]]>
.NET Core 5 中的一系列网络 API 是由 Win 8.1 版 Windows Store 应用开发者使用的 API 演进而来的(点此查看 MSDN API 参考指南)。正如会上所强调的，将 App 移植到 .NET Core 和 UWP 上，意味着开发者可以使用相同的代码库在 Xbox 、 Windows Phone 、 Windows 和 HoloLens 等平台实现同一应用。当然，你仍可以使用 Windows 8.1 应用商店中的全部 .NET 网络 API （外部 API 不存在被删除或弃用的状况）。
如果比较 .NET Framework 与 .NET Core ，我们会发现：尽管 .NET Core 中的大部分外部 API 与之前 .NET Framework 版的相同，但这些 API 的底层实现已经发生了显著变化，我们也通过此次版本迭代实现了网络 API 部署的现代化 ，使之更适用于 Windows 应用商店中的 App 。在本文中，我们会列举 UWP 开发人员可用的全部 .NET 网络 API ，并介绍其实现原理。
请注意：本文所讨论的 API 及其变化仅适用于开发 UWP App 的 .NET Core ，并不适用于 .NET Framework 4.6 版本。我们同样致力于优化 .NET Core 网络 API 以更好地支持服务器平台（如 ASP .NET 5 ），这些内容将在另一篇博客中单独介绍。同样，本文也不会介绍 Windows 应用开发者不可用的 .NET 网络 API 。
新的内容
以下为 .NET Core 5 中为 UWP 应用开发者新加的 API 与功能。
System.Net.Sockets
在 Windows 10 和 .NET Core 5 中，System.Net.Sockets 被添加到用于 UWP 应用开发的 API Surface 中。这是 Windows Store 应用期待已久的 API（ Windows Phone Silverlight 应用程序早已使用了此接口），它包含了System.Net.Sockets.Socket和System.Net.Sockets.SocketAsyncEventArgs之类的变量，可用于异步套接字通信开发。在 .NET Core 中，System.Net.Sockets现有的 API Surface 基于 Phone 8.1 Silverlight 中的 API ，并继续支持大多数的类型、属性和方法（删除了一些被认为已经过时 APIs ）。展望未来，我们计划扩大 API Surface 以支持该命名空间下的更多类型--请参考下面的展望部分。
System.Net.Sockets API 的实现方式已经显著改变，以便消除对不属于 .NET Core 的 API 的依赖，同时使用与 WinRT API 一样的底层线程 API 。我们的目标是确保旧版的部署与新版 .NET Core 间的功能对等。如果你在移植 Sockets 代码到 UWP 时出现任何步骤或者性能上的差异，请在GitHub及时向我们反馈。
System.Net.Http 得到 HTTP/2 支持
开发者在 Windows 10 或.NET Core 5 上编写 UWP 应用时，在使用System.Net.Http.HttpClient时可获取 HTTP/2 协议支持。 HTTP/2 是 HTTP 协议的最新版本，通过最小化连接和往返信息的数量提供了低延迟的网络访问方式。在 HttpClientAPI 中使用该协议意味着服务器响应更快，应用程序在相同的网速下运行更加流畅。最棒的是——该功能默认生效的，无需对代码做任何改动即可使用之。了解 HTTP/2 实现 App 更快网络访问的细节，请参考 Build 2015 会上的演讲。该演讲还演示了一个图片下载的简单应用，在切换到 HTTP/2 后达到 200%的延迟提升（ demo 视频）。
下面一段代码显示了如何查询客户端的 HTTP 版本偏好以及实际用于连接的 HTTP 版本：
var myClient = new HttpClient();
var myRequest = new HttpRequestMessage(HttpMethod.Get, "http://www.contoso.com");
// This property represents the client preference for the HTTP protocol version.
// The default value for UWP apps is 2.0.
Debug.WriteLine(myRequest.Version.ToString());
var respOnse= await myClient.SendAsync(myRequest);
// This tells if you if the client-server communication is actually using HTTP/2
Debug.WriteLine(response.Version.ToString());
注释：
其他 .NET 平台并不支持将
Request.Version属性值设置为 2.0 ，当该请求发出时会抛出System.ArgumentException异常。除 UWP 外的其他 .NET 平台默认版本为 1.1 。Request.Version属性表示客户端 API 优先使用 HTTP/2 协议。实际使用的 HTTP 版本取决于客户端操作系统、服务器和中间代理。 HTTP/2 是一个协商协议，如果服务器或者中间代理不支持该协议，将会回退为 HTTP 1.1 版本。
改动的内容
在这一节中，我们将回顾 Windows Store 开发人员之前使用过的 API ，在新版中起底层实现已经发生了显著变化。理解这些变化将会帮助你以一个开发者的视角，洞悉应用程序从 Windows 8.1 Store App 移植到 Windows 10 UWP 的过程中发生的代码改动。
System.Net.Http
在 Windows 8.1 中， HttpClient的实现基于 HTTP 协议栈，其包括的类型有System.Net.HttpWebRequest 和System.Net.ServicePointManager等。在 .NET Core 中，该部分由全新的、轻量级包装类替代，后者基于原生 Windows OS HTTP 组件，例如基于 WinINet.aspx)的Windows.Web.Http。因此，我们能够利用操作系统的最新功能（例如： HTTP/2 ），同时以更快的速度将这些新功能提供给 .NET 开发人员。此外，运行在 Windows 10 上的 .NET 应用在内存消耗更低，用户在运行多个应用时也能获得更为流畅的体验。此文档所记录的 System.Net.Http 中的可用 API 集保持不变。
新的实现方案已经通过测试以确保与之前 Windows 8.1 的实现功能对等，所以开发人员在将 HTTP 客户端代码移植到 UWP 时， API 行为不会有任何差异。然而，如果你发现任何问题或者 Bug 时，请在GitHub上提交给我们。
System.Net.Requests
System.Net.Requests库包括 与System.Net.HttpWebRequest 、 System.Net.HttpWebResponse类相关的类型，开发人员可以利用这些类型实现 HTTP 协议的客户端功能。.NET Core 5 的 API Surface 与适用于 Windows 8.1 应用的 API 一致，这些接口相比于 .NET Framework 的外部接口限制更多。这是有意设置的，我们强烈建议大家使用 HttpClient API--这是我们将会集中精力，创新前进的方向。 .NET Core 5 的其他部分，诸如 Windows Communication Foundation （ WCF ）也已经迁移到 .NET Cores 实现的 HttpClient ，点击此处查看概述。
提供该库的目的是保证向后兼容性，让使用旧 API 的 .NET 库也能使用。对 .NET Core 来说，HttpWebRequest的部署实际上基于HttpClient（与 .NET Framework 中的依赖顺序相反）。正如前文所述，这样做是为了避免在 UWP 应用开发语境中使用受管理的 .NET HTTP 堆栈，同时将HttpClient转变单个 HTTP 客户端的 API 。
不变的内容
Windows 8.1 Store 应用支持的 System.Net和System.Net.NetworkInformation命名空间中的其他类型在 UWP 应用依旧可用。这些 API Surface 有少量添加项，但其实现方式并没有大的变化。
展望未来
本文，我们讨论了为 Windows 10 UWP 应用开发人员提供的首版 .NET 网络 API 。我们将继续完善这些接口、加入新的外部 API ，以确保开发人员能够使用 .NET 编写丰富、功能齐全的 UWP 应用程序。
为了确保我们优先开发的重点 API 是大众所需的，请让我们知道你的反馈--请及时告诉我们 .NET Core 中遗漏的 API ，以及在使用 UWP 应用时影响你体验的因素。请在GitHub上创建或投票表决Windows platform missing APIs uservoice ，也可以留下您的问题。我们期待与您合作来开发兼容性更好的优质应用。
原文链接： http://blogs.msdn.com/b/dotnet/archive/2015/07/28/net-networking-apis-for-uwp-apps.aspx
OneAPM 助您轻松锁定 .NET 应用性能瓶颈，通过强大的 Trace 记录逐层分析，直至锁定行级问题代码。以用户角度展示系统响应速度，以地域和浏览器维度统计用户使用情况。想阅读更多技术文章，请访问 OneAPM 官方博客。
]]>1月29日，国内APM（应用性能管理）第一品牌OneAPM正式开始OneAPM For PHP版本的公测，成为国内首家支持PHP的APM解决方案提供商。
OneAPM For PHP通过 SaaS向用户提供统一的入口、友好的界面、便捷的流程来管理和监控应用程序的性能，并完成从前端、到网络、直至应用代码的端到端应用性能管理，可以随时随地查看运维状态。
APM是近年来比较热门的一个领域，对于开发者来说，每一行代码性能怎样、API接口的响应时间是不是够快、一个网页的加载速度是否在用户可接受的范围之内，这些都是需要进行监管的。对于各类网络产品来说，监测并提升自身的应用性能，十分必要。
目前，OneAPM已经支持的开发语言有Java 、.NET、Python、Node.js等，适用于所有主流语言和平台。此次开发出针对PHP的版本，也是看好PHP应用广泛，希望能给国内数量庞大的PHP开发者提供优质服务。
OneAPM For PHP所解决的关键问题
-当在PHP崩溃的时候得到报警；-排查PHP应用运行缓慢问题的原因
-需要调教应用程序性能；需要函数级别的性能数据
-想要摆脱传统的命令行应用监控性能，进行对性能的可视化监控等时
-其他性能问题
功能亮点一：分布式事务追踪
OneAPM能在分布式环境中，通过逐层追溯交易流程，快速定位性能瓶颈-合理化的事务交易追溯流程，简单、便捷地追踪事务瓶颈
-健全的数据展示，帮助您直指问题核心。
-网络拓扑图自动建模，全方位掌握事务交易流程。
-总览应用实时性能曲线，迅速感知应用性能指数。
功能亮点二：代码级别深度追踪
OneAPM能以小于2%的性能消耗，进行代码执行情况跟踪及可视化，无需手动配置-针对SQL语句的性能诊断，不仅涵盖执行时间，还包括调用参数；不仅可以按照SQL语句逐条进行诊断，也可以结合事务和SQL语句类型进行性能诊断。
-针对JVM的诊断，从CPU消耗到内存使用，和垃圾回收，以及类装载信息，可以全方面了解Java TM应用程序性能。
-深度追踪错误信息，实现代码级别的性能监控。
-根据不同的应用程序，自定义关键事务，随时跟踪最重要的事务，达到更高的投资回报率。
总的来说，OneAPM for PHP 不仅能够深入到所有 PHP 应用内部完成应用性能管理和监控，包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。还可以追溯性能问题至各个环节，包括：性能表现差的 SQL 语句 Traces 记录、性能表现差的第三方 API、Web 服务、Cache 等等。
注：公测版本在OneAPM官网（www.oneapm.com）开放下载，公测开放期间，写测评报告还可获得OneAPM提供的小米手环等新春礼物。
（下载链接： http://www.oneapm.com/features/php.html注册之后按照步骤添加PHP应用即可）
]]>首先你要在他们的网站注册一个新账号，将它的jar包下载下来。然后根据JVM的不同大概会有一些区别，以TOMCAT来说，就是在bin目录里的catalina.sh中多加入JAVA_OPT。
-javaagent:/path-to/plumbr.jar 然后再重启的时候将这个jar包带起来，从而实现对数据的抓取。
PLUMBR的支持范围：
| JDK | Version |
|---|---|
| Oracle HotSpot | 6, 7 and 8 |
| Open JDK 6 and 7 | 28 |
| Server | Version |
|---|---|
| Jetty | 6, 7 and 8 |
| JBoss | 7+ |
| WebLogic | 8+ |
| Tomcat | 6+ |
| Glass-fish | 4+ |
基本上包括了主流的jvm系统，还是支持的蛮全的。支持的语言当然只有JAVA，不过在它官网是这么说的：
Although officially Plumbr supports only Java, we encourage all users of other JVM-based languages – such as Groovy, Jython, JRuby, Clojure, Scala etc – to give it a try and let us know about the test results. This will help us further broaden the list of supported environments.
反正他也不知道能不能支持，你可以试试看~~
它抓取的信息包括以下内容：
对于操作系统，JVM设置和启动参数，通过RuntimeMXBean和System.getProperties接口获得的数据。
关于garbage collection events的信息 - gc的频率，收集时间，释放内存等量
有关对象分配的统计信息。信息是基于分配点进行收集的，包括类名和根据类名创建的对象和创建对象的代码行。
事件报告的数据。内存泄漏，事故报告包含对象计数，占用的空间，分配点（包括类名称和代码行）和线程的堆栈跟踪。
总结来说就是，JVM的设置，GC的log，和基于堆栈信息拉出来的对象信息。
成功部署以后，进入的页面非常的简洁：
首先关注的是堆内存的使用情况，是否有泄漏，泄露的话会通过leaksize绘出红色的泄露情况。
从图表上可以看出我现在的内存还是没有泄露的。图表右上角有一个threshold，可以设置阀值，一旦发现有泄漏的情况就给你发报警邮件。
http://i.imgur.com/bDZl3Nh.jpg
第二个图表是GC回收时间，从这里可以看到你每次GC的回收时间是多少，还是通过右上角的设置自定义你觉得多长时间是长GC，这里由于我设置的事1MS，所以几乎每次GC都被当做成了长GC.
第三个图表示是对线程锁的监控，从这里可以看出这一小时内你的锁的数量和时间，是否存在超长时间的锁。
对于上述图表出现的问题，plumbr会详细记录每一次问题的情况，以便用户查找。
http://i.imgur.com/4ImD5bQ.jpg
对于每一个问题，它还有详细的描述，包括问题发生的机器，时间，造成问题的原因，问题发生的对象和方法等等，甚至有一些常见的问题，它还能告诉你怎样修复它。这可以说是它最吸引我的地方。
附上一个它对我memory leak诊断的链接：
https://portal.plumbr.eu/shared#/incident/188484?token=wgy4UKRNk13Wvt7-ZWzy1cH__Eg
不只是memory leak，对长GC和锁它好像也要有所诊断，不过因为是付费版提供的功能所以就不太清楚了。
链接： http://wenku.baidu.com/view/9ae5ad232b160b4e777fcf2d.html
]]>[本周成果] ：
1. 应用隐藏功能
大家不用再为多出来的测试应用感到烦恼，OneAPM提供隐藏功能，方便您隐藏暂时不需要监控的应用。 2. 更换工单服务商
不少同学都在抱怨为啥OneAPM的工单系统最近访问非常慢，我们只能说是因为GFW！为了彻底解决这个问题，我们重新选择了国内的工单服务商，以期待给用户带来更好的体验！欢迎大家使用。 [本周推荐] ：
报警功能
OneAPM的报警功能最近刚刚重构优化了，当然因为我们一向低调的原因可能这个优化的好处可能只有在使用的同学们才知道，so你要不要也试试？ 本次更新了一些新功能，对已有功能进行了大量体验上的完善。
更新级别：
高级
更新时间：
2014年11月14日
更新详细说明：
新增报警功能，您再也无需时常担心您的系统是否正常，OneAPM使用科学有效地方式发送报警信息，随时随地掌握应用程序现状。更多详情请参见： https://oneapm.kf5.com/posts/view/5254/
JAVA探针新增支持1.7和1.8版本的JDK。
持续优化整个UI界面，更加简洁和流畅的体验：
- 图标扁平化
- 图表卡片化
三级层次设计，主次分明，将不常用的第一级进行缩进。
大幅优化访问速度，尤其是在展现用户7到15天数据这个层面上。
重新优化了数据展示，从用户角度出发，展示用户更关心，更易理解的数据。
