Webpage performance monitoring method and device, electronic equipment and storage medium

Abstract

This invention discloses a webpage performance monitoring method, apparatus, electronic device, and storage medium, relating to the fields of system operation and maintenance and data processing. The method includes: responding to the acquisition of webpage request data and performance indicator data; acquiring the stage processing time of each request processing stage based on the performance indicator data; acquiring the performance analysis results of each request processing stage based on the stage processing time and historical baseline data; if it is determined that the front-end stage time is abnormal, acquiring the resource loading time of each page resource, and acquiring the front-end loading path based on the resource loading time, so as to identify the front-end performance bottleneck based on the front-end loading path. The technical solution of this invention, when determining that the front-end stage time is abnormal, perceives the front-end performance bottleneck affecting page loading time from the front-end perspective, so that the front-end performance bottleneck truly reflects the user's visual experience, ensuring the accuracy and timeliness of webpage performance monitoring results.

Description

Technical Field

[0001] This invention relates to the field of system performance monitoring and data processing, and in particular to a webpage performance monitoring method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the continuous development of computer technology, the number of access requests carried by business systems is also increasing. Among these, the waiting time for users to access web pages, as the most intuitive feeling during the user process, has become an important part of the user experience.

[0003] Taking the user's access to the product details page as an example, in order to solve the problem of slow loading of the product details page, the existing technology usually monitors the performance indicators of various components in the business system through a background monitoring system. When abnormal performance indicators are detected, the corresponding system components are repaired through automatic operation and maintenance or manual operation and maintenance to maintain a fast page loading speed and ensure a good user experience.

[0004] However, this method of webpage performance monitoring often results in no alarms on the server side, but users perceive a performance degradation, which fails to accurately reflect the user's experience. In addition, time-consuming anomalies involve multiple processing stages, and a single backend monitoring method cannot establish a complete anomaly chain, leading to missing influencing factors in the performance test results. Summary of the Invention

[0005] This invention provides a webpage performance monitoring method, apparatus, electronic device, and storage medium to solve the problem that webpage performance monitoring results cannot have large errors.

[0006] According to another aspect of the present invention, a webpage performance monitoring method is provided, comprising: In response to obtaining webpage request data and performance indicator data, the processing time of each request processing stage is obtained based on the performance indicator data; wherein, the request processing stage includes the network stage, the backend stage, and the frontend stage; Based on the webpage request data, obtain historical baseline data that matches the performance index data, and based on the processing time of each stage and the historical baseline data, obtain the performance analysis results of each request processing stage; If the time consumption of the front-end stage is determined to be abnormal, the resource loading time of each page resource is obtained, and the front-end loading path is obtained based on the resource loading time, so as to identify the front-end performance bottleneck based on the front-end loading path.

[0007] After obtaining the front-end performance bottleneck based on the front-end loading path, the method further includes: expanding the call hierarchy of the application programming interface calls in the current page in sequence to obtain the call time of different call stages, and obtaining the back-end performance bottleneck based on the call method of the target call stage with the longest call time.

[0008] After identifying the backend performance bottleneck based on the calling method of the target call phase with the longest call duration, the method further includes: obtaining the infrastructure status within the corresponding time period based on the web page request data, and obtaining the infrastructure performance bottleneck based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0009] After identifying the infrastructure performance bottleneck based on the infrastructure status, the method further includes: obtaining the total time increment based on the performance indicator data and the historical baseline data, and obtaining the front-end time contribution, back-end time contribution, and infrastructure time contribution based on the total time increment, the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck.

[0010] After obtaining the front-end time contribution, back-end time contribution, and infrastructure time contribution based on the total time increment, the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck, the method further includes: obtaining the processing priority of the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck based on the repair difficulty coefficient and impact range coefficient corresponding to the front-end time contribution, the back-end time contribution, and the infrastructure time contribution, respectively, as well as the processing priority of the front-end time contribution, the back-end time contribution, and the infrastructure time contribution.

[0011] After obtaining the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data, the method further includes: if it is determined that the backend stage time is abnormal and / or the network stage time is abnormal, and the frontend stage time is normal, the call hierarchy of the application programming interface calls in the current page is expanded sequentially to obtain the call time of different call stages, and the backend performance bottleneck is obtained based on the call method of the target call stage with the longest call time; the infrastructure status within the corresponding time period is obtained based on the web page request data, and the infrastructure performance bottleneck is obtained based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0012] According to another aspect of the present invention, a webpage performance monitoring device is provided, comprising: The positioning area acquisition module is used to acquire the positioning area image of the status indicator in the video frame image in response to the acquisition of the video frame image of the status indicator, by using the reference position information of the reference template image; An overexposure judgment module is used to obtain a grayscale image corresponding to the image of the positioning area, and to determine whether the image of the positioning area is overexposed based on the proportion of bright pixels in the grayscale image. The illumination status acquisition module is used to classify the pixels of the positioning area image according to a reference color threshold if it is determined that there is no overexposure phenomenon in the positioning area image, so as to obtain the illumination status of the status indicator light according to the pixel classification result.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the webpage performance monitoring method according to any embodiment of the present invention.

