A method and system for analyzing power grid website optimization

Abstract

This invention discloses a method and system for analyzing power grid website optimization. In this invention, the cache validity period of hot resources is dynamically compressed based on the real-time rendering level, ensuring that the front-end prioritizes obtaining the latest topology data during periods of rapid load increase. Simultaneously, temporary composite indexes are created for combinations of high-frequency, slow queries, effectively shortening the database retrieval path. The sampling step size and timeout timer no longer use fixed values ​​but are adjusted dynamically based on the current concurrency and average interface response time. This avoids the problems of misjudgment due to overly aggressive fixed parameters under extreme traffic conditions or resource idleness due to overly conservative parameters. The temporary indexes are retained or removed based on the actual query hit rate during off-peak periods, ensuring that maintenance costs always match benefits. This eliminates the need for manual parameter tuning of optimization strategies. Even if the power grid operation mode or user behavior changes, the system can automatically approach the optimal configuration through multiple iterations, thus maintaining the timeliness of optimization effects over the long term.

Description

Technical Field

[0001] This invention belongs to the field of power grid safety monitoring technology, specifically a method and system for analyzing power grid site optimization. Background Technology

[0002] The power grid dispatch and monitoring website is the core business platform of the power dispatch and control center, and its performance directly affects the dispatchers' speed of perception and efficiency in handling the power grid's operational status. With the continuous expansion of the power grid and the intensified load fluctuations following the large-scale integration of new energy sources, the workload for dispatchers during peak hours—frequently refreshing main wiring diagrams, load forecast curves, and alarm event lists—has significantly increased. Currently, performance optimization for such websites generally adopts a technical approach of static presets combined with manual adjustments. Power grid website optimization refers to a digital governance process that systematically upgrades the underlying architecture, front-end interaction, and business processes of the State Grid, China Southern Power Grid, and related power service portal websites, based on the characteristics of the power industry. Its core lies in building a high-concurrency, highly available, and secure infrastructure to ensure smooth and stable access for massive user traffic during peak summer electricity demand and the release of tiered electricity pricing policies.

[0003] However, the optimization strategies of existing power grid websites are mostly statically configured, with fixed values ​​for cache validity period, query index, timeout count, and sampling step size. This makes it impossible to automatically switch between peak and off-peak periods, thus affecting the flexibility and regulation efficiency during use. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for analyzing power grid website optimization in order to solve the problems mentioned above.

[0005] The technical solution adopted in this invention is as follows: A method for analyzing power grid site optimization, comprising the following steps: S1: Collect access logs, server resources, connection pool status and outbound traffic for the past seven days, record the number of calls, response time and timeout ratio of each module by hour, and store them in partitions for subsequent calculations.

[0006] S2: Clean the window data daily, remove outliers, and calculate the mean and standard deviation of page loading and interface latency for each period during off-peak and three peak periods to generate a dynamic baseline. The baseline is simultaneously fed into step S3 for parameter normalization and serves as the comparison benchmark for step S5.

[0007] S3: Align user clicks with load change rate and overload signal timing to establish a spatiotemporal correlation model. Based on the pattern of early access surges after the load exceeds the threshold, formulate dynamic rendering and pre-push strategies, and introduce feedback factors to automatically correct trigger offsets based on historical hit rates. Output rendering level, pre-push list, and refresh coefficient to step S4.

[0008] S4: The parameters output from step S3 are encapsulated into versioned configuration plugins. During peak hours, the cache expiration strategy is dynamically modified, composite indexes are added to frequently queried fields, and the sampling step size and timeout retransmission count of the front-end chart library are adjusted. During off-peak hours, the system automatically reverts to the baseline values ​​of step S2 to maintain lightweight operation. All changes are versioned and support one-click rollback. A gradual, phased rollout is used to reduce the risk of mis-adjustments. New logs and slow query records after implementation are appended to a separate data table in the format of step S1 for easy extraction and comparison in step S5.

[0009] S5: Take the difference between the peak index 72 hours after step S4 and the baseline of step S2, and check the three items: loading time reduction, interface error change, and cache hit improvement. If all three items are met, the version is fixed and the process ends; otherwise, step S1 is triggered to re-collect the latest data, and step S3 is driven to adjust the feedback factor according to the failure characteristics, automatically entering the next iteration.

