Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to diagnose stutter problems in Java applications by ARMS

2025-04-07 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

This article shows you how ARMS diagnoses stutter problems in Java applications. The content is concise and easy to understand, and it will definitely brighten your eyes. I hope you can get something from the detailed introduction of this article.

According to related research: when the page loading time from 1 second to 3 seconds, the chance of jumping out increased by about 30%. The chance of 1s to 5s has increased to 90%. If your site needs 10s to load, the chance of jumping out will be more than 120%. (the 120% here does not mean 10 people, 12 people, it means the growth rate of user churn.) therefore, in this era of "user experience is king", application performance monitoring has become the top priority of operation and maintenance management.

First, find out the causes of "slow".

Stuttered websites and slow page loading are one of the common problems in Internet applications, which are not easy to troubleshoot and solve, and will cost a lot of time and energy of operation and maintenance personnel. There are usually three reasons:

The application link is too long to start.

From the front-end page to the background gateway, from the Web application server to the background database, any problem may lead to the overall stutter of the request. Is it because the front-end resources load too slowly? Or is there something wrong with the database? Or is there a performance problem with the newly released server code? The reasons for the problems are varied.

For applications with "micro-service" architecture, the link is more complex. Different components may be maintained by different teams and personnel, which makes it more difficult to troubleshoot problems.

The log is incomplete or of poor quality, and the site is missing.

There is no doubt that the application log is an artifact to troubleshoot online problems, but the location of the problem is often unpredictable, and when a problem occurs, it is often found that the log information is incomplete, because it is impossible for us to print the log in every place where there may be problems.

The definition of "slow" is subjective, and "slow" is often an occasional phenomenon. To really capture the "slow" line of code, we often need to record every call and not miss every line of code, but this is too expensive.

Lack of monitoring, it is too late to have a problem.

Rapid business development and faster iteration will lead to frequent interface modification, increased dependence and deterioration of code quality in the business system. If there is not a perfect monitoring system, it is too late to automatically monitor the performance of each interface of the application, record the calls that have problems, and wait for user feedback to solve the problem.

Second, how to locate the "slow" problem in one minute

Real-time business monitoring service ARMS (Application Real-Time MonitoringService) is a full-link monitoring product of Ali Cloud Application performance Management (APM). ARMS provides omni-directional monitoring features for Java application monitoring and diagnosis, vehicle networking real-time monitoring, retail real-time monitoring, user experience monitoring and other scenarios, including front-end monitoring, application monitoring and custom monitoring and other functions to quickly build real-time business monitoring capabilities.

Step 1: install the Java probe (if your application is hosted on EDAS, you can even skip this step)

Activate ARMS and create an application.

Download the Java probe kit and extract it.

Add-javaagent:/ {user.workspace} / ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar-Darms.licenseKey=xxx-Darms.appId=xxx to the Java application startup script (appId and licenseKey fill in according to the information assigned by the page)

Open the ARMS page and start reporting the data to verify that the Java probe has been installed successfully.

Step 2: find "slow" suspicious clues in the application overview

Enter the ARMS application topology diagram. In the application overview, we can clearly see that there are 5 times of "slow SQL" in today's system.

Step 3: browse and find the "slow interface"

Click on the interface list, we can see at a glance all the interfaces provided by the application, as well as the number of calls to this interface and time-consuming, of course, these interfaces are automatically discovered by ARMS probes in the program, without any configuration.

In these interfaces, the "slow" interface is clearly marked. We obviously found a suspicious slow interface.

Select the "slow" interface on the left that has the most calls, and we can see from the right that this call is obviously "slow" on the database call.

Step 4: which line of code is slow in the end? One button to locate the reason!

The time it takes to see the interface is not enough, we need to pinpoint which line of code "slow" appears in.

Click "Interface Snapshot" to see a snapshot of all interfaces corresponding to this interface, which is a complete record of a full-link call to a single call. The ARMS probe will record the code and time spent on each call with very little performance loss, helping you pinpoint the "slow" problem.

We click on one of the TraceId that calls the snapshot, and expand to see which line of the call is "slow". From the figure above, we can clearly see that in this 705ms call, most of the time is spent in the "SELECT * FROMl_employee" SQL call, which is obviously a full table scan operation!

So far, we have clearly found the root cause of a slow call error in the system. And there is a sufficient basis to guide our next step of code optimization. We can also go back to the list of calling interfaces, and then open the other "slow" calls in the list one by one and solve them one by one. I believe that with the help of ARMS, your website can stay away from stutter and provide users with a more smooth experience.

Step 5: take precautions-- set alarms

Of course, you can set alarms for one or all of the interfaces in the alarm settings of ARMS, so that your OPS team can be notified as soon as a card appears on the page interface.

The above is how ARMS diagnoses stutter problems in Java applications. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report