Wolfgang Gottesheim About the Author

Wolfgang has several years of experience as a software engineer and research assistant in the Java enterprise space. Currently he contributes to the strategic development of the Compuware dynaTrace enterprise solution as a Technology Strategy in the Compuware APM division’s Center of Excellence. He focuses on monitoring and optimizing applications in production. Find him at @gottesheim

APM as a Service: 4 Steps to Monitor Real User Experience in Production

With our new service platform and the convergence of dynaTrace PurePath Technology with the Gomez Performance Network, we are proud to offer an APMaaS solution that sets a higher bar for complete user experience management, with end-to-end monitoring technologies that include real-user, synthetic, third-party service monitoring, and business impact analysis.

To showcase the capabilities we used the free trial on our own about:performance blog as a demonstration platform. It is based on the popular WordPress technology which uses PHP and MySQL as its implementation stack. With only 4 steps we get full availability monitoring as well as visibility into every one of our visitors and can pinpoint any problem on our blog to problems in the browser (JavaScript, slow 3rd party, …), the network (slow network connectivity, bloated website, ..) or the application itself (slow PHP code, inefficient MySQL access, …).

Before we get started, let’s have a look at the Compuware APMaaS architecture. In order to collect real user performance data all you need is to install a so called Agent on the Web and/or Application Server. The data gets sent in an optimized and secure way to the APMaaS Platform. Performance data is then analyzed through the APMaaS Web Portal with drilldown capabilities into the dynaTrace Client.

Compuware APMaaS is a secure service to monitor every single end user on your application end-to-end (browser to database)

Compuware APMaaS is a secure service to monitor every single end user on your application end-to-end (browser to database)

4 Steps to setup APMaaS for our Blog powered by WordPress on PHP

From a high-level perspective, joining Compuware APMaaS and setting up your environment consists of four basic steps:

  1. Sign up with Compuware for the Free Trial
  2. Install the Compuware Agent on your Server
  3. Restart your application
  4. Analyze Data through the APMaaS Dashboards

In this article, we assume that you’ve successfully signed up, and will walk you through the actual setup steps to show how easy it is to get started.

After signing up with Compuware, the first sign of your new Compuware APMaaS environment will be an email notifying you that a new environment instance has been created:

Following the steps as explained in the Welcome Email to get started

Following the steps as explained in the Welcome Email to get started

While you can immediately take a peek into your brand new APMaaS account at this point, there’s not much to see: Before we can collect any data for you, you will have to finish the setup in your application by downloading and installing the agents.

After installation is complete and the Web Server is restarted the agents will start sending data to the APMaaS Platform – and with dynaTrace 5.5, this also includes the PHP agent which gives insight into what’s really going on in the PHP application!

Agent Overview shows us that we have both the Web Server and PHP Agent successfully loaded

Agent Overview shows us that we have both the Web Server and PHP Agent successfully loaded

Now we are ready to go!

For Ops & Business: Availability, Conversions, User Satisfaction

Through the APMaaS Web Portal, we start with some high level web dashboards that are also very useful for our Operations and Business colleagues. These show Availability, Conversion Rates as well as User Satisfaction and Error Rates. To show the integrated capabilities of the complete Compuware APM platform, Availability is measured using Synthetic Monitors that constantly check our blog while all of the other values are taken from real end user monitoring.

Operations View: Automatic Availability and Response Time Monitoring of our Blog

Operations View: Automatic Availability and Response Time Monitoring of our Blog

Business View: Real Time Visits, Conversions, User Satisfaction and Errors

Business View: Real Time Visits, Conversions, User Satisfaction and Errors

For App Owners: Application and End User Performance Analysis

Through the dynaTrace client we get a richer view to the real end user data. The PHP agent we installed is a full equivalent to the dynaTrace Java and .NET agents, and features like the application overview together with our self-learning automatic baselining will just work the same way regardless of the server-side technology:

Application level details show us that we had a response time problem and that we currently have several unhappy end users

Application level details show us that we had a response time problem and that we currently have several unhappy end users

Before drilling down into the performance analytics, let’s have a quick look at the key user experience metrics such as where our blog users actually come from, the browsers they use, and whether their geographical location impacts user experience:

The UEM Key Metrics dashboards give us the key metrics of web analytics tools as well as tying it together with performance data. Visitors from remote locations are obviously impacted in their user experience

The UEM Key Metrics dashboards give us the key metrics of web analytics tools as well as tying it together with performance data. Visitors from remote locations are obviously impacted in their user experience

If you are responsible for User Experience and interested in some of our best practices I recommend checking our other UEM-related blog posts – for instance: What to do if A/B testing fails to improve conversions?

Going a bit deeper – What impacts End User Experience?

dynaTrace automatically detects important URLs as so-called “Business Transactions.” In our case we have different blog categories that visitors can click on. The following screenshot shows us that we automatically get dynamic baselines calculated for these identified business transaction:

Dynamic Baselining detect a significant violation of the baseline during a 4.5 hour period last night

Dynamic Baselining detect a significant violation of the baseline during a 4.5 hour period last night

Here we see that our overall response time for requests by category slowed down on May 12. Let’s investigate what happened here, and move to the transaction flow which visualizes PHP transactions from the browser to the database and maps infrastructure health data onto every tier that participated in these transactions:

The Transaction Flow shows us a lot of interesting points such as Errors that happen both in the browser and the WordPress instance. It also shows that we are heavy on 3rd party but good on server health

The Transaction Flow shows us a lot of interesting points such as Errors that happen both in the browser and the WordPress instance. It also shows that we are heavy on 3rd party but good on server health

Since we are always striving to improve our users’ experience, the first troubling thing on this screen is that we see errors happening in browsers – maybe someone forgot to upload an image when posting a new blog entry? Let’s drill down to the Errors dashlet to see what’s happening here:

3rd Party Widgets throw JavaScript errors and with that impact end user experience.

3rd Party Widgets throw JavaScript errors and with that impact end user experience.

Apparently, some of the third party widgets we have on the blog caused JavaScript errors for some users. Using the error message, we can investigate which widget causes the issue, and where it’s happening. We can also see which browsers, versions and devices this happens on to focus our optimization efforts. If you happen to rely on 3rd party plugins you want to check the blog post You only control 1/3 of your Page Load Performance.

PHP Performance Deep Dive

We will analyze the performance problems on the PHP Server Side in a follow up blog. We will show you what the steps are to identify problematic PHP code. In our case it actually turned out to be a problematic plugin that helps us identify bad requests (requests from bots, …)

Conclusion and Next Steps

The intention of this blog was to show you how easy it is to setup your application with Compuware APMaaS and what it delivers – not only for Enterprise Applications that we typically write about but even for applications such as our WordPress blog. Stay tuned for more posts on this topic, or try Compuware APMaaS out yourself by signing up here for the free trial!

Comments

  1. Hi
    Could you please give me answers on these questions:
    1- What is the protocol used to communicate between the dynatrace Agent installed on the Web server and the APMaaS platform ?
    2- Does APMaaS send requests toward the Agent ? If so, using what protocol ?
    3- Does APMaaS provide the ability to create customized dashboards by the user ?
    4- Is it possible to have different user accounts to access the same reporting on APMaaS (by different users from the same company) ?
    5- Is there a mean to permit access to a dashboard only by its owner (protect a dashboard against access by a user who is not the owner) ?

    Thanks
    Best Regards
    Rezki BOUZEFRANE

    • Hi – great questions. Let me know if these answers your questions
      1: The Agent communicates through TCP/IP with the Collector. The Collector itself is sending it either via TCP/IP (Secure) or HTTPS to the dynaTrace Server. Some of our customers install a collector OnPremise in order to also leverage data compression features of the Collector in order to keep traffic low.
      2: The communication is always from Agent to Collector to Server. There is no communication the other way round.
      3: Yes – you can create any type of dashboards. They are very flexible as you can see in some of our examples
      4: Yes – you can create user roles, groupes and these roles and groups also have certain permissions
      5: Yes – this is handled through our User Groups concept as explained in point 4

      If you want to learn more about some of the dashboards other people built or some additonal arguments on APMaaS vs OnPremise check out the following blog: http://apmblog.compuware.com/2014/09/22/dynatrace-correcting-mis-representations/
      In general you will find a lot of screenshots of dynaTrace on this blog. EVerything that is possible with dynaTrace OnPremise is also possible with dynaTrace as a Service

      Andi

  2. Bouzefrane says:

    Hi Andi,
    Thanks a lot for your response. Just an another question about Collector : with application servers running only Java and Php, do you recommend to use a SaaS-collector ? Are performances quite similar with OnPremise Collector ? Is there a Saas-Collector located in Europe, where ?
    Sorry, there is more than one question :=)
    Best regards
    Rezki Bouzefrane

  3. Happy to answer these questions. We still recommend putting a Collector in your data center where your Java or PHP App runs. But – of course – feel free to just use our SaaS Collector. You just need to be aware of a slightly larger startup time of your JVM as we send byte code over to the Collector during startup.
    When you decide to go with SaaS we have different geo locations in AWS that we offer – Europe is part of it.
    If you have more question feel also free to ask them on our discussion forum on the community
    Andi

Comments

*


+ eight = 10