Troubleshooting Performance Issues - What to Expect

Amanda Jennewein
Amanda Jennewein
  • Updated

Author: Amanda Jennewein

Date: February 7, 2024

Audience: Everyone

Environmental details: All 

Summary: 

Performance is one of the most pivotal elements of user experience in a web application. This document is geared toward giving you, our customers, some insight into the things we look for and ask while handling these complex issues.

Accurately assessing performance issues is much like peeling an onion; one must peel back each layer of the issue one-by-one to get to the core of the problem. Additionally, the true source of the issue may not be directly related to where the behavior manifests itself on the front-end of the application. Therefore, when attempting to troubleshoot these types of issues, it's critical that as much information is captured as quickly as possible while the issue is occurring. Moreover, it's also critical that this information is provided to Support as soon as possible to help jumpstart the troubleshooting process. If you need help resolving a performance issue, knowing the answers to as many of the following questions as possible can help us begin work on the problem, and drive to a resolution quicker.

 

The Four Dimensions of Performance Troubleshooting:

  • Who?
    • Which users are affected by the problem?
      • Is this all users, or only specific users (or subsets of users)?
      • Are these users all of the same license types, or contained within a particular user role (a group used to assign permissions)?
      • Are these users particularly valuable or important, e.g. is this affecting an executive or a set of testers whose results are critical to shipping a product on a tight timeline?
    • Which user reported the problem?
  • What?
    • What, specifically, is the actual problem?
      • Does it simply take an inordinate amount of time to load a page/feature/item or do things completely fail to load?
      • Are you seeing error messages or warnings? If so, can you provide the exact error message or a screenshot of the error?
    • What specific actions or areas are "slow"?
      • Is this limited to a specific feature, or is it perceived application-wide?
        • If application-wide, is it worse in some areas, or is it consistently slow across the app?
    • What is the impact of the issue?
      • What are the specific business impacts of the issue?
        • Is it painful for users, but they're still able to complete their job (albeit not as effectively), or is this actually preventing work from getting done?
    • What does "slow" mean, quantifiable?
      • A network trace from the browser's developer tools is the most accurate way to provide us with quantifiable information about what specifically is slow, and how slow it is.
    • What behavior do you expect?
      • In other words, if the application isn't responding in the manner you expected, what were you expecting?
        • Has this feature or portion of the application behaved differently in the past, that was more consistent with your expectations?
    • What browsers does this affect?
      • Is it particularly slow on a specific browser, or is the performance relatively equal across browsers?
    • What changes, if any, have been made recently within your environment?
      • Did you recently begin using a particular feature?

      • Have you made any configuration changes recently within Jama?

      • If self-hosted, have you made any hardware, software, or network configuration changes recently?
  • Where?
    • Where are the affected users located?
      • Are they all from the same office or geographical location?
      • Are they all on the same network?
        • Are users physically connected to that network, or are they using a VPN to access it?
  • When?
    • When did the issue begin?
      • Specific dates and times
    • Is the issue still occurring?
      • If not, when did it end?
    • If the issue is intermittent, does it happen on any sort of consistent schedule or pattern?
      • The specific time of day?

      • Specific day or week?

      • Always after using some particular feature or taking some particular action?
    • When does the application perform well?
      • It's often just as important to understand when the issue is not occurring, as it allows us to compare and contrast certain data to look for anomalies.

Not every one of these questions will apply in every situation, and we don't expect you to copy-and-paste these questions as a template into your ticket. However, addressing as many of these elements as possible in your first reply on the ticket will give us a strong foundation to begin the investigation and help narrow the scope of the problem quickly.


What to Expect from Jama Support