[0010] In a preferred embodiment, in step S1, a log collection agent is deployed and mounted on the web server and database middleware to continuously capture the URL, source IP, user operation type, server processing time and returned bytes of each page request for 7 consecutive days. At the same time, the number of active connections in the database connection pool and the network egress bandwidth utilization are sampled every 15 seconds.

[0011] In a preferred embodiment, in step S2, a batch cleaning task is performed once a day. First, records with response times greater than three times the standard deviation or status codes other than 200 are removed, as these values ​​are usually caused by planned downtime or external crawler attacks and do not represent the normal user experience. After cleaning, the average first-screen loading time of the main wiring diagram page and the 95th percentile latency of the load prediction interface are calculated during off-peak hours and the three peak periods: 8:00-10:00 AM, 11:00-1:00 PM, and 7:00-9:00 PM. These values ​​are then combined to form the daily baseline table. Baseline updates do not rely on manual review; the system automatically overwrites the old baseline with the new one, while retaining the baseline history for the most recent 7 days for trend observation.

[0012] In a preferred embodiment, in step S3, during the automatic correction of the trigger offset by the feedback factor, the actual hit rate of each pre-push action within the past 72 hours is statistically analyzed every morning. A hit is defined as the substation SVG file in the pre-push list being actually clicked and loaded by the user within 4 minutes after being pushed. The total number of hits within these 72 hours is divided by the total number of pre-push actions to obtain the historical hit rate for that day.

[0013] If the hit rate is below 60%, the feedback factor will gradually shorten the trigger offset in the prediction function from the default 4 minutes to 3 minutes, because an excessively large offset will cause the push to be made too early, and the cache will be occupied by other resources when the user accesses the site.

[0014] If the hit rate is higher than 85%, the offset will be extended to 5 minutes, because if the offset is too small, the user will initiate the original request before the push is completed.

[0015] In a preferred embodiment, in step S4, a basic adjustment cycle of 5 minutes is used. At the beginning of each cycle, the rendering level, pre-push list, and refresh coefficient output in step S3 are read. The peak period is determined by the three peak windows defined in the S2 baseline: morning, noon, and evening. Once the current time falls within a window, the algorithm starts dynamic adjustment. The modification of the cache expiration policy is not applied uniformly to all resources, but only to the topology data and static metafiles of hot areas marked in the S3 pre-push list. Their cache validity period is compressed from the usual 600s to 120s, while the browser-side mandatory verification header is enabled to ensure that the delay of the graphics data obtained by the user after a sudden change in load does not exceed 2 cycles. For non-hot resources, their cache validity period remains unchanged to avoid excessive consumption of the backend verification channel.

[0016] The formula for calculating the validity period of hot resource cache is: ; in The baseline cache duration is 600 seconds. The sensitivity coefficient for power grid load fluctuations is set to 0.03. The hotspot level output by S3 is between 1 and 5.

[0017] In a preferred embodiment, in step S4, the database slow query records for the most recent hour are scanned every 10 minutes to extract combined query conditions involving the device parameter table, measurement history table, and alarm event table. When a combination of triplet fields appears more than 15 times per 100 queries during the peak window, the algorithm automatically creates a composite index for that combination, and the index's storage period is tied to the current peak period. Once the off-peak period arrives, the algorithm does not immediately delete these indexes, but instead marks them as low priority and adjusts the query optimizer's index hint weight, causing the optimizer to prioritize the use of existing single-column indexes. Composite indexes are only used when the optimizer's estimated cost is less than 30% of that of single-column indexes, thus balancing maintenance costs and query benefits.

[0018] The formula for determining the creation of a composite index is: ; in The number of times a specific combination of fields appears in the last hour. This represents the total number of queries during the same period. This is a unit step function; it outputs 1 to trigger creation when the difference within the parentheses is greater than 0.

[0019] In a preferred embodiment, in step S4, the sampling step size is determined jointly based on the current query time span and the rendering level given in S3. When the rendering level is level 1 (high precision), the step size is fixed at 1 / 1.25 of the original data. When the rendering level drops to level 3 (low precision), the step size expands to 1 / 5 of the original data. The number of timeout retransmissions is uniformly reduced from 3 to 1 during peak periods. However, the initial value of the timeout timer is not fixed at 4 seconds, but dynamically fluctuates based on the average response time of the interface over the last 5 periods. The upper limit of the fluctuation is 1.8 times the average value, and the lower limit is 0.6 times the average value. After a timeout is triggered, the priority of retransmission requests automatically drops to the end of the queue to avoid retransmission traffic exacerbating network congestion.

