TAG | EUM
Why End User Monitoring?
AppDynamics End User Monitoring enables application owners to:
- Monitor Their Global Audience and track End User Experience across the World to pinpoint which geo-locations may be impacted by poor Application Performance
- Capture end-to-end performance metrics for all business transactions – including page rendering time in the Browser, Network time, and processing time in the Application Infrastructure
- Identify bottlenecks anywhere in the end-to-end business transaction flow to help Operations and Development teams triage problems and troubleshoot quickly
- Compare performance across all browsers types – such as Internet Explorer, FireFox, Google Chrome, Safari, iOS and Android
“Fox News already depends upon AppDynamics for ease-of-use and rapid troubleshooting capability in our production environment,” said Ryan Jairam, Internet Operations Lead at Fox News. “What we’ve seen with AppDynamics’ End-User Monitoring release is an even greater ability to understand application performance, from what’s happening on the browser level to the network all the way down to the code in the application. Getting this level of insight and visibility for an application as complex and agile as ours has been a tremendous benefit, and we’re extremely happy with this powerful new addition to the AppDynamics Pro solution.”
EUM Cloud Service
EUM (End User Monitoring) Cloud Service is our on-demand, cloud based, multi-tenant SaaS infrastructure that acts as an aggregator for the entire EUM metrics traffic. All the EUM metrics from the end user browsers from different customers are reported to EUM Cloud service. The raw browser information received from the browser is verified, aggregated, and rolled up at the EUM Cloud Service. All the AppDynamics Controllers (SaaS or on-premise) connect to the EUM Cloud service to download metrics every minute, for each application.
On-Demand highly available
End users access customer web applications anywhere in the world and any time of the day in different time zones, whenever an AppDynamics instrumented web page is accessed. From the browser, EUM metrics are reported to the EUM Cloud Service. This requires a highly available on-demand system accessed from different geo locations and different time zones.
Extremely Concurrent usage
All end users of all AppDynamics customers using EUM solution continuously report browser information on the same EUM Cloud Service. EUM Cloud Service processes all the reported browser information concurrently and generate metrics and collect snapshot samples continuously.
The usage pattern for different applications throughout the day is different; the number of records to be processed at EUM Cloud vary with different applications at different times. The EUM Cloud Service automatically scale up to handle any surge in the incoming records and accordingly scale down with lower load.
Multi Tenancy support
The EUM Cloud Service process EUM metrics reported from different applications for different customers; the cloud service provides multi-tenancy. The reported browser information is partitioned based on customers and their different applications. EUM Cloud Service provides a mechanism for different customer controllers to download aggregated metrics and snapshots based on customer and application identification.
The EUM Cloud Service needs to be able to dynamically scale based on demand. The problem with supporting massive scale is that we have to pay for hardware upfront and over provision to handle huge spikes. One of the motivating factors when choosing to use Amazon Web Services is that costs scale linearly with demand.
The EUM Cloud Service is hosted on Amazon Web Services infrastructure for horizontal scaling. The service has two functional components – collector and aggregator. Multiple instances of these components work in parallel to collect and aggregate the EUM metrics received from the end user browser/device. The transient metric data be transient is stored in Amazon S3 buckets. All the meta data information related to applications and other configuration is stored in the Amazon DynamoDB tables.
The functionality of the nodes is to receive the metric data from the browser and process it for the controller:
- Resolve the GEO information (request coming from the country/region/city) and add it to the metric using a in-process maxmind Geo-resolver.
- Parse the User-Agent information and add browser information, device information and OS information to the metrics.
- Validate the incoming browser reported metrics and discard invalid metrics
- Mark the metrics/snapshots SLOW/VERY SLOW categories based on a dynamic standard deviation algorithm or using static threshold
For maximum scalability, we leverage Amazon Web Services global presence for optimal performance in every region (Virginia, Oregon, Ireland, Tokyo, Singapore, Sao Paulo). In our most recent load test, we tested the system as a collective to about 6.5 B requests per day. The system is designed to easily scale up as needed to support infinite load. We’ve tested the system running at many billions of requests per day without breaking a sweat.
Check out your end user experience data in AppDynamics
Find out more about AppDynamics Pro and get started monitoring your application with a free 15 day trial.
As always, please feel free to comment if you think I have missed something or if you have a request for content in an upcoming post.Link to this post:
Web application performance is fundamentally associated in the mind of the end user; with a brands reliability, stability, and credibility. Slow or unstable performance is simply not an option when your users are only a click away from taking their business elsewhere. Understanding your users, the locations they are coming from, and the devices/browsers they are using is crucial to ensuring customer loyalty and growth.
Today’s modern web applications are architected to be highly interactive, often executing complex client side logic in order to provide a rich and engaging experience to the user. This added complexity means it is no longer good enough to simply measure the effects users have on the back-end. It is also necessary to measure and optimize the client-side performance to ensure the best possible experience for your users.
Let’s take a look at a few of the key features available in AppDynamics 3.7 which simplify troubleshooting these problems.
End User Experience dashboard:
The first view we will look at reports EUM data by geographic location showing which regions have the highest loads, the longest response times, the most errors, etc.
- A main panel in the upper left that displays geographic distribution on a map or a grid
- A panel on the right displaying summary information: total end user response time, page render time, network time and server time
- Trend graphs in the lower part of the dashboard that dynamically display data based on the level of information displayed in the other two panels
The geographic region for which the data is displayed throughout the dashboard is based on the region currently showed on the map or in the summary panel. For example, if you zoom down from global view to France in the map, the summary panel and the graphs display data only for France.
This view is key to understanding the geographical impact of any network & CDN latency performance issues. You can also see which are the busiest geographies, driving the highest throughput of your application.
Browsers and Devices:
From the Browsers and Devices tabs you can see the distribution of devices, browsers and browser versions providing an understanding of which are the most popular access mechanisms for the users of your application and geographic-split by region. From here we can isolate if a particular browser or device is delivering a reduced experience to the end user and help plan the best areas for optimisation.
Troubleshooting End User Experience:
Response time metric breakdown
First Byte Time is the interval between the time that a user initiates a request and the time that the browser receives the first response byte.
Server Connection Time is the interval between the time that a user initiates a request and the start of fetching the response document from the server. This includes time spent on redirects, domain lookups, TCP connects and SSL handshakes.
Response Available Time is the interval between the beginning of the processing of the request on the browser to the time that the browser receives the response. This includes time in the network from the user’s browser to the server.
Front End Time is the interval between the arrival of the first byte of text response and the completion of the response page rendering by the browser.
Document Ready Time is the time to make the complete HTML document (DOM) available.
Document Download Time is the time for the browser to download the complete HTML document content.
Document Processing Time is the time for the browser to build the Document Object Model (DOM)
Page Render Time is the time for the browser to complete the download of remaining resources, including images, and finish rendering the page.
AppDynamics EUM reports on three different kinds of pages:
- A base page represents what an end user sees in a single browser window.
- An iframe is a page embedded in another page.
- An Ajax request is a request for data sent from a page asynchronously.
Notifications can be configured to trigger on any of these.
If the above isn’t enough and you want to look into the execution within the datacentre, you can drill in-context from any of the detailed browser snapshots directly into the corresponding call stack trace in the application servers behind. This provides end-to-end visibility of a user’s interaction with your web application, from the browser all the way through the datacentre and deep into the database.
Deployment and scalability:
If you don’t currently know exactly what experience your users are getting when they access your applications or your users are complaining and you don’t know why then why not checkout AppDynamics End User Monitoring for free at appdynamics.comLink to this post:
Some companies talk about monitoring their end user experience and other companies take the bull by the horns and get it done. For those who have successfully implemented EUM (RUM, EUEM, or whatever your favorite acronym is) the technology is rewarding for both the company and the end user alike. I recently had the opportunity to discuss AppDynamics EUM with one of our customers and the information shared with me was exciting and gratifying.
ManpowerGroup monitors their intranet and internet applications with AppDynamics. These applications are used for internal operations as well as customer facing websites; in support of their global business and accessed from around the word, 24×7. We’re talking about business critical, revenue generating applications!
I asked Fred Graichen, Manager of Enterprise Application Support, why he thought ManpowerGroup needed EUM.
“One of the key components for EUM is to shed light on what is happening in the “last mile”. Our business involves supporting branch locations. Having an EUM tool allows us to compare performance across all of our branches. This also helps us determine whether any performance issues are localized. Having the insight into the difference in performance by location allows us to make more targeted investments in local hardware and network infrastructure.”
Turning on a monitoring tool doesn’t mean you’ll automagically get the results you want. You also need to make sure your tool is integrated with your people, processes, and technologies. That’s exactly what ManpowerGroup has done with AppDynamics EUM. They have alerts based upon EUM metrics that get routed to the proper people. They are then able to correlate the EUM information with data from other (Network) monitoring tools in their root cause analysis. Below is an EUM screen shot from ManpowerGroup’s environment.
By implementing AppDynamics EUM, ManpowerGroup has been able to:
- Identify locations that are experiencing the worst performance.
- Successfully illustrate the difference in performance globally as well. (This is key when studying the impact of latency etc. on an application that is being accessed from other countries but are located in a central datacenter.)
- Quickly identify when a certain location is seeing performance issues and correlate that with data from other monitoring solutions.
But what does all of this mean to the business? It means that ManpowerGroup has been able to find and resolve problems faster for their customers and employees. Faster application response time combined with happier customers and more productive employees all contribute to a healthier bottom line for ManpowerGroup.
ManpowerGroup is using AppDynamics EUM to bring a higher level of performance to it’s employees, customers, and shareholders. Sign up for a free trial today and begin your journey to a healthier bottom line.Link to this post:
Round Two – Last time I wrote a blog comparing APM versus network-based APM tools, which I still consider NPM at it’s core regardless of what some critics and competitors claim. Let me make one thing clear though, NPM is great for equipping IT network administrators to see how fast or slow data is traveling through the pipes of their application. Unfortunately, network-based APM tools simply cannot provide App Ops granular visibility into the application runtime when isolating bottlenecks go beyond the system level and it’s final destination – the end user’s browser.
I find several of the blogs and YouTube clips from such NPM vendors quite comical as they try to throw punches at APM companies. Their arguments are centered primarily against agent-based approaches being an inadequate APM solution due to today’s fickle and distributed application architectures. It’s not like I haven’t heard it before.
The amusing thing about it…they’re completely right! In fact, we couldn’t agree more, and that’s why Jyoti Bansal founded AppDynamics to address these perennial shortcomings legacy APM vendors have been ignoring. Even the smallest businesses next to the largest enterprises have complex applications that have outpaced their App Ops teams’ current set of monitoring tools. That’s why AppDynamics is reinventing and reigniting the application performance management space by enabling IT operations to monitor complex, modern applications running in the cloud or the data center. So let me respond to those claims they’ve made.
“Agents have high deployment and ongoing maintenance burden.”
Legacy APM: TRUE
AppDynamics: FALSE. No manual instrumentation required. It’s automatic.
“Agents are invasive which can perturb the systems being monitored.”
Legacy APM: TRUE
AppDynamics: FALSE. Our customers see less than 1-2% overhead in production.
All AppDynamics. The next-gen of APM.
I drew a parallel in my previous post that using NPM concepts to monitor application performance is like inspecting UPS packages en-route to figure out why operations at a hub came to a screeching halt. Remember, even if the package contents is visible from afar, it doesn’t explain why the hub conveyors, which electronically guide packages to their appropriate destination chute is broken, nor can it identify why cargo operations have stalled. In other words, good luck trying to gather anything beyond the scope of the application’s infrastructure. Using network monitoring tools to collect even the most basic system health metrics such as CPU utilization, memory usage, thread pool consumption and thrashing? Time to throw in the towel.
And what about End User Monitoring?
What’s becoming just as important as being able to monitor server side processing and network time is the ability to monitor end user performance. When NPM tools are only able to see the last packet sent from the server, how does that help you understand the browser’s performance? It doesn’t since once again, this kind of analysis is only feasible higher up the stack at the Application Layer. And just to clarify when I say Application Layer, I mean application execution time, not “network process time to application” as defined by OSI Layer 7.
On top of that, what about those customers running their applications in a public cloud? Are you going to convince your cloud provider to install a network appliance into their infrastructure? I highly doubt it. With AppDynamics, we have partnerships with cloud providers such as Amazon EC2, Azure, RightScale and Opsource allowing developers and operations to easily deploy AppDynamics with a flick of a switch and monitor their applications in production 24/7.
Once again, next-gen APM triumphs over NPM based application performance on not just the server side, but also the browser. AppDynamics is embracing this and fully aware of the technical and business significance of monitoring end user performance. We’re delighted to offer this kind of end-to-end visibility to our customers who will now be able to monitor application performance from the end users’ browser to the backend application tiers (databases, mainframes), all through a single pane of glass view.Link to this post: