How can filtering help to manage the complexity of my service architecture?

Modern web applications typically feature complex service architectures that can process millions of different types of requests. With each unique request behaving slightly differently and triggering a slightly varied service flow, it can be a real challenge to analyze the performance and behavior of individual requests. Filtering options on each Dynatrace service-analysis page help you navigate the complexity of your application’s service architecture.

Filter requests based on specific call sequences

Dynatrace Service flow enables you to analyze subsets of requests triggered by a given service. As you can see in the service flow example below, only 40% of the requests to the easyTravel Customer Frontend service also called the JourneyService service.

Dynatrace additionally enables you to focus your analysis on specific sets of requests that are involved in specific call sequences. Call sequence filters are available in most service analysis views, but they’re most obvious in service flow.

To filter requests on the Service flow page

  1. Select Transactions & services from the navigation menu.
  2. Select the service you want to analyze.
  3. Click View service flow in the Understand dependencies section.
  4. Within service flow, select a called service to define the path of services you want to analyze. The Filter service flow button for the selected sequence appears on the right side of the page.
  5. Click Filter service flow to create a filter for the selected service flow.

In the example below, a filter has been created by clicking easyTravel-Business and thereby selecting the path of those requests from the easyTravel Customer Frontend service that call JourneyService and subsequently easyTravel-Business. Notice that the number of requests analyzed on easyTravel Customer Frontend has been reduced, as only a subset is now taken into account. Consequently, the average response time now represents only those easyTravel Customer Frontend requests that call JourneyService.

Now take a close look at the JourneyService node. As you can see, 39% of the easyTravel Customer Frontend service’s response time is taken up by JourneyService. Service flow also reveals something unexpected—some of the selected requests trigger the RMI server.

Once a filter has been defined, you can remove the filter by clicking Remove filter.

Create multi-faceted filters

Each filter can contain multiple call sequences. This means that you can create complex, multi-faceted call-sequence filters that are based on your unique service-analysis needs. Just click additional call sequences in service flow and click the Filter service flow button to add the new sequences to the existing filter.

Analyze call sequences from multiple angles

The true power of call-sequence filtering becomes apparent once you begin analysis of a problematic call sequence. Continuing with the example above, Service flow now shows us that half of the easyTravel Customer Frontend service’s response time is taken up by JourneyService.

The next logical step is to analyze the response time of JourneyService in the context of the selected call sequence. To do this, simply click the JourneyService box within service flow. The right-hand pane expands, revealing all types of Dynatrace analysis that you can perform on this service (PurePath, service-level backtrace, response time distribution, and response time)—all within the context of the filtered call sequence.

Because service flow filters remain persistent across all analysis views, your analysis remains focused on the exact call sequence that you’re interested in as you step through all available types of analysis. You can choose, for example, to analyze the response time of JourneyService. Just click View response time.

In the example below, response time analysis shows how well JourneyService performs when it’s called by easyTravel Customer Frontend and subsequently makes calls to the database—while easyTravel Customer Frontend simultaneously calls RMI Server, all within the same requests.

In this case, most of the response time is spent in Code execution. This drill-down functionality is available in all analysis views.

Click View PurePaths from the analysis options appearing at the bottom of the page (see image above) to view each of the individual PurePaths that relate to the selected call sequence. This PurePath view shows each JourneyService call or each call to an individual request—each of which can be analyzed separately.

Extend your filters with additional criteria

As you can see in the PurePaths view example above, most of the JourneyService requests are fast, but one is rather slow. Continuing our analysis, it makes sense to now focus on those JourneyService requests that exceed a certain response time threshold. To do this, click the JourneyService node within the filter visualization. This opens up a new pane with controls you can use to refine your filter based on Response time, CPU time, Wait time, and more. This functionality is available across all analysis views.

You can define such specific filter criteria for each filter node. Looking at the service flow example below, you can see that we’ve narrowed our analysis down to 3 requests! These are the only 3 requests within which the JourneyService response time is slower than 200 ms and the RMI Server requests are slower than 20 ms.

Multi-step analysis

Call-sequence filtering can be particularly useful when you’re analyzing a service and you want to analyze a different service within the context of the selected call-sequence. Note in the Response time analysis example below that the same subset of requests (calls made by easyTravel Customer Frontend to JourneyService) is shown. The analysis shows that the JourneyService is executed in 38% of the easyTravel Customer Frontend requests. Using the Filter response time button, we can focus our analysis on only those transactions that execute the given request.

What we see now is that the selected requests all seem to suffer from GC suspension. Also, note that the response time contribution of JourneyService has increased. This makes sense. Whereas in the first analysis JourneyService was only called in 38% of the requests, it is now present in 100% of requests. Consequently, JourneyService now contributes more to the overall response time.

The next logical step is to analyze JourneyService itself and try to understand its response time. Click the View response time button on the right side to view response time analysis of the JourneyService in the context of it being called by easyTravel Customer Frontend.

Impact analysis of slow database statements

Call sequence filters are particularly powerful within Service-level backtrace view.

To open Service-level backtrace view

  1. Select Transactions & services from the navigation menu.
  2. Select the service you want to analyze.
  3. In the Understand dependencies section, click Analyze backtrace to access the Service-level backtrace page.

On the Service-level backtrace page, click Add filter to define a new filter. In the example below, you can see the backtrace of the database where database requests are slower than 10ms. It turns out that only a single user action is affected by the img_gallery database statement: click on “Gallery”.

Not only have we now identified which exact click triggered the slow database call, we can reverse the analysis and look at the flow of requests that led up to the SQL call by performing a drill-down of My web application within the service flow view. Just select My web application and click the View service flow button.