[0020] The formula for calculating the dynamic sampling step size of front-end charts is: ; in One-fifth of the original step size, It is 1.25 times the original step size. To adjust the slope to a value of 1.5, The rendering level value for S3 output is 1~3.

[0021] The formula for setting the initial value of the timeout timer is: ; in This represents the average response time of the interface over the most recent five periods. This represents the number of concurrent requests in the current period. This represents the peak concurrent users during the corresponding peak period in the S2 baseline.

[0022] In a preferred embodiment, in step S4, the rollback operation during off-peak hours is not a simple parameter reset to zero, but rather a gradual relaxation based on the statistical values ​​of the corresponding time period in the baseline of S2. The algorithm employs a damping coefficient to ensure that the cache validity period, sampling step size, and timeout count approach the baseline values ​​exponentially over the first three periods after leaving the peak window, rather than experiencing instantaneous jumps, thus preventing sudden parameter changes from causing new performance fluctuations. After the rollback is complete, all temporarily created composite indexes enter an observation period. If no queries hit the index within two consecutive off-peak hours, it is automatically deleted; otherwise, it is retained until the next peak window.

[0023] The formula for calculating the damping coefficient during the off-peak retreat phase is: ; in This is the current parameter value at the end of the peak window. The relaxation rate is set to 0.4. The cycle count value after leaving the peak window starts to increase from zero.

[0024] The formula for determining whether to retain a temporary composite index is: ; in The value for consecutive off-peak hours is 2. This represents the number of times the index was selected by the query optimizer within the i-th hour. If the sum is greater than 0, output 1 to retain the index; otherwise, trigger deletion.

[0025] In a preferred embodiment, in step S5, the average loading time of the main wiring diagram page within the window from 11:00 to 13:00 every noon is taken, and the difference is calculated between this and the average loading time of the corresponding period in the baseline of S2. The difference is divided by the baseline value to obtain the reduction percentage.

[0026] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. In this invention, the cache validity period of hot resources is dynamically compressed according to the real-time rendering level, enabling the front-end to prioritize obtaining the latest topology data when the load increases sharply. Simultaneously, a temporary composite index is created for high-frequency, slow query combinations, effectively shortening the database retrieval path. The sampling step size and timeout timer no longer use fixed values, but are adjusted dynamically based on the current concurrency and average interface response time. This avoids the problems of misjudgment due to overly aggressive fixed parameters under extreme traffic conditions or resource idleness due to overly conservative parameters, thus ensuring that power grid dispatchers can obtain stable and timely responses when performing operations during critical windows of rapid load increases.

[0027] 2. In this invention, the temporary index is retained or removed based on the actual query hit rate during off-peak periods, ensuring that maintenance costs always match benefits. The feedback factor automatically corrects the pre-specified offset, ensuring it continuously aligns with the dispatcher's actual operating habits. The verification results of step S5 directly drive the adjustment of data collection weights and the correction of weight coefficients. This eliminates the need for manual parameter tuning of the optimization strategy. Even if the power grid operation mode or user behavior changes, the system can automatically approach the optimal configuration through multiple iterations, thus maintaining the timeliness of the optimization effect over the long term. Attached Figure Description

[0028] Figure 1 This is a schematic diagram illustrating the process principle of the present invention; Figure 2 This is a diagram of the step load trend monitoring and trigger configuration interface in this invention; Figure 3 This is a diagram of the pre-propagation strategy output and feedback correction panel interface in this invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0030] Reference Figure 1-2 , A method for analyzing power grid site optimization includes the following steps: S1: Collect access logs, server resources, connection pool status and outbound traffic for the past seven days, record the number of calls, response time and timeout ratio of each module by hour, and store them in partitions for subsequent calculations.

[0031] S2: Clean the window data daily, remove outliers, and calculate the mean and standard deviation of page loading and interface latency for each period during off-peak and three peak periods to generate a dynamic baseline. The baseline is simultaneously fed into step S3 for parameter normalization and serves as the comparison benchmark for step S5.

[0032] S3: Align user clicks with load change rate and overload signal timing to establish a spatiotemporal correlation model. Based on the pattern of early access surges after the load exceeds the threshold, formulate dynamic rendering and pre-push strategies, and introduce feedback factors to automatically correct trigger offsets based on historical hit rates. Output rendering level, pre-push list, and refresh coefficient to step S4.