[0014] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the webpage performance monitoring method described in any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the webpage performance monitoring method described in any embodiment of the present invention.

[0016] The technical solution of this invention, in response to obtaining webpage request data and performance indicator data, obtains the processing time of each request processing stage based on the performance indicator data; obtains historical baseline data matching the performance indicator data based on the webpage request data, and obtains the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data; if it is determined that the front-end stage time is abnormal, it obtains the resource loading time of each page resource, and obtains the front-end loading path based on the resource loading time, so as to identify the front-end performance bottleneck based on the front-end loading path. Therefore, when it is determined that the front-end stage time is abnormal, the front-end performance bottleneck affecting the page loading time is perceived from the front-end perspective, avoiding the phenomenon of no alarms on the server side while the user perceives a performance degradation. This ensures that the obtained front-end performance bottleneck truly reflects the user's visual experience, guaranteeing the accuracy and timeliness of webpage performance monitoring results.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a webpage performance monitoring method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of another webpage performance monitoring method provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart of another webpage performance monitoring method provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of a webpage performance monitoring device according to Embodiment 4 of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device that implements the webpage performance monitoring method of this invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] Example 1 Figure 1 This is a flowchart of a webpage performance monitoring method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where, when abnormal front-end time consumption is determined, the front-end performance bottleneck is obtained based on the resource loading time of each page resource. This method can be executed by a webpage performance monitoring device, which can be implemented in hardware and / or software and can be configured in an electronic device (e.g., a server). Figure 1 As shown, the method includes: S101. In response to obtaining webpage request data and performance indicator data, obtain the stage processing time of each request processing stage based on the performance indicator data; wherein, the request processing stage includes the network stage, the backend stage, and the frontend stage.

[0023] Webpage request data refers to the data related to the request itself and the user when a user sends a webpage access request to a server through a browser. Webpage request data may include user identity document (ID), webpage Uniform Resource Locator (URL), access time, geographic location, device type, and network type. Among them, access time refers to the time when the current access request was sent; geographic location refers to the region where the current access request was sent, that is, the user's region; device type includes terminal device type, operating system type, and browser type; network type is the network type of the transmission channel of the current access request.

[0024] Performance metrics include page full load time, initial content rendering time, initial interactive time, Domain Name System (DNS) resolution time, TCP (Transmission Control Protocol) connection time, SSL (Secure Sockets Layer) handshake time, first byte time, content download time, DOM (Document Object Model) parsing time, resource loading time, and front-end script execution time.

[0025] Page load time refers to the time from when the browser sends a request to when all page resources are fully loaded; initial content rendering time refers to the time it takes for the user to first see (i.e., when the browser first displays) non-blank content (e.g., text and images); initial interactive time refers to the time it takes for the page to fully respond to input and for the main thread to remain idle; domain name system resolution time refers to the time it takes for the browser to resolve a domain name to obtain an IP (Internet Protocol) address; and TCP connection time refers to the time it takes for the browser and server to establish a TCP three-way handshake.

[0026] SSL handshake time refers to the duration of negotiating the encryption key for an HTTPS (Hypertext Transfer Protocol Secure) connection; first byte time refers to the time from when the browser initiates a request to when it receives the first byte from the server; content download time refers to the time from when the browser receives the first byte to when it has fully downloaded the resource; DOM parsing time refers to the time it takes for the browser to parse HTML (Hypertext Markup Language) and build the DOM tree; resource loading time refers to the total time taken to load all external resources on the page; and front-end script execution time refers to the total time taken to parse, compile, and execute front-end scripts (i.e., JavaScript files).

[0027] The total page load time can be divided into network time, backend time, and frontend time. In other words, the total page load time is the sum of network time, backend time, and frontend time. Network time refers to the time it takes for the browser to establish a connection with the server and transmit data; network time = DNS resolution time + TCP connection time + SSL handshake time + content download time. Backend time refers to the time it takes for the server to process requests and generate responses; backend time = first byte time - DNS resolution time - TCP connection time - SSL handshake time. Frontend time refers to the time it takes for the browser to parse and render the page; frontend time = DOM parsing time + resource loading time + frontend script execution time.

[0028] Specifically, webpage request data and performance metrics can be obtained through the JavaScript SDK (Software Development Kit). For example, the performance metrics are as follows: Full page load time: 5200 milliseconds; Initial content rendering time: 1200 milliseconds; Initial interactive time: 3800 milliseconds; DNS resolution time: 80 milliseconds; TCP connection time: 120 milliseconds; SSL handshake time: 180 milliseconds; First byte time: 850 milliseconds; Content download time: 1200 milliseconds; DOM parsing time: 800 milliseconds; Resource loading time: 1500 milliseconds; Front-end script execution time: 900 milliseconds.