Because performance issues differ in nature from most other reported issues, the troubleshooting process is often not comparable to that of the average ticket. In particular, you can expect the following (which may be different from the troubleshooting process you're already familiar with):

  • Expect to Be Actively Involved in the Troubleshooting Process
    This is summarized in greater detail by the expectations below but, unlike other types of issues, working through performance issues often requires us to work in close conjunction with your team. We typically won't be able to just gather some data and then work on the resolution in a vacuum; we'll need to ask additional questions, obtain additional data, and test hypotheses and/or changes using a Test/Measure/Repeat or an Observe/Orient/Decide/Act cycle. This is particularly true for self-hosted customers, as we don't have direct access to the instance or the data.
  • Expect Many Questions
    Troubleshooting performance is an iterative process. Sometimes we won't know what we don't know until we start asking questions, and your answers may lead to new questions, or into new areas that weren't previously considered. We'll strive to bundle as many of these together as possible (and to not repeat the same question twice!), but be prepared for multiple rounds of questions.
  • Expect That Some of These Questions May Not Seem Relevant, or May Lead to Dead Ends
    As we dig into an issue, the data we gather may lead us to a place that seems unrelated to the original issue. This is due to the way that things are interconnected "under the hood," which often makes it difficult or impossible for the end-user to perceive a connection between the problem they're experiencing and the questions that we're asking. Please trust us; our questions are always relevant and always data-driven. Without speculating, we'll strive to explain why we are asking the questions that we pose. That being said, we will sometimes ask a question or ask for some additional data to rule something out, so don't be concerned or discouraged if we stop a line of questioning and shift gears. We do track the information we request and are provided, and don't discard the responses, as we re-align our focus.
  • Expect Us to Request a Lot of Data from Your Server and (Potentially) from Your Users
    Troubleshooting without empirical data is like trying to find a needle in a haystack with a dessert fork on a moonless night; it's nigh impossible. Most often, performance issues are due to the specific nature of the data stored in Jama combined with a particular configuration. The complexity of these issues typically means that just telling us what functionality is slow and what configuration you have isn't enough to determine the cause. Having real, empirical data from the users and/or applications experiencing the problem is key. Don't worry, we'll guide you in gathering empirical data from tools and logs as necessary.
  • Expect Us to Ask You to Use Tools You May Be Unfamiliar With to Gather Empirical Data
    Different situations call for a different set of data and, thus, a different set of tools. In general, we'll ask for a specific type of information instead of the output from a specific tool, but it's possible that this may require you to set up or use certain types of tools that you aren't currently using. We understand that enterprises have varying degrees of security restrictions and validation processes for software and data; we will recommend built-in tools over third-party software where possible and, if a third-party tool is the only way, we'll always look for a free option. However, if we aren't able to gather the proper types of data, we may not be able to effectively troubleshoot your issue.
  • Expect Us to Ask You to Reproduce the Issue, Often in Multiple Environments/Configurations
    Before ever asking you to reproduce an issue, we will attempt to reproduce it ourselves locally. When we can't replicate the issue, we will often need you to attempt this issue in multiple environments (such as a test environment) to help rule out environmental or client-side issues. While we understand the inconvenience this may place on you, it helps us to narrow our focus and drive to the root of the issue quicker. We'll do what we can to limit these requests but be prepared to conduct some extensive testing on your side as well.
  • Expect to Be Asked to Make Data or Configuration Changes
    Sometimes, the only way we can prove our hypothesis is to actually manipulate the data or configuration we have identified as potentially contributing to the issue. We prefer to do this in a test instance when possible; however, the interim solution may be to leave such a configuration change in place. While we strive to be respectful and supportive of each use-case, there are some situations where impactful changes may be unavoidable.
  • Expect That the Issue Could Fall Outside of Our Scope
    Sometimes, performance problems may actually be caused by factors outside of the Jama application, such as proxy/network issues, browser or client configuration issues, a user's geographical distance from the server, and/or issues with external services such as an SSO provider (IdP) or integration provider (JIRA, Rally, TFS, etc). Other times, they could be caused by unsupported software or configurations that don't meet our minimum system requirements. If we've identified the issue as being due to one of these causes, we'll direct you to resolve the external issues first before troubleshooting Jama any further with you.
  • Don't Expect an Immediate Resolution
    We definitely understand that performance issues are often critically impactful. However, due to the complexity of performance issues in general, and the iterative nature of troubleshooting such issues, investigation is often a time-consuming process. We're going to investigate thoroughly to ensure that we have found the true root of the problem and that we have the data to back up our findings. Even if we're able to quickly identify the cause, the "fix" may be very complicated and require considerable QA investment to ensure that the proposed solution fully resolves the issue without causing any new ones. While we'll drive hard to resolve these issues as quickly as possible, we may not be able to rapidly provide a full fix.

Great, I Know What to Expect! If I Have an Issue, What Do I Do?

  • If your site is down or unresponsive, please gather a set of thread dumps immediately and generate a support bundle.

  • If you're a self-hosted customer, review our Supported Software list as well as our Production System Requirements to verify that you are running a supported configuration and that you have the proper resource allocation for your Jama App server and for your Database Server.

    NOTE: Jama will be unable to provide assistance for instances that do not meet our minimum supported requirements.
    1. If the issue isn't listed in our known issues or our release notes, and you've verified that your instance meets the minimum supported requirements, review the Four Dimensions of Performance Troubleshooting above and gather answers to as many questions as possible.
      • Try to at least address one question for each: Who, What, Where, and When.

    2. Gather as much empirical data and logs as reasonably possible based on the context. A HAR file of the event would be helpful. 
      • If you are self-hosted, gather a minimum of a Support Bundle, the contour.log, and some network/javascript output, and Support will direct you further.

    3. File a ticket with Jama Support that includes the information from steps 1 and 2 by logging into support.jamasoftware.com.
      • We will set an appropriate severity based on our guidelines.

    4. Monitor the ticket for the next steps from Jama Support! 

Remove this link before publishing - Original Source:

Troubleshooting Performance Issues - What to Expect

Feedback: Please leave feedback in the comments below.

 

 

Related to

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.