[0033] S4: The parameters output from step S3 are encapsulated into versioned configuration plugins. During peak hours, the cache expiration strategy is dynamically modified, composite indexes are added to frequently queried fields, and the sampling step size and timeout retransmission count of the front-end chart library are adjusted. During off-peak hours, the system automatically reverts to the baseline values ​​of step S2 to maintain lightweight operation. All changes are versioned and support one-click rollback. A gradual, phased rollout is used to reduce the risk of mis-adjustments. New logs and slow query records after implementation are appended to a separate data table in the format of step S1 for easy extraction and comparison in step S5.

[0034] S5: Take the difference between the peak index 72 hours after step S4 and the baseline of step S2, and check the three items: loading time reduction, interface error change, and cache hit improvement. If all three items are met, the version is fixed and the process ends; otherwise, step S1 is triggered to re-collect the latest data, and step S3 is driven to adjust the feedback factor according to the failure characteristics, automatically entering the next iteration.

[0035] In step S1, a log collection agent is deployed and mounted on the web server and database middleware. It continuously captures the URL, source IP, user operation type, server processing time and returned bytes of each page request for 7 days. At the same time, it samples the number of active connections in the database connection pool and the network egress bandwidth utilization rate every 15 seconds.

[0036] In step S2, a batch cleaning task is performed daily. First, records with response times greater than three standard deviations or status codes other than 200 are removed, as these values ​​are typically caused by planned downtime or external web crawler attacks and do not represent the normal user experience. After cleaning, the average first-screen loading time of the main wiring diagram page and the 95th percentile latency of the load prediction interface are calculated during off-peak hours and the three peak periods: 8:00-10:00 AM, 11:00-1:00 PM, and 7:00-9:00 PM. These values ​​are then combined to form the daily baseline table. Baseline updates do not rely on manual review; the system automatically overwrites the old baseline with the new one, while retaining the baseline history for the most recent 7 days for trend observation.

[0037] In step S3, during the automatic correction of the trigger offset by the feedback factor, the actual hit rate of each pre-push action over the past 72 hours is statistically analyzed every morning. A hit is defined as the substation SVG file in the pre-push list being actually clicked and loaded by the user within 4 minutes after being pushed. The historical hit rate for the day is obtained by dividing the total number of hits over these 72 hours by the total number of pre-push actions.

[0038] If the hit rate is below 60%, the feedback factor will gradually shorten the trigger offset in the prediction function from the default 4 minutes to 3 minutes, because an excessively large offset will cause the push to be made too early, and the cache will be occupied by other resources when the user accesses the site.

[0039] If the hit rate is higher than 85%, the offset will be extended to 5 minutes, because if the offset is too small, the user will initiate the original request before the push is completed.

[0040] In step S4, a basic adjustment cycle of 5 minutes is used. At the beginning of each cycle, the rendering level, pre-push list, and refresh coefficient output from step S3 are read. The peak period is determined by the three peak windows defined in the S2 baseline: morning, noon, and evening. Once the current time falls within a window, the algorithm starts dynamic adjustment. The modification to the cache expiration policy is not applied uniformly to all resources, but only to the topology data and static metafiles of hot areas marked in the S3 pre-push list. Their cache validity period is compressed from the usual 600s to 120s, while the browser-side mandatory verification header is enabled to ensure that the delay in obtaining graphics data for users after a sudden change in load does not exceed 2 cycles. For non-hot resources, their cache validity period remains unchanged to avoid excessive consumption of the backend verification channel.

[0041] The formula for calculating the validity period of hot resource cache is: ; in The baseline cache duration is 600 seconds. The sensitivity coefficient for power grid load fluctuations is set to 0.03. The hotspot level output by S3 is between 1 and 5.

[0042] In step S4, the database slow query records for the past hour are scanned every 10 minutes to extract combined query conditions involving the device parameter table, measurement history table, and alarm event table. When a combination of triplet fields appears more than 15 times per 100 queries during the peak window, the algorithm automatically creates a composite index for that combination. The storage period of the index is tied to the current peak period. Once the off-peak period arrives, the algorithm does not immediately delete these indexes but marks them as low priority and adjusts the index hint weight of the query optimizer. This causes the optimizer to prioritize the use of existing single-column indexes, and composite indexes are only used when the optimizer's estimated cost is less than 30% of that of a single-column index, thus balancing maintenance costs and query benefits.