[0029] The network phase time is 80 + 120 + 180 + 1200 = 1580 milliseconds; the backend phase time is 850 - 80 - 120 - 180 = 470 milliseconds; and the frontend phase time is 800 + 1500 + 900 = 3200 milliseconds. Additionally, based on the page full load time = network time + backend time + frontend time = 1580 + 470 + 3200 = 5250 milliseconds, the calculated page full load time (5250 milliseconds) can be compared with the actual result (5200 milliseconds). The error between the two (50 milliseconds) is determined to be less than the preset error threshold (e.g., 500 milliseconds). Therefore, the calculation result is within the normal error range, thus completing the verification of the calculation result.

[0030] S102. Obtain historical baseline data that matches the performance index data based on the webpage request data, and obtain the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data.

[0031] Based on the webpage request data, historical performance metrics data for the same webpage (i.e., the same webpage address), the same region (i.e., the same geographical location), and the same device type are obtained, and their average or optimal values ​​are used as historical baseline data. Based on this historical baseline data, the baseline value of the page full load time and the baseline value of each request processing stage are defined. For example, in the historical baseline data, the page full load time is 2000 milliseconds, the network stage time is 800 milliseconds, the backend stage time is 300 milliseconds, and the frontend stage time is 900 milliseconds.

[0032] The performance degradation ratio of the page load time is calculated by comparing the current page load time with the historical baseline data. The ratio of this difference to the historical baseline value is used as the performance degradation ratio of the page load time: (5200-2000)÷2000=3200÷2000=160%. Similarly, the performance degradation ratio of each request processing stage is calculated by comparing the processing time of each stage with the corresponding historical baseline value. The ratio of this difference to the historical baseline value is used as the performance degradation ratio of each request processing stage: (1580-800)÷800=780÷800=97.5%); (470-300)÷300=170÷300=56.7%); (3200-900)÷900=2300÷900=255.6%).

[0033] Different preset degradation thresholds can be configured for the page full load time (i.e., total time), network stage, backend stage, and frontend stage, or the same preset degradation threshold can be configured. For example, if the preset degradation threshold is set to 50% for all of them, then obviously the performance degradation ratios of the page full load time, network stage, backend stage, and frontend stage in the above technical solution are all greater than the preset degradation threshold of 50%, that is, the total time, network stage time, backend stage time, and frontend stage time are all abnormal.

[0034] S103. If it is determined that the front-end stage time consumption is abnormal, obtain the resource loading time of each page resource, and obtain the front-end loading path according to the resource loading time, so as to obtain the front-end performance bottleneck according to the front-end loading path.

[0035] Regardless of whether there are any time-consuming anomalies in the network stage and the backend stage, if it is determined that there are time-consuming anomalies in the frontend stage, since the frontend stage needs to load multiple page resources, it is necessary to analyze the resource loading time of each page resource. Based on this, the browser's resource timing data can be obtained through the browser's Resource Timing API; page resources include HTML documents, images, JS script files, and CSS files.

[0036] The HTML document, also known as the main document of the page, serves as the core skeleton file of the page and contains basic content such as text, image links, and structural tags; images are the visual elements that display products; JS script files refer to script files with the ".js" extension, also known as JavaScript files, which are used to implement interactive logic; CSS files refer to files with the ".css" extension, which are used to control the visual style of HTML elements.

[0037] Specifically, during the JavaScript file download phase, asynchronous requests are made through the backend's Application Programming Interface (API) to dynamically retrieve structured data from the page. For example, API call 1 retrieves product information, API call 2 retrieves product reviews, and API call 3 retrieves recommended products. As shown in Table 1, the URL, start time, end time, resource size, and download time of each resource on the page can be obtained.

[0038] Table 1. Resource loading time for each page resource Taking the above scheme as an example, the HTML document was loaded from 0 to 850 milliseconds, and the first image was loaded at 900 milliseconds, which indicates that the HTML document was parsed between 850 and 900 milliseconds; then the image, JavaScript file, and CSS file were loaded in parallel from 900 milliseconds; based on this, the longest dependency chain in the resource loading stage was taken as the front-end loading path, that is, (1) the HTML document was downloaded from 0 to 850 milliseconds; (2) the HTML document was parsed from 900 to 1000 milliseconds and the JavaScript file was found; (3) the JavaScript file was downloaded and executed from 1000 to 2800 milliseconds; (4) the API call was triggered during the execution of the JavaScript file; (5) the page was fully rendered at 5200 milliseconds.

[0039] As shown above, the download time of the JavaScript file (1800 milliseconds) accounts for 56% of the total time spent in the front-end stage (3200 milliseconds). Therefore, the excessive download time of the JavaScript file can be regarded as the front-end performance bottleneck, that is, the page rendering is blocked due to the excessive download time of the JavaScript file. Based on this, if there are abnormal time consumptions during the user's access to the webpage, the performance bottleneck of the front-end stage (i.e., the front-end performance bottleneck) can be determined by calculating the resource loading time of each page resource.

