N O T I C E


MSPbots WIKI is moving to a new home at support.mspbots.ai to give you the best experience in browsing our Knowledge Base resources and addressing your concerns. Click here for more info!


The inspection function in Chrome is used to investigate issues in the MSPbots app and perform actions like capturing errors on the page and examining slow networks. This article contains the following: 

The instructions on this page apply to the Inspector Function for Chrome only.

1. How to bring up the inspection tool and developer tools

To open the tools:  

    • Press F12.
    • Press Ctrl+Shift+I.
    • Click on the ellipsis ... in the upper right corner of the screen, then click More tools > Developer tools.
      bring up inspection tool

    • Right-click on a blank area on the screen then click Inspect

      bring up inspection tool2

2. The most commonly used features for inspection 

2.1. The page loading is very slow

Access Network from the front-end browser and the server-side network interaction request.

inspection tools

  1. Clear the track log.
  2. Keep the track log when you refresh.
  3. Filter the request you need.
  4. For HTTP request type, the MSPbots API is Fetch/XHR(AJAX: asynchronous request). We are focused on monitoring this type of request.
  5. Next, for Dockside, the section where you find the tool, is below the default. Choose the appropriate position according to the number and size of your browsers.
  6. Close developer tools.
  7. Track the log detail grid. Right-click on the header to customize the columns for display.

2.2. Some area is not loading, or maybe because some area is not loading, the page is very slow

2.3. ConsoleThe recorded output of the front-end script code execution and the script code execution errors are found here. Please note that not all JS errors affect the normal flow of system functions. The flow is affected only when a function, button, or link sends a request to the server and the communication fails. This is a front-end bug. 
inspect console 


2.4. Other Troubleshooting

Issues with system function are classified into two categories: Front-End and Server-Side. Front-end issues include scenarios where the page becomes unresponsive, and the HTTP request is not sent after the user clicks a function button. For example, when you click on the menu in a test environment and do not receive a response, you can check with F12.


If the issue is on the server side:

  1. First, clean up the previous logs and track only the latest logs.
  2. Click the feature you want to troubleshoot.
  3. Next, switch request All to Fetch/XHR.
  4. Then, import the columns of the request tracking grid.


Status
- This is the status code of the HTTP request. Below are some common codes:
Status code 200 means the interface request is successful.
Status code 500 refers to the server side.
Status code 401 or 403 means insufficient permission to request the API.
Status code 503 means the server program is being updated and released, and that it is temporarily unavailable. The update will take a few minutes and the user has to try again.

Size - This is the size of the data returned by the server. A smaller data returned by the API means that the network transmission time and the waiting time of the user front end will be shorter.
Time is the total time it takes to finally return the data. This indicator directly reflects the performance of the interface. More complex processing logic for the interface means more time is consumed. A bigger data returned by the server also results in longer time consumption. In both cases, this means longer processing and response time leads to a worse user experience.

Waterfall - This is used to analyze what causes a request to consume a long time and focuses on waiting for server response, which is the server-side processing time. This includes the total processing time of business programs and databases.

If the response time of an API is taking a while, it may be because the business logic is complex and requires a longer processing time. Another reason is that the SQL is complex and the writing grammar is not optimized, which leads to slower database execution. Executing all SQL commands during this period will be slow.

Content Download
. After processing, the server will transmit the data back to the browser through the network. This will take time.

If there are too many API requests, you can output the API name keyword to filter the API to be checked.



Single request specific information



2.5. Use Case: A client reports that the MSPbots app runs very slowly 

Troubleshooting by the MSPbots Client Success Manager

  1. Switch to the client's account and log in as admin.
  2. Perform a dashboard refresh on the Executive Summary.

Findings and resolution:

Although each widget was loading, the SQL API request, which was supposed to be sent right away at a rate of 2-3 seconds, did not send immediately.  The successful sending of all the SQL API requests took 2-3 minutes. Each API responded quickly.

Because the API response was fast, errors in the server program and database were basically ruled out. The presumption was that the performance issue was purely a front-end bug. This was confirmed by the DEV team and the fix was released.


 

Another useful tool for feedback



  • No labels