摘要：RUM的工作名副其实:它观察的是网站的真实访客，记录访客打开页面的速度，然后生成报表
RUM的工作名副其实:它观察的是网站的真实访客，记录访客打开页面的速度，然后生成报表。
从这点来看，RUM会告诉你系统是否出问题了，因为你可以通过RUM发现问题以及速度变慢的情况，这些情况你没有进行测试，从而也就不知道是否存在。
何时使用RUM
RUM工具生成两种报表，每种都可以帮助你测量性能及诊断问题。
单个访客报表
有了这样的报表，就像每个访客都有Firebug一样，你可以对用户的访问进行回放，复查每个页面和每个对象，也可以针对单个错误生成报警(例如，“假如用户得到了一个HTP500错误，则给我发邮件”)。
集合报表
这些报表针对所有访客显示发生了什么一哪些页面最慢、哪些对象出现的错误最多等。可以基于聚合数据和时间段生成报警(例如，“如果5分分钟之内平均页面延迟时间间超过5秒钟，则发送一个SNMP陷阱”)。
常见的RUM用例包括
●复查问题会话，以诊断网站的技术问题。
●对网站真实访客生成服务水平报表，特别是在运行一个软件作为服务(Sas)的系统时。识别出那些可能需要更多规范监控的部分。
●对于无法使用综合方式进行测量的部分，如付款页面等，测测量其健康状况
遇到问题即时报警，而不是采用间隔方式，到点儿才报。
RUM的局限
虽然综合工具都大同小异，但客户端的RUM工具，和服务器端的相比，是有很大区别的。前者依赖于AAX脚本或者嵌入的代理代码(agentcode)，在终端用户访问网站时，采集他们的信息；后者使用服务器日志、负载均衡器或者网络窃听器从数据中心收集访客信息。
客户端RUM在浏览器中观察用户体验，所以能够测量像客户端渲染等的延迟。可惜的是，由于只有在页面成功加载并且在浏览器上运行的时候，客户端RUM才能够加载，所以就无法检测导致其自身无法加载这样的错误，而且也可能与某些客户端不兼容。更进一步说，因为RUM是在浏览器的沙箱里运行的，所以也就无法看到更为低层的数据，像包丢失情况，也无法计算用户访问第一个页面时的主机延迟。
服务器端的RUM的问题正相反。因为独立于浏览器，所以能看到发生的任何事情的详细情况一一甚至是失败的TCP连接次数，然而却看不到浏览器中发生的情况。或许更重要的是，因为服务器端的RUM需要访问网络与日志，以及某些情况下的各个物理网络，所以对于托管或基于云计算的环境，就无法部署了。许多商业化的RUM解决方案结合了客户端及服务器端的采集方式来解决这个问题。
配置RUM
有两个基本步骤来配置RUM工具。首先，训练工具以理解网站的流量模式，然后告诉工具监视哪些重要的内容。
按照定义，一个RUM工具应该能捕提所有进出服务器的流量。对工具进行训练是必要的，因为每个网站都是不同的。对工具进行训练涉及到下面的步骤。
1.剔除不需要的流量。
某些流量你可能不需要。像网站机器人(bots)、其他的监控工具、网络服务调用以及防火墙之内的流量，所有这些都会让你曲解终端用户的体验。
2.告诉系统如何追踪单个用户。
所有网站都会使用某种东西来识别单个访客，不管是会话cookie还是URL参数，甚至是IP地址。但在某些RUM实现中一一特别是那些使用客户端脚本的一这些是不需要的，因为脚本实例运行在每个访客的浏览器中。
3.告诉系统如何组装页面。
知道一个页面在哪里结束以及另一个页面在哪里开始，是需要技巧的。有些页面在加载以后可能还会有异步通信(如GoogleSuggest，用户在搜索框中输入内容时，GoogleSuggest会基于这些内容显示建议)。RUM工具需要知道什么东西组成了页面的开始与结束，这对于合理地计时以及计算页面数都很重要
4.识别错误。
虽然每个网站都有一些基本的错误类型(如HTTP500)，但也会有一些定制的页面，看起来跟正常页面一样，但却是出错页面。
一旦工具理解了怎样才算是一次访问，以及如何测量延迟，你就可以告诉它要监视些什么。多数RUM工具在开始时都会有默认的参数:页面、用户、城市以及服务器都是用来切割数据的好方法，都会向你显示哪些最慢，或者哪些出错最多。
由于RUM工具要处理大量信息，所以往往只向你显示高层次的数据，除非你特别要求做钻取，例如，进入到网站建设的刚刚发布的那部分，或者显示一个特定的高价值客户。一般来说，每个数据区段都可以用来生成报告，以及产生报警或邮件通知。
平面设计相关资讯推荐阅读：