[0040] Optionally, in this embodiment of the invention, after obtaining the front-end performance bottleneck based on the front-end loading path, the method further includes: sequentially expanding the call hierarchy of the application programming interface calls in the current page to obtain the call time of different call stages, and obtaining the back-end performance bottleneck based on the call method of the target call stage with the longest call time.

[0041] Specifically, when there are abnormal time consumptions in the front-end stage, front-end performance bottlenecks may not be the only factor causing excessively long page loading times. They may also be affected by the back-end service chain. Therefore, a distributed tracing system can be used to connect the API calls initiated by the front-end with the complete processing flow of the back-end service, forming an end-to-end call trajectory. Taking API call 1 in the above technical solution, i.e., calling product information, as an example, starting from the root node, the entire call process begins at 2024-01-15 14:30:01.100 and ends at 2024-01-15 14:30:01.600, taking 500ms (total duration from start to finish). The call process includes two stages: Stage 1 verifies the user's token, taking 40 milliseconds (8% of the total call time); Stage 2 processes the product service, taking 400 milliseconds (80% of the total call time). Clearly, Stage 2 is the main source of time consumption.

[0042] Then, we continue to traverse stage 2, whose sub-stages include cache query, database query, and data assembly. Among them, cache query refers to whether the cache is hit to avoid direct access to the database, which takes 20 milliseconds; data assembly refers to converting the database result into the API response format, which takes 30 milliseconds; and database query takes 350 milliseconds. Obviously, the database query takes the most time, and the database query time in historical baseline data is usually 50 milliseconds. Based on this, the database query stage is determined as the target call stage.

[0043] Finally, by analyzing the query method of the database host, it was found that the query method was a full table scan using Structured Query Language (SQL) without using indexes, resulting in low query efficiency. Therefore, the performance bottleneck in the backend stage was found to be the excessively long database query time. Thus, the API calls of the frontend page were mapped to the backend microservice chain, forming an end-to-end call trajectory. This enabled the accurate acquisition of backend time-consuming behaviors when time-consuming anomalies were identified in the frontend stage, ensuring the complete acquisition of the factors affecting the excessively long page loading time.

[0044] Optionally, in this embodiment of the invention, after obtaining the backend performance bottleneck based on the calling method of the target calling stage with the longest calling time, the method further includes: obtaining the infrastructure status within the corresponding time period based on the web page request data, and obtaining the infrastructure performance bottleneck based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0045] Specifically, based on the time of this page access request, the infrastructure status within the corresponding time period is obtained. This infrastructure status can include the database host status, container status, and content delivery network node status. Among them, the database host status can include CPU utilization of 85% (normal value is less than 70%), memory utilization of 65% (normal value), disk I / O (Input / Output) wait time of 120ms (normal value is less than 50ms), and active connection count of 450 (normal value is less than 300).

[0046] Container status can include CPU utilization of 40% (normal), memory utilization of 55% (normal), request QPS of 1200 (normal), and error rate of 0.1% (normal). Content Delivery Network (CDN) node status includes the average response time of nodes in the current region of 800 milliseconds (normal is 300 milliseconds), cache hit rate of 60% (normal is greater than 90%), and bandwidth utilization of 95% (normal is less than 80%). Among these, the excessively long average response time of CDN nodes is the identified infrastructure performance bottleneck and the reason for the excessively long network stage. Therefore, by linking backend services with infrastructure monitoring, it was verified whether the excessively long page full load time was related to the server room infrastructure, further ensuring the complete acquisition of the influencing factors that cause the excessively long page full load time.

[0047] Specifically, based on the front-end performance bottlenecks, infrastructure performance bottlenecks, and back-end performance bottlenecks obtained above, a complete end-to-end performance impact chain can be constructed; that is, the total time for the user's webpage access request (i.e., the full page load time) is 5200 milliseconds, which is decomposed into the network stage time of 1580 milliseconds → associated with CDN node metrics: the current CDN response time is slow and the cache hit rate is low, that is, due to the current CDN response time being slow and the cache hit rate being low, the network stage time is too long.

[0048] Meanwhile, it was further broken down into the following steps: backend stage time: 470 milliseconds (with a small statistical error, the actual value is obviously greater than 500 milliseconds) → associated backend API calls → API call 1 time: 500 milliseconds → product service time: 400 milliseconds → database query time: 350 milliseconds → associated infrastructure: high database host CPU, high disk I / O wait, too many active connections; in addition, it was further broken down into the following steps: frontend stage time: 3200 milliseconds → associated resource loading: JS file download time: 1800 milliseconds, API call 1 time: 500 milliseconds, API call 2 time: 700 milliseconds, API call 3 time: 800 milliseconds.