[0043] The formula for determining the creation of a composite index is: ; in The number of times a specific combination of fields appears in the last hour. This represents the total number of queries during the same period. This is a unit step function; it outputs 1 to trigger creation when the difference within the parentheses is greater than 0.

[0044] In step S4, the sampling step size is determined by both the current query time span and the rendering level given in S3. When the rendering level is level 1 (high precision), the step size is fixed at 1 / 1.25 of the original data. When the rendering level drops to level 3 (low precision), the step size expands to 1 / 5 of the original data. The number of timeout retransmissions is uniformly reduced from 3 to 1 during peak periods. However, the initial value of the timeout timer is not fixed at 4 seconds, but dynamically fluctuates based on the average response time of the interface over the last 5 periods. The upper limit of the fluctuation is 1.8 times the average, and the lower limit is 0.6 times the average. After a timeout is triggered, the priority of retransmission requests automatically drops to the end of the queue to avoid retransmission traffic exacerbating network congestion.

[0045] The formula for calculating the dynamic sampling step size of front-end charts is: ; in One-fifth of the original step size, It is 1.25 times the original step size. To adjust the slope to a value of 1.5, The rendering level value for S3 output is 1~3.

[0046] The formula for setting the initial value of the timeout timer is: ; in This represents the average response time of the interface over the most recent five periods. This represents the number of concurrent requests in the current period. This represents the peak concurrent users during the corresponding peak period in the S2 baseline.

[0047] In step S4, the rollback operation during off-peak hours is not a simple parameter reset to zero, but rather a gradual relaxation based on the statistical values ​​of the corresponding period in the S2 baseline. The algorithm employs a damping coefficient to ensure that the cache expiration time, sampling step size, and timeout count approach the baseline values ​​exponentially over the first three periods after leaving the peak window, rather than experiencing instantaneous jumps, thus preventing sudden parameter changes from causing new performance fluctuations. After the rollback is complete, all temporarily created composite indexes enter an observation period. If no queries hit the index for two consecutive off-peak hours, it is automatically deleted; otherwise, it is retained until the next peak window.

[0048] The formula for calculating the damping coefficient during the off-peak retreat phase is: ; in This is the current parameter value at the end of the peak window. The relaxation rate is set to 0.4. The cycle count value after leaving the peak window starts to increase from zero.

[0049] The formula for determining whether to retain a temporary composite index is: ; in The value for consecutive off-peak hours is 2. This represents the number of times the index was selected by the query optimizer within the i-th hour. If the sum is greater than 0, output 1 to retain the index; otherwise, trigger deletion.

[0050] In step S5, the average loading time of the main wiring diagram page within the window from 11:00 to 13:00 every day is taken, and the difference between this and the average loading time of the corresponding period in the baseline of S2 is calculated. The difference is divided by the baseline value to obtain the reduction percentage.

[0051] Simultaneously, the system calculates the proportion of timeouts returned by the load prediction interface within the same window relative to the total number of requests. This proportion is subtracted from the timeout proportion in the baseline to obtain the error change. Then, the system calculates the proportion of static resources for sites in the pre-push list that are already in the cache when a user actually accesses the site, and subtracts the historical average of this proportion from the baseline to obtain the cache improvement value. If the reduction percentage is greater than 15%, the error change is less than 0, and the cache improvement value is greater than 0.2, the system is deemed to have met the criteria for this round. The system then writes the current plugin version number to the stable version configuration table and stops subsequent actions. If any of the three conditions are not met, the system automatically encapsulates the name and value of the failed metric into an alarm event and sends it to the S1 collection filter. This increases the sampling weight of the raw logs for that metric by 5 times in the next round of collection. Simultaneously, the failure information is transmitted to the S3 parameter adjustment interface, allowing it to reduce the weight coefficient of the corresponding dimension in the next modeling iteration, and then immediately starts the next iteration.

[0052] A power grid site optimization analysis system is provided, which operates based on the aforementioned power grid site optimization analysis method.

