TLDR; RUM captures real user experiences directly from their browsers. Whereas, web checks simulate user experiences because they are monitoring from data centers, not actual browsers.
Subnet Mask Cheat SheetRecords Cheat SheetGeoDNS ExplainedFree Network TroubleshooterKnowledge BasePricing CalculatorLive CDN PerformanceVideo Demos
BlogsNewsPress ReleasesIT NewsTutorials
Give us your email and we'll send you the good stuff.
When it comes to DNS, there's nothing we love more - except DNS management. And maybe Secondary DNS. Or Failover. Even anomaly detection. Oh who are we kidding, if it's even remotely close to the topic of DNS, we got you covered!
RUM captures real user experiences directly from their browsers. Whereas, web checks simulate user experiences because they are monitoring from data centers, not actual browsers.
Synthetic monitoring relies on nodes that are located in data centers. These nodes attempt to simulate user experiences and will ping your servers and resources and record the response times. The thing is, your users aren't sitting in data centers.
Why, you ask, does this matter? A few reasons...
Without RUM, you're missing out on dozens, even hundreds of network hops that your users are relying on to reach your resources.
Now just because RUM gives you data on these "last mile" connections, doesn't necessarily mean you can do something about them.
But what it can do is give you insight into whether a long load time is your fault or an upstream provider.
Now, if you want to optimize your routing configurations based on your RUM data, you can use our new Traffic Steering service... you can read about it more here.
When I say "upstream" that means any network, data provider, or hosting service that your users depend on to reach your site.
For any given user, they will have to cross a handful, if not a dozen of these upstream networks to reach your site. That's dozens of chances for connection failure or latency.
RUM makes it easy for you to pinpoint latencies caused by a particular provider and then make the necessary updates to your routing configurations to avoid the issue.
Synthetic monitoring captures some of the same data, but it's stored in traceroutes. Traceroutes are text files that list all the network hops between a monitoring node (location) and your system. Each hop is labeled by an ASN (Autonomous System Number) which maps to an upstream provider.
Unless your monitoring service has visual traceroutes or automated Traffic Steering (we have both!), this can be a tedious task.
Visual traceroutes still use synthetic monitoring, but they can give you valuable insight into how your users are reaching your site.
Let's say you notice long load times from New York. You can run a traceroute from our monitoring node in New York to your website. We'll actually run five separate traces, which will usually return a few different paths.
As you can see, the orange line is the most used path with the fastest time. Most of the other traceroutes follow a similar path but veer off (and sometimes return) at different hops.
Both synthetic and RUM can be integrated with your DNS configurations. You can learn how to set them up on our Knowledge Base.
Synthetic monitoring captures data from nodes that are located in data centers. A typical monitoring network will have anywhere from 50 to a few hundred nodes.
Sounds like a lot, but those 50-100+ nodes will almost never cover all of the locations of your querying clients.
Since RUM data comes from your actual users, you're likely to canvas more of the locations and networks that your users are relying on to reach your resources. That means, not just more data... but more applicable data.
But what if your data set is small? You can use our RUM Community data to augment your existing data set.
*Please note: the Sonar RUM Community feature is still in beta.
Sign up for news and offers from Constellix and DNS Made Easy