[0049] Optionally, in this embodiment of the invention, after obtaining the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data, the method further includes: if it is determined that the backend stage time is abnormal and / or the network stage time is abnormal, and the frontend stage time is normal, the call hierarchy of the application programming interface calls in the current page is expanded sequentially to obtain the call time of different call stages, and the backend performance bottleneck is obtained based on the call method of the target call stage with the longest call time; the infrastructure status within the corresponding time period is obtained based on the web page request data, and the infrastructure performance bottleneck is obtained based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0050] Specifically, if the front-end stage execution time is normal, there is no need to identify the front-end performance bottleneck. However, if the back-end stage execution time or the network stage execution time is abnormal, as described in the above technical solution, the call hierarchy of the application programming interface calls in the current page is expanded sequentially to obtain the call time of different call stages. Based on the call method of the target call stage with the longest call time, the back-end performance bottleneck is identified. At the same time, the infrastructure status within the corresponding time period is obtained based on the web page request data, and the infrastructure performance bottleneck is identified based on the infrastructure status.

[0051] Specifically, when the backend stage time is normal but the network stage time is abnormal, the abnormal network stage time may be related to the infrastructure status or the backend service link. In this case, although the backend stage time is normal, as described in the above technical solution, the backend performance bottleneck is obtained first, and then the infrastructure performance bottleneck is obtained. This avoids the calculation of the frontend performance bottleneck, improves the efficiency of obtaining performance analysis results, and ensures the complete acquisition of the factors that cause the page to take too long to fully load.

[0052] The technical solution of this invention, in response to obtaining webpage request data and performance indicator data, obtains the processing time of each request processing stage based on the performance indicator data; obtains historical baseline data matching the performance indicator data based on the webpage request data, and obtains the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data; if it is determined that the front-end stage time is abnormal, it obtains the resource loading time of each page resource, and obtains the front-end loading path based on the resource loading time, so as to identify the front-end performance bottleneck based on the front-end loading path. Therefore, when it is determined that the front-end stage time is abnormal, the front-end performance bottleneck affecting the page loading time is perceived from the front-end perspective, avoiding the phenomenon of no alarms on the server side while the user perceives a performance degradation. This ensures that the obtained front-end performance bottleneck truly reflects the user's visual experience, guaranteeing the accuracy and timeliness of webpage performance monitoring results.

[0053] Example 2 Figure 2 This is a flowchart of a webpage performance monitoring method provided in Embodiment 2 of the present invention. The relationship between this embodiment and the above embodiments is that the contribution of each performance bottleneck to the total time increment is calculated respectively, such as... Figure 2 As shown, the method specifically includes: S201. In response to obtaining webpage request data and performance indicator data, obtain the processing time of each request processing stage based on the performance indicator data; wherein, the request processing stage includes the network stage, the backend stage, and the frontend stage.

[0054] S202. Obtain historical baseline data that matches the performance index data based on the webpage request data, and obtain the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data.

[0055] S203. If it is determined that the front-end stage time consumption is abnormal, obtain the resource loading time of each page resource, and obtain the front-end loading path according to the resource loading time, so as to obtain the front-end performance bottleneck according to the front-end loading path.

[0056] S204. Expand the call hierarchy of the application programming interface calls in the current page in sequence to obtain the call time of different call stages, and obtain the backend performance bottleneck based on the call method of the target call stage with the longest call time.

[0057] S205. Obtain the infrastructure status within the corresponding time period based on the webpage request data, and obtain the infrastructure performance bottleneck based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0058] S206. Obtain the total time increment based on the performance index data and the historical baseline data, and obtain the front-end time contribution, back-end time contribution and infrastructure time contribution based on the total time increment, the front-end performance bottleneck, the back-end performance bottleneck and the infrastructure performance bottleneck.

[0059] First, the total time increment equals the actual total time (i.e., the page full load time of 5200 milliseconds in the performance metric data) minus the normal total time (i.e., the page full load time of 2000 milliseconds in the historical baseline data), resulting in 3200 milliseconds. Then, the impact (i.e., contribution) of each performance bottleneck on the page full load time is calculated, and the contribution calculation formula is defined as: Performance bottleneck contribution = (actual time of the performance bottleneck - normal time of the performance bottleneck) ÷ total time increment.

[0060] Taking the above-mentioned CDN node response time anomalies, JavaScript file download anomalies, and database host query anomalies as examples, the average response time of the two images actually responded by the CDN node is (1300 milliseconds + 850 milliseconds) / 2 = 1075 milliseconds, while the normal response time of the CDN node is 300 milliseconds. That is, the incremental time of the CDN node response time anomalies is 775 milliseconds. Therefore, the contribution of the CDN node response time anomalies is 775 ÷ 3200 = 0.242 = 24.2%.

[0061] Meanwhile, the JavaScript file download time was 1800 milliseconds, while the normal download speed is 1024KB / s. With the JavaScript file being 300KB, the normal download time would be 300KB ÷ 1024KB / s = 0.293 seconds = 293 milliseconds. That is, the JavaScript file download anomaly occurred in 1507 milliseconds. Therefore, the contribution of the JavaScript file download anomaly is 1507 ÷ 3200 = 0.471 = 47.1%.