[0053] Comparison: Using industry-standard optimization solutions The caching strategy uses a uniform, fixed validity period across the entire site: 600 seconds for static resources and no caching for dynamic data interfaces. The database only retains single-column indexes for fields pre-defined during table creation, without any runtime additions or deletions. The front-end chart library's sampling step size is locked at one-quarter of the original data points, maintaining this ratio regardless of the query duration. The timeout retransmission mechanism uses a fixed 3 retries, with a constant timeout timer of 4 seconds. The pre-push mechanism sorts the top 20 most popular pages based on the total number of site visits the previous day and pushes them to all online browsers at 1 AM daily, without distinguishing between user location or real-time power grid status. All parameters remain consistent 24 / 7, with no peak / off-peak switching logic. Maintenance personnel manually adjust some values ​​every two weeks based on observed congestion.

[0054] A comparative test was conducted over five consecutive working days. Three typical pages were selected as test objects: the main wiring diagram page, which handles topology rendering and circuit breaker status updates; the load forecast curve page, which displays data overlaid across multiple time scales; and the alarm event list page, which handles real-time scrolling updates and high-frequency polling. Each day during the test was divided into off-peak periods (9:30-11:30 and 14:00-16:00) and peak periods (11:30-13:00 and 16:30-18:30). The initial screen loading time, API request timeout rate, time taken for complete rendering after user interaction, and peak server CPU utilization were recorded for each page during each time period.

[0055] Two additional auxiliary metrics were recorded: the number of slow database queries per minute and the pre-hit rate of browser-based cached resources before the user's actual click. The standard solution and the optimized solution were run alternately on the same hardware cluster. The standard solution was run on the first day, the optimized solution on the second day, the standard solution on the third day, the optimized solution on the fourth day, and the standard solution was run again on the fifth day for a final comparison. The average value of each run was taken as the final result. The specific test data is summarized below: ; The data in the table shows that: During peak hours, the standard solution resulted in initial screen loading times exceeding 3 seconds across all platforms, with the main wiring diagram and load curve even surpassing 4.8 seconds, severely exceeding the scheduler's tolerance threshold. Interface timeout rates reached 9.6% to 18.3% during peak hours, meaning one in every five to ten requests failed. Schedulers repeatedly refreshed the page during high-load critical windows but frequently received timeout errors, easily delaying timely handling of line overload. Full rendering took even longer than the initial screen loading time, with the main wiring diagram reaching 6.7 seconds. This indicated that while the initial screen framework appeared, the image and data metadata and real-time status were not fully populated, resulting in a half-finished interface for users. Peak CPU usage climbed to 65% to 78%, approaching the server's warning threshold. Under the standard solution, maintenance personnel had to manually restart some services temporarily to alleviate the pressure. Slow queries exceeded 6 per minute, with queries related to the main wiring diagram even reaching 12.4 per minute, indicating that the efficiency of multi-table joins deteriorated sharply under peak concurrency due to the lack of dynamic composite indexes. The cache pre-hit rate is only about 30%, the pre-pushed content is seriously mismatched with the actual needs of the dispatcher, a large amount of pushed resources are not used, and the substation topology data that is really needed does not arrive in advance.

[0056] From the above, we can conclude that: In this invention, the cache validity period of hot resources is dynamically compressed based on the real-time rendering level, enabling the front-end to prioritize obtaining the latest topology data when the load surges. Simultaneously, temporary composite indexes are automatically created for combinations of high-frequency, slow queries, shortening the database retrieval path. The sampling step size and timeout timer are no longer fixed values ​​but fluctuate with the current concurrency and average interface response time, avoiding the problems of fixed parameters being either too aggressive leading to misjudgments or too conservative leading to resource idleness under extreme traffic conditions. These mechanisms collectively ensure that grid dispatchers receive stable and timely responses during critical windows of rapid load increases, allowing them to repeatedly refresh the main wiring diagram and power flow page.

[0057] In this invention, all peak-hour strategies gradually relax to the baseline exponentially after leaving the window, preventing parameter mutations from causing new performance fluctuations. Temporary indexes are retained or removed based on actual query hit rates during off-peak periods, ensuring that maintenance costs always match benefits. Feedback factors automatically correct the pre-specified offset, ensuring it continuously aligns with dispatchers' actual operating habits. The verification results of step S5 directly drive the adjustment of the collection weights in step S1 and the weight coefficients in step S3. This full-chain automatic feedback mechanism eliminates the need for manual parameter tuning of optimization strategies. Even if the power grid operation mode or user behavior changes, the system can automatically approach the optimal configuration through multiple iterations, maintaining the timeliness of optimization effects over the long term.