[0062] Furthermore, the actual query time on the database host is 350 milliseconds, while the normal query time is 50 milliseconds. The increase in database query time is 350 milliseconds - 50 milliseconds = 300 milliseconds. Since the database affects the above three API calls, assuming that the increase in database query time for API call 2 and API call 3 is also 300 milliseconds, then the actual increase in database time should be 300 milliseconds + 300 milliseconds + 300 milliseconds = 900 milliseconds. Therefore, the contribution of the database host query anomaly is 900 ÷ 3200 = 0.281 = 28.1%.

[0063] In summary, JavaScript file download errors, database host query errors, and CDN node response time errors account for 47.1%, 28.1%, and 24.2% of the total time increment, respectively. Other unaccounted factors and calculation errors account for 0.6%, for a total of 100%.

[0064] The technical solution of this invention obtains the total time increment based on performance index data and historical baseline data, and then obtains the front-end time contribution, back-end time contribution, and infrastructure time contribution based on the total time increment, front-end performance bottlenecks, back-end performance bottlenecks, and infrastructure performance bottlenecks. This not only identifies the factors influencing excessive page loading time but also obtains the contribution of each factor, providing accurate operational data for system maintenance.

[0065] Example 3 Figure 3This is a flowchart of a webpage performance monitoring method provided in Embodiment 3 of the present invention. The relationship between this embodiment and the above embodiments is that the processing priority of each performance bottleneck is calculated respectively, such as... Figure 3 As shown, the method specifically includes: S301. In response to obtaining webpage request data and performance indicator data, obtain the processing time of each request processing stage based on the performance indicator data; wherein, the request processing stage includes the network stage, the backend stage, and the frontend stage.

[0066] S302. Obtain historical baseline data that matches the performance index data based on the webpage request data, and obtain the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data.

[0067] S303. If it is determined that the front-end stage time consumption is abnormal, obtain the resource loading time of each page resource, and obtain the front-end loading path according to the resource loading time, so as to obtain the front-end performance bottleneck according to the front-end loading path.

[0068] S304. Expand the call hierarchy of the application programming interface calls on the current page in sequence to obtain the call time of different call stages, and obtain the backend performance bottleneck based on the call method of the target call stage with the longest call time.

[0069] S305. Obtain the infrastructure status within the corresponding time period based on the webpage request data, and obtain the infrastructure performance bottleneck based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0070] S306. Obtain the total time increment based on the performance index data and the historical baseline data, and obtain the front-end time contribution, back-end time contribution and infrastructure time contribution based on the total time increment, the front-end performance bottleneck, the back-end performance bottleneck and the infrastructure performance bottleneck.

[0071] S307. Based on the front-end time consumption contribution, the back-end time consumption contribution, and the infrastructure time consumption contribution, the corresponding repair difficulty coefficient and impact range coefficient, as well as the front-end time consumption contribution, the back-end time consumption contribution, and the infrastructure time consumption contribution, obtain the processing priority of the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck.

[0072] The repair difficulty coefficient reflects the ease or difficulty of repairing the current anomaly. The greater the repair difficulty, the greater the repair difficulty coefficient. Different repair difficulty coefficients can be pre-assigned to different types of anomalies. Taking the above technical solution as an example, the repair difficulty coefficients for CDN node response time anomalies, JavaScript file download anomalies, and database host query anomalies can be configured to 0.4, 0.8, and 0.6, respectively. The impact range coefficient reflects the number of users affected by the current anomaly. For example, a JavaScript file download anomaly affects all users in the system, and its corresponding impact range coefficient is 1; a database host query anomaly also affects all users in the system, and its corresponding impact range coefficient is also 1; a CDN node response time anomaly only affects users in that node region, and based on the proportion of users in that region, its corresponding impact range coefficient is 0.3.

[0073] The priority score is defined as: Contribution × Repair Difficulty Coefficient × Impact Scope Coefficient. Based on the above calculation equation, the priority score for CDN node response time anomalies is 24.2% × 0.4 × 0.3 = 2.9%; the priority score for database host query anomalies is 28.1% × 0.6 × 1.0 = 16.9%; and the priority score for JavaScript file download anomalies is 47.1% × 0.8 × 1.0 = 37.7%. Obviously, the processing priority of JavaScript file download anomalies, database host query anomalies, and CDN response time anomalies decreases in that order.

[0074] Specifically, for the above-mentioned anomalies, a root cause analysis report and specific operation and maintenance methods can be provided through rule models or large language models. For example, the main problem is abnormal JavaScript file download, contributing 47.1% of the total. Specifically, when the JavaScript file is 300KB, the download time is 1800ms. The root cause is that the file is uncompressed and the CDN node performance is poor. Suggested operation and maintenance methods may include splitting the code and loading it on demand; enabling file compression; delaying the loading of non-critical JavaScript files; monitoring the JavaScript file size and setting an alarm threshold of 300KB.

[0075] The secondary issue is database query anomalies, contributing 28.1% of the problem. Specifically, API calls take 350 milliseconds to execute. The root cause is a full table scan and limited database host resources. Recommended maintenance measures include adding an index to the ID field; optimizing query methods to select only necessary fields; separating database read and write functions; monitoring the number of active database connections and setting an alarm threshold of 300.

[0076] The secondary issue is the performance degradation of CDN nodes, contributing 24.2%, specifically manifested as a current CDN node response time of 800 milliseconds and a cache hit rate of 60%. The root cause is excessive node load and improper cache configuration. Recommended maintenance methods may include scaling up the current CDN nodes; adjusting the caching strategy to increase the caching time of static resources; and implementing a disaster recovery solution with multiple CDN nodes.

[0077] Specifically, the expected optimization results can be provided through rule models or large language models. For example, JavaScript file download optimization can reduce the time taken from 1800 milliseconds to 300 milliseconds, saving 1500 milliseconds; database query optimization can reduce API call time from 500 milliseconds to 150 milliseconds, saving 350 milliseconds; CDN node optimization can reduce image loading time from 1075 milliseconds to 400 milliseconds, saving 675 milliseconds. The total expected savings are 1500 milliseconds + 350 milliseconds + 675 milliseconds = 2525 milliseconds; the expected full page load time is 5200 - 2525 = 2675 milliseconds, and the optimization results are within the normal range.

[0078] The technical solution of this invention obtains the processing priority of front-end performance bottlenecks, back-end performance bottlenecks, and infrastructure performance bottlenecks based on the repair difficulty coefficient and impact scope coefficient corresponding to the front-end time consumption contribution, back-end time consumption contribution, and infrastructure time consumption contribution, respectively. This ensures that anomalies with a large impact scope and easy to quickly repair are prioritized, improving the operational efficiency of the business system.

[0079] Example 4 Figure 4 This is a structural block diagram of a webpage performance monitoring device provided in Embodiment 4 of the present invention. The device specifically includes: The stage processing time acquisition module 401 is used to acquire web page request data and performance index data in response to acquiring the stage processing time of each request processing stage based on the performance index data; wherein, the request processing stage includes the network stage, the backend stage and the frontend stage. The performance result acquisition module 402 is used to acquire historical baseline data that matches the performance indicator data based on the web page request data, and to acquire the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data. The front-end bottleneck acquisition module 403 is used to acquire the resource loading time of each page resource if it is determined that the front-end stage time consumption is abnormal, and to acquire the front-end loading path based on the resource loading time, so as to acquire the front-end performance bottleneck based on the front-end loading path.

[0080] The technical solution of this invention, in response to obtaining webpage request data and performance indicator data, obtains the processing time of each request processing stage based on the performance indicator data; obtains historical baseline data matching the performance indicator data based on the webpage request data, and obtains the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data; if it is determined that the front-end stage time is abnormal, it obtains the resource loading time of each page resource, and obtains the front-end loading path based on the resource loading time, so as to identify the front-end performance bottleneck based on the front-end loading path. Therefore, when it is determined that the front-end stage time is abnormal, the front-end performance bottleneck affecting the page loading time is perceived from the front-end perspective, avoiding the phenomenon of no alarms on the server side while the user perceives a performance degradation. This ensures that the obtained front-end performance bottleneck truly reflects the user's visual experience, guaranteeing the accuracy and timeliness of webpage performance monitoring results.

[0081] Optionally, the webpage performance monitoring device is also used to sequentially expand the call hierarchy of the application programming interface calls in the current page to obtain the call time of different call stages, and to obtain the backend performance bottleneck based on the call method of the target call stage with the longest call time.

[0082] Optionally, the webpage performance monitoring device is also used to obtain the infrastructure status within a corresponding time period based on the webpage request data, and to obtain the infrastructure performance bottleneck based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0083] Optionally, the webpage performance monitoring device is also used to obtain the total time increment based on the performance index data and the historical baseline data, and to obtain the front-end time contribution, back-end time contribution and infrastructure time contribution based on the total time increment, the front-end performance bottleneck, the back-end performance bottleneck and the infrastructure performance bottleneck.

[0084] Optionally, the webpage performance monitoring device is further configured to obtain the processing priorities of the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck based on the repair difficulty coefficient and impact range coefficient corresponding to the front-end time consumption contribution, the back-end time consumption contribution, and the infrastructure time consumption contribution, respectively, as well as the processing priorities of the front-end time consumption contribution, the back-end time consumption contribution, and the infrastructure time consumption contribution.

[0085] Optionally, the webpage performance monitoring device is further configured to, if it is determined that the backend stage time consumption is abnormal and / or the network stage time consumption is abnormal, and the frontend stage time consumption is normal, sequentially expand the call hierarchy of the application programming interface calls in the current page to obtain the call consumption of different call stages, and obtain the backend performance bottleneck based on the call method of the target call stage with the longest call consumption; obtain the infrastructure status within the corresponding time period based on the webpage request data, and obtain the infrastructure performance bottleneck based on the infrastructure status; wherein, the infrastructure status includes the database host status, container status, and content delivery network node status.