[0058] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0059] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for analyzing power grid site optimization, characterized in that: The method includes the following steps: S1: Collect access logs, server resources, connection pool status and outbound traffic for the past seven days, record the number of calls, response time and timeout ratio of each module by hour, and store them in partitions for subsequent calculations; S2: Clean the window data daily, remove outliers, and calculate the mean and standard deviation of page loading and interface latency during off-peak and three peak periods to generate a dynamic baseline; the baseline is synchronously supplied to step S3 for parameter normalization and used as the comparison benchmark for step S5. S3: Align user clicks with load change rate and overload signal timing to establish a spatiotemporal correlation model; formulate dynamic rendering and pre-push strategies based on the pattern of early access after load exceeds threshold, and introduce feedback factors to automatically correct trigger offset based on historical hit rate; output rendering level, pre-push list and refresh coefficient to step S4. S4: The parameters output from step S3 are encapsulated into versioned configuration plugins. During peak periods, the cache expiration strategy is dynamically modified, composite indexes are added to high-frequency query fields, and the sampling step size and timeout retransmission count of the front-end chart library are adjusted. During off-peak periods, the system automatically reverts to the baseline values ​​of step S2 to maintain lightweight operation. All changes are versioned and support one-click rollback. At the same time, a canary release is used to gradually expand the scope of effectiveness and reduce the risk of misadjustment. After implementation, new logs and slow query records are appended to an independent data table in the format of step S1, which is convenient for direct extraction and comparison in step S5. S5: Take the difference between the peak index 72 hours after step S4 and the baseline of step S2, and check the three items: loading time reduction, interface error change, and cache hit improvement; if all three items are met, the version is fixed and the process ends; otherwise, step S1 is triggered to re-collect the latest data, and step S3 is driven to adjust the feedback factor according to the failure characteristics, and the process automatically enters the next iteration.

2. The method for analyzing and optimizing power grid sites as described in claim 1, characterized in that: In step S1, a log collection agent is deployed and mounted on the web server and database middleware. It continuously captures the URL, source IP, user operation type, server processing time and returned bytes of each page request for 7 days. At the same time, it samples the number of active connections in the database connection pool and the network egress bandwidth utilization rate every 15 seconds.

3. The method for analyzing power grid site optimization as described in claim 1, characterized in that: In step S2, a batch cleaning task is performed once a day. First, records with response times greater than 3 times the standard deviation or status codes other than 200 are removed, because these values ​​are usually caused by planned downtime or external crawler attacks and do not represent the normal user experience. After cleaning, the average first screen loading time of the main wiring diagram page during off-peak hours and the three peak periods of 8:00 to 10:00, 11:00 to 13:00, and 19:00 to 21:00, as well as the 95th percentile delay of the load prediction interface, are calculated. These values ​​are combined into the baseline table for the day. The baseline is updated without manual review. The system automatically overwrites the old baseline with the new one, while retaining the baseline history of the most recent 7 days for trend observation.

4. The method for analyzing power grid site optimization as described in claim 1, characterized in that: In step S3, during the automatic correction of the trigger offset by the feedback factor, the actual hit rate of each pre-push action in the past 72 hours is statistically analyzed every morning. A hit is defined as the substation SVG file in the pre-push list being actually clicked and loaded by the user within 4 minutes after being pushed. The total number of hits in these 72 hours is divided by the total number of pre-push actions to obtain the historical hit rate for the day. If the hit rate is below 60%, the feedback factor will gradually shorten the trigger offset in the prediction function from the default 4 minutes to 3 minutes, because an excessively large offset will cause the push to be made too early, and the cache will be occupied by other resources when the user accesses the site. If the hit rate is higher than 85%, the offset will be extended to 5 minutes, because if the offset is too small, the user will initiate the original request before the push is completed.

5. The method for analyzing power grid site optimization as described in claim 1, characterized in that: In step S4, a basic adjustment cycle of 5 minutes is used. At the beginning of each cycle, the rendering level, pre-push list, and refresh coefficient output by step S3 are read. The peak period is determined by the three peak windows defined in the S2 baseline: morning, noon, and evening. Once the current time falls into a window, the algorithm starts dynamic adjustment. The modification of the cache expiration policy is not applied uniformly to all resources, but only to the topology data and static metafiles of hot areas marked in the S3 pre-push list. Their cache validity period is compressed from the usual 600s to 120s, and the browser's mandatory verification header is enabled to ensure that the delay of the graphics data obtained by the user after a sudden change in load does not exceed 2 cycles. For non-hot resources, their cache validity period remains unchanged to avoid excessive consumption of the backend verification channel. The formula for calculating the validity period of hot resource cache is: ； in The baseline cache duration is 600 seconds. The sensitivity coefficient for power grid load fluctuations is set to 0.

03. The hotspot level output by S3 is between 1 and 5.

6. The method for analyzing power grid site optimization as described in claim 1, characterized in that: In step S4, the database slow query records within the most recent hour are scanned every 10 minutes to extract combined query conditions involving the device parameter table, measurement history table and alarm event table. When a combination of triplet fields appears more than 15 times per 100 queries during a peak window, the algorithm automatically creates a composite index for that combination, and the storage period of the index is tied to the current peak period. Once off-peak hours arrive, the algorithm will not immediately delete these indexes. Instead, it will mark them as low priority and adjust the index hint weight of the query optimizer, so that the optimizer will give priority to using the original single-column indexes. Composite indexes will only be used when the optimizer estimates the cost to be less than 30% of that of a single-column index, thus balancing maintenance costs and query benefits. The formula for determining the creation of a composite index is: ； in The number of times a specific combination of fields appears in the last hour. This represents the total number of queries during the same period. This is a unit step function; it outputs 1 to trigger creation when the difference within the parentheses is greater than 0.

7. The method for analyzing power grid site optimization as described in claim 1, characterized in that: In step S4, the sampling step size is determined by the current query time span and the rendering level given in S3. When the rendering level is level 1 high precision, the step size is fixed at 1 / 1.25 of the original data. When the rendering level is reduced to level 3 low precision, the step size is expanded to 1 / 5 of the original data. The number of timeout retransmissions is uniformly reduced from 3 to 1 during peak windows. However, the initial value of the timeout timer is not fixed at 4 seconds, but dynamically fluctuates according to the average response time of the interface in the last 5 periods. The upper limit of the fluctuation is 1.8 times the average value, and the lower limit is 0.6 times the average value. After the timeout is triggered, the priority of the retransmission request is automatically reduced to the end of the queue to avoid retransmission traffic from aggravating network congestion. The formula for calculating the dynamic sampling step size of front-end charts is: ； in One-fifth of the original step size, It is 1.25 times the original step size. To adjust the slope to a value of 1.5, The rendering level value for S3 output is 1~3; The formula for setting the initial value of the timeout timer is: ； in This represents the average response time of the interface over the most recent five periods. This represents the number of concurrent requests in the current period. This represents the peak concurrent users during the corresponding peak period in the S2 baseline.

8. The method for analyzing power grid site optimization as described in claim 1, characterized in that: In step S4, the rollback operation during off-peak hours is not a simple parameter reset to zero, but a gradual relaxation based on the statistical values ​​of the corresponding time period in the baseline of S2. The algorithm is designed with a damping coefficient so that the cache validity period, sampling step size, and timeout count approach the baseline value in an exponential decay manner in the first 3 cycles after leaving the peak window, rather than an instantaneous jump, to prevent parameter mutations from causing new performance jitters. After the rollback is completed, all temporarily created composite indexes enter the observation period. If no query hits the index for two consecutive off-peak hours, it is automatically deleted; otherwise, it is retained until the next peak window. The formula for calculating the damping coefficient during the off-peak retreat phase is: ； in This is the current parameter value at the end of the peak window. The relaxation rate is set to 0.

4. The periodic count value after leaving the peak window is incremented from zero. The formula for determining whether to retain a temporary composite index is: ； in The value for consecutive off-peak hours is 2. This represents the number of times the index was selected by the query optimizer within the i-th hour. If the sum is greater than 0, output 1 to retain the index; otherwise, trigger deletion.

9. The method for analyzing power grid site optimization as described in claim 1, characterized in that: In step S5, the average loading time of the main wiring diagram page within the window from 11:00 to 13:00 during the noon peak each day is taken, and the difference between this and the average loading time of the corresponding period in the baseline of S2 is calculated. The difference is divided by the baseline value to obtain the reduction percentage.

10. A system for analyzing power grid site optimization, characterized in that: The system is based on the power grid site optimization method according to any one of claims 1 to 9.

Images