[0086] The above-described apparatus can execute the webpage performance monitoring method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in this embodiment can be found in the webpage performance monitoring method provided in any embodiment of the present invention.

[0087] Example 5 Figure 5 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, electronic devices, blade electronic devices, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0088] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0089] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0090] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as web page performance monitoring methods.

[0091] In some embodiments, the web page performance monitoring method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on a heterogeneous hardware accelerator via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by a processor, one or more steps of the web page performance monitoring method described above may be performed. Alternatively, in other embodiments, the processor may be configured to perform the web page performance monitoring method by any other suitable means (e.g., by means of firmware).

[0092] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0093] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0094] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0095] To provide user interaction, the systems and techniques described herein can be implemented on a heterogeneous hardware accelerator, which includes: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the heterogeneous hardware accelerator. Other types of devices can also be used to provide user interaction; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or haptic feedback); and input from the user can be received in any form (including sound input, voice input, or haptic input).

[0096] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0097] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0098] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0099] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for monitoring webpage performance, characterized in that, include: In response to obtaining webpage request data and performance indicator data, the processing time of each request processing stage is obtained based on the performance indicator data; wherein, the request processing stage includes the network stage, the backend stage, and the frontend stage; Based on the webpage request data, obtain historical baseline data that matches the performance index data, and based on the processing time of each stage and the historical baseline data, obtain the performance analysis results of each request processing stage; If the time consumption of the front-end stage is determined to be abnormal, the resource loading time of each page resource is obtained, and the front-end loading path is obtained based on the resource loading time, so as to identify the front-end performance bottleneck based on the front-end loading path.

2. The webpage performance monitoring method according to claim 1, characterized in that, After identifying the front-end performance bottleneck based on the aforementioned front-end loading path, the process also includes: Expand the call hierarchy of the application programming interface calls on the current page in sequence to obtain the call time of different call stages, and identify the backend performance bottleneck based on the call method of the target call stage with the longest call time.

3. The webpage performance monitoring method according to claim 2, characterized in that, After identifying the backend performance bottleneck based on the call method of the target call phase with the longest call duration, the following steps are also included: The infrastructure status within a corresponding time period is obtained based on the webpage request data, and infrastructure performance bottlenecks are identified based on the infrastructure status; wherein, the infrastructure status includes database host status, container status, and content delivery network node status.

4. The webpage performance monitoring method according to claim 3, characterized in that, After identifying infrastructure performance bottlenecks based on the infrastructure status, the process also includes: The total time increment is obtained based on the performance metric data and the historical baseline data. The front-end time contribution, back-end time contribution, and infrastructure time contribution are obtained based on the total time increment, the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck.

5. The webpage performance monitoring method according to claim 4, characterized in that, After obtaining the front-end time contribution, back-end time contribution, and infrastructure time contribution based on the total time increment, the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck, the process further includes: Based on the front-end time consumption contribution, the back-end time consumption contribution, and the infrastructure time consumption contribution, the corresponding repair difficulty coefficient and impact range coefficient, as well as the front-end time consumption contribution, the back-end time consumption contribution, and the infrastructure time consumption contribution, the processing priorities of the front-end performance bottleneck, the back-end performance bottleneck, and the infrastructure performance bottleneck are obtained.

6. The webpage performance monitoring method according to claim 1, characterized in that, After obtaining the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data, the method further includes: If it is determined that the backend stage time consumption is abnormal and / or the network stage time consumption is abnormal, while the frontend stage time consumption is normal, the call hierarchy of the application programming interface calls in the current page is expanded sequentially to obtain the call time consumption of different call stages, and the backend performance bottleneck is obtained based on the call method of the target call stage with the longest call time. The infrastructure status within a corresponding time period is obtained based on the webpage request data, and infrastructure performance bottlenecks are identified based on the infrastructure status; wherein, the infrastructure status includes database host status, container status, and content delivery network node status.

7. A webpage performance monitoring device, characterized in that, include: The stage processing time acquisition module is used to acquire web page request data and performance indicator data, and to acquire the stage processing time of each request processing stage based on the performance indicator data; wherein, the request processing stage includes the network stage, the backend stage and the frontend stage. The performance result acquisition module is used to acquire historical baseline data that matches the performance indicator data based on the web page request data, and to acquire the performance analysis results of each request processing stage based on the processing time of each stage and the historical baseline data. The front-end bottleneck acquisition module is used to acquire the resource loading time of each page resource if it is determined that the front-end stage is abnormal, and to acquire the front-end loading path based on the resource loading time, so as to acquire the front-end performance bottleneck based on the front-end loading path.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the web page performance monitoring method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the webpage performance monitoring method according to any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the webpage performance monitoring method according to any one of claims 1-6.

Images