A method to optimize BMC Redfish access efficiency

Abstract

This invention discloses a method for optimizing Redfish access efficiency in the BMC (Backend Management Center) field, belonging to the technical field of remote server management. The method collects and initially categorizes client access data, generates flame graphs based on the data to identify frequently accessed hotspot functions and their calling patterns, and constructs a mapping table between time periods and Nginx worker processes based on the patterns of these hotspot functions and time-period characteristics. Finally, it identifies the current time period and dynamically adjusts the number of processes based on this table. This achieves precise matching between the number of processes and the volume of access requests, effectively reducing resource waste during idle periods and processing latency during peak periods, improving Redfish access efficiency and resource utilization rationality. Furthermore, the entire process is automated, requiring no manual intervention, enhancing the method's practicality and operational reliability.

Description

Technical Field

[0001] This invention relates to the field of server remote management technology, and in particular to a method for optimizing BMC Redfish access efficiency. Background Technology

[0002] With the increasing demands for large-scale data center deployment and server cluster management, the Baseboard Management Controller (BMC), as a core component for remote server management, has become the mainstream interface in the industry for server hardware status query, configuration management, and troubleshooting due to its standardized and easy-to-use advantages. Currently, Nginx is widely used as a reverse proxy server to handle and forward client access requests to the BMC Redfish interface, supporting scenarios with multiple concurrent clients. At the technical application level, data collection, function call monitoring, and performance analysis have become common methods for optimizing interface access efficiency. Visualization tools such as flame graphs are also increasingly used for function call characteristic analysis, helping technical personnel understand the system's operating status. Meanwhile, with the diversification of access scenarios, the volume and type of client access vary significantly at different times, placing higher demands on the access efficiency and resource adaptability of the BMC Redfish interface. The application of related technologies is also developing towards refinement and automation.

[0003] Currently, several technical issues remain to be addressed in the access processing of the BMC Redfish interface: First, the configuration of the number of Nginx worker processes often uses fixed values ​​or simple static adjustments, without dynamic adaptation based on actual access data, function call patterns, and access characteristics at different times. This results in insufficient process numbers during peak hours, leading to increased latency in access request processing, while redundant process numbers occur during idle hours, wasting system resources. Second, data collection lacks systematicity and completeness. Key data such as access request details, processing time, and request status are not comprehensively collected and categorized, making it difficult to support subsequent function call analysis and process configuration optimization. Third, there is a lack of accurate identification of hot functions corresponding to high-frequency access, making it impossible to clearly identify the core functions and call patterns affecting access efficiency, resulting in a lack of targeted process configuration. Fourth, no correlation mechanism between time periods and process configuration has been established. Process adjustments lack clear reference criteria and cannot achieve accurate adaptation based on access needs at different times, ultimately affecting the overall access efficiency and resource utilization rationality of the BMC Redfish interface, making it difficult to meet the efficient management needs of large-scale deployment scenarios. Summary of the Invention

[0004] The purpose of this invention is to overcome one or more shortcomings of the prior art and provide a method for optimizing BMC Redfish access efficiency.

[0005] The objective of this invention is achieved through the following technical solution: A method for optimizing BMC Redfish access efficiency is provided, which includes the following steps: S1. Collect client access-related data, including access request details, access quantity, access time, access type, processing time, and request status, and perform preliminary data classification; S2. Generate a flame graph based on the collected and categorized data, preprocess the data to remove redundant interference, present the function call situation through the flame graph, and determine the hot functions and call patterns corresponding to high-frequency access. S3. Based on the calling patterns of hot functions and the access characteristics of different time periods, generate a table showing the correspondence between time periods and Nginx worker processes, and clarify the time period range, process configuration standards, and effective conditions; S4. Based on the corresponding relationship table, identify the current time period, match the corresponding process configuration, adjust the number of Nginx worker processes, and adapt to the Redfish access request volume.

[0006] Furthermore, step S1 includes the following sub-steps: S1.1. Collect the client's access request content, initiation order, access count statistics, access time nodes, access types, request processing time, and request status; S1.2. Filter and remove data with missing key information, duplicates, and incorrect formats, and unify the format of the remaining data; S1.3. Store the processed data according to time period and data type, create an index and mark the storage location and related information; S1.4. Perform integrity and consistency checks on the stored data, correct any problems found, and then synchronize the data to subsequent processing steps.

[0007] Furthermore, step S2 includes the following sub-steps: S2.1. Perform multi-dimensional analysis on the categorized data, analyzing data distribution, access peaks, function call correlations, and trends; S2.2. Construct a flame graph according to preset rules. The horizontal axis of the flame graph represents the time dimension, and the vertical axis represents the function call dimension. The frequency of function calls is distinguished by color. S2.3. Set a threshold, identify the functions corresponding to high-frequency access based on the threshold, and determine the range of hotspot functions by combining the function's impact on access processing; S2.4. Mark the identifier, name, and call path information of hot functions, sort the hot functions according to call frequency and impact, and extract the core features of hot functions.

[0008] Furthermore, step S3 includes the following sub-steps: S3.1. Divide the time period according to the preset standard, and count the frequency and change characteristics of hotspot functions of different ranking levels in each time period; S3.2. Based on the frequency of occurrence, core characteristics, and processing load of hot functions, determine the range of the number of Nginx worker processes required for each time period; S3.3. Construct a table mapping time periods to Nginx worker processes in chronological order, and clarify the key fields in the table and the process configuration corresponding to each time period; S3.4. Check the rationality of the time period division, the logic of the process configuration, and the accuracy of the data in the corresponding relationship table. After adjusting the table, mark the version and store it.

[0009] Furthermore, step S4 includes the following sub-steps: S4.1. Receive the corresponding relationship table, check the data integrity and format correctness of the table, and store the table to the specified path after the check is passed; S4.2. Obtain the current system time, compare the current time with the time period information in the table, and determine the current time period; S4.3. Find the standard number of Nginx worker processes and the dynamic adjustment rules for the current time period; S4.4. Query the number and status of currently running Nginx worker processes, terminate idle processes that exceed the configured number, start new processes that are less than the configured number, and the new processes complete the configuration loading and reverse proxy service connection; S4.5. Monitor the running status and access request processing of the adjusted Nginx worker processes, and establish an exception handling process to deal with process exceptions.

[0010] Furthermore, in step S1, client access-related data is acquired through periodic collection. The collection frequency is adjusted according to changes in the access scenario. The data generation time and source identifier are recorded and stored along with the access-related data. Data is transmitted using a combination of real-time transmission and cache backup. Data is encrypted during transmission. If collection is interrupted, a recovery process is initiated to replenish the data collected during the interruption.

[0011] Furthermore, in step S2.2, the preset chart generation rules include data preprocessing standards, sampling specifications, and color coding rules. The data preprocessing standards clarify the judgment type and removal method of redundant information. The sampling specifications determine the sampling interval and sampling point selection logic. The time dimension adopts equal time period division or dynamic time period division. The vertical axis is displayed according to the function call stack level and labeled with function identifiers and names. After the flame chart is generated, it is compressed. The compressed flame chart is stored in association with the original data.

[0012] Furthermore, in step S3.2, the processing load is calculated by weighting the function call duration and the call frequency. Hot functions of different sorting levels correspond to different weights. The processing load is divided into three levels: low, medium, and high. Different levels correspond to different Nginx worker process configuration ranges. When determining the process configuration, the process running records in the historical access data are referenced, and the process configuration is adjusted in combination with the total system resources. After testing the feasibility of the process configuration through simulated access scenarios, the configuration is included in the corresponding relationship table.

[0013] Furthermore, in step S4.4, idle processes exceeding the configured number are sorted by idle duration, and processes are terminated sequentially according to the sorting result. Before termination, it is checked whether there are any unfinished access requests in the process. When a new process starts, it loads the configuration parameters required by the Nginx worker process, establishes a connection with the reverse proxy service after initialization, and the process adjustment adopts a smooth switching method. After the new process is ready, access requests are gradually allocated. Processes exceeding the configured number are terminated after processing the current request.

[0014] Furthermore, in step S4.5, the monitoring content includes process running status, resource usage, access request processing progress and results, and records the monitoring data to form a monitoring log. The anomaly handling process includes identifying the anomaly type, terminating the abnormal process, and starting a new process to replace it. At the same time, the anomaly occurrence time, anomaly type and abnormal process identifier are recorded. The anomaly record is stored together with the monitoring log for reference in subsequent adjustments to the corresponding relationship table.

[0015] The beneficial effects of this invention are: (1) Based on data collection, flame graph analysis, time-process configuration table construction and dynamic process adjustment, the number of processes is accurately matched with the number of access requests, effectively reducing request processing latency; (2) The data filtering and verification, smooth process switching and exception handling mechanism work together to avoid wasting resources during idle periods and ensure the continuity and stability of access request processing; (3) Full-process automated execution and data traceability optimization require no manual intervention, can be adapted to different access scenarios, and improve the practicality and long-term operational reliability of the method. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the steps involved in optimizing BMC Redfish access efficiency; Figure 2 The following is a flowchart illustrating the specific steps of a method for optimizing BMC Redfish access efficiency, provided as an example. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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 are within the scope of protection of the present invention.

[0018] Example 1 See Figure 1 This embodiment provides a method for optimizing BMC Redfish access efficiency, which includes the following steps: S1. Collect client access-related data, including access request details, access quantity, access time, access type, processing time, and request status, and perform preliminary data classification; S2. Generate a flame graph based on the collected and categorized data, preprocess the data to remove redundant interference, present the function call situation through the flame graph, and determine the hot functions and call patterns corresponding to high-frequency access. S3. Based on the calling patterns of hot functions and the access characteristics of different time periods, generate a table showing the correspondence between time periods and Nginx worker processes, and clarify the time period range, process configuration standards, and effective conditions; S4. Based on the corresponding relationship table, identify the current time period, match the corresponding process configuration, adjust the number of Nginx worker processes, and adapt to the Redfish access request volume.

[0019] In some embodiments, step S1 includes the following sub-steps: S1.1. Collect the client's access request content, initiation order, access count statistics, access time nodes, access types, request processing time, and request status; S1.2. Filter and remove data with missing key information, duplicates, and incorrect formats, and unify the format of the remaining data; S1.3. Store the processed data according to time period and data type, create an index and mark the storage location and related information; S1.4. Perform integrity and consistency checks on the stored data, correct any problems found, and then synchronize the data to subsequent processing steps.

[0020] In some embodiments, step S2 includes the following sub-steps: S2.1. Perform multi-dimensional analysis on the categorized data, analyzing data distribution, access peaks, function call correlations, and trends; S2.2. Construct a flame graph according to preset rules. The horizontal axis of the flame graph represents the time dimension, and the vertical axis represents the function call dimension. The frequency of function calls is distinguished by color. S2.3. Set a threshold, identify the functions corresponding to high-frequency access based on the threshold, and determine the range of hotspot functions by combining the function's impact on access processing; S2.4. Mark the identifier, name, and call path information of hot functions, sort the hot functions according to call frequency and impact, and extract the core features of hot functions.

[0021] In some embodiments, step S3 includes the following sub-steps: S3.1. Divide the time period according to the preset standard, and count the frequency and change characteristics of hotspot functions of different ranking levels in each time period; S3.2. Based on the frequency of occurrence, core characteristics, and processing load of hot functions, determine the range of the number of Nginx worker processes required for each time period; S3.3. Construct a table mapping time periods to Nginx worker processes in chronological order, and clarify the key fields in the table and the process configuration corresponding to each time period; S3.4. Check the rationality of the time period division, the logic of the process configuration, and the accuracy of the data in the corresponding relationship table. After adjusting the table, mark the version and store it.

[0022] In some embodiments, step S4 includes the following sub-steps: S4.1. Receive the corresponding relationship table, check the data integrity and format correctness of the table, and store the table to the specified path after the check is passed; S4.2. Obtain the current system time, compare the current time with the time period information in the table, and determine the current time period; S4.3. Find the standard number of Nginx worker processes and the dynamic adjustment rules for the current time period; S4.4. Query the number and status of currently running Nginx worker processes, terminate idle processes that exceed the configured number, start new processes that are less than the configured number, and the new processes complete the configuration loading and reverse proxy service connection; S4.5. Monitor the running status and access request processing of the adjusted Nginx worker processes, and establish an exception handling process to deal with process exceptions.

[0023] In some embodiments, in step S1, client access-related data is acquired through periodic collection. The collection frequency is adjusted according to changes in the access scenario. The data generation time and source identifier are recorded and stored together with the access-related data. Data is transmitted using a combination of real-time transmission and cache backup. Data is encrypted during transmission. If collection is interrupted, a recovery process is initiated to collect the data during the interruption.

[0024] In some embodiments, in step S2.2, the preset chart generation rules include data preprocessing standards, sampling specifications, and color coding rules. The data preprocessing standards clarify the determination type and removal method of redundant information. The sampling specifications determine the sampling interval and sampling point selection logic. The time dimension adopts equal time period division or dynamic time period division. The vertical axis is displayed according to the function call stack level and the function identifier and name are marked. After the flame chart is generated, it is compressed. The compressed flame chart is stored in association with the original data.

[0025] In some embodiments, in step S3.2, the processing load is calculated by weighting the function call duration and the call frequency. Hot functions of different sorting levels correspond to different weights. The processing load is divided into three levels: low, medium and high. Different levels correspond to different Nginx worker process configuration ranges. When determining the process configuration, the process running records in the historical access data are referenced. The process configuration is adjusted in combination with the total system resources. After testing the feasibility of the process configuration through simulated access scenarios, the configuration is included in the corresponding relationship table.

[0026] In some embodiments, in step S4.4, idle processes exceeding the configured number are sorted by idle duration, and processes are terminated sequentially according to the sorting result. Before termination, it is checked whether there are any unfinished access requests in the process. When a new process starts, the configuration parameters required by the Nginx worker process are loaded. After initialization is completed, a connection with the reverse proxy service is established. Process adjustment adopts a smooth switching method. After the new process is ready, access requests are gradually allocated. Processes exceeding the configured number are terminated after processing the current request.

[0027] In some embodiments, in step S4.5, the monitoring content includes process running status, resource usage, access request processing progress and processing results, and the monitoring data is recorded to form a monitoring log. The anomaly handling process includes identifying the anomaly type, terminating the abnormal process, and starting a new process to replace it. At the same time, the anomaly occurrence time, anomaly type and anomaly process identifier are recorded. The anomaly record is stored together with the monitoring log for reference in subsequent adjustments to the corresponding relationship table.

[0028] Example 2 This embodiment discloses a specific implementation process for optimizing BMC Redfish access efficiency. Through systematically collecting client access data, constructing flame graphs to locate hotspot functions, building a table mapping time periods to process configurations, and dynamically adjusting the number of Nginx worker processes, it achieves optimized access efficiency and rational resource utilization. Figure 2 As shown, the specific implementation process is as follows: S1. Collect and initially classify relevant access data: S1.1. Collect the client's access request content, initiation order, access count statistics, access time, access type, request processing time, and request status: Access request content is collected by capturing various access commands sent by the client to the BMC, including the specific descriptions of data query commands, data submission commands, data modification commands, and data deletion commands, ensuring a complete record of the operation direction and core requirements of each request. The order of access requests is recorded using timestamps; each captured access request is recorded in its order of initiation, forming an ordered request sequence. Access count is achieved through real-time counting, accumulating and recording all valid access requests received within a unit of time, ensuring that the statistical results reflect the access density at different times. The collection of access time nodes covers the request initiation time, request reception time, and other relevant information. The system includes a data entry time, a request start time, and a request end time, each time point accurate to the smallest identifiable time unit, providing a foundation for subsequent time segmentation and analysis. Access types are categorized by operation attributes into data query access, data submission access, data modification access, and data deletion access, with each access request corresponding to a unique access type identifier. Request processing time is obtained by calculating the difference between the request start time and processing end time, directly reflecting the processing time of a single request. Request status includes three states: successful processing, processing in progress, and processing failure. When processing fails, a failure identifier must be recorded synchronously to provide a basis for subsequent data filtering and anomaly analysis.

[0029] S1.2. Filter and remove data with missing key information, duplicates, and incorrect formats, and standardize the format of the remaining data: The criteria for determining data lacking key information are records that lack one or more of the following core data: access request content, access time, access type, and request status. Such data cannot meet the needs of subsequent analysis and is directly filtered out. Duplicate data is determined by comparing the access request content, initiation time, and client source identifier. When all three are identical, it is considered duplicate data, and only the first valid record is retained; the remaining duplicate records are removed. Data with incorrect format refers to records not stored according to the preset data format, including cases where field length exceeds limits, data type mismatches, or encoding formats are inconsistent. This type of data is also included in the filtering and removal scope. The retained valid data undergoes format unification processing, converting data from different sources and with different initial formats into the preset standard format, unifying field length, data type, and encoding methods to ensure that all valid data is stored in a consistent format, providing a unified data foundation for subsequent retrieval, analysis, and processing.

[0030] S1.3. Store the processed data by time period and data type, create indexes, and label the storage location and associated information: Time periods are divided according to a pre-defined unified standard, dividing the entire day into multiple continuous and non-overlapping time intervals, each with clear start and end boundaries. Data types are categorized based on data attributes such as access request details, access count statistics, access time nodes, access types, request processing durations, and request status, with each data type corresponding to an independent storage directory. During storage, data is first assigned to the corresponding time period storage module according to its time interval, and then stored in the corresponding storage directory according to data type within each time period storage module, achieving dual-classification storage. To facilitate subsequent fast querying and retrieval, an index is created for the stored data. The index information includes the core identifier of the data, its time period, data type, and storage path, allowing direct location of the target data's storage location. Simultaneously, the association information of each data entry is marked, including the correspondence between this data and other related data, and the associated scenarios in which the data was generated, making the logical relationships between data clear and traceable.

[0031] S1.4. Perform integrity and consistency checks on the stored data, correct any problems found, and then synchronize the data to subsequent processing stages: Integrity checks are performed by verifying that each data entry contains all the pre-defined necessary fields. This involves confirming that key fields such as access request details, access count statistics, and access time points are not missing, ensuring no data omissions at the field level. Consistency checks primarily verify the logical relationships between data items corresponding to the same access request, including the order of access initiation time and processing start time, the matching degree between processing duration calculation results and start and end times, and the correspondence between request status and processing results, ensuring no internal logical conflicts within the data. If data omissions or logical conflicts are found during the checks, the original source of the data is traced to find the cause of the problem. The data is corrected based on the original access records, supplementing missing key information and adjusting logically conflicting data content to restore data integrity and consistency. After data correction, a data synchronization mechanism is initiated to synchronize the processed, complete, and consistent data to the subsequent flame graph generation stage. The synchronization time, status, and results are recorded during the synchronization process to ensure timely and accurate data transmission to the next stage. If synchronization is interrupted, a recovery mechanism is activated to re-initiate the synchronization request, ensuring the continuity of data synchronization.

[0032] During the implementation of step S1, client access-related data is collected periodically. The collection frequency is flexibly adjusted according to actual changes in the access scenario. When access volume fluctuates significantly, the collection frequency is adjusted accordingly to ensure the comprehensiveness and timeliness of data collection. During the collection process, the generation time and source identifier of each piece of data are recorded in detail. The generation time and source identifier are stored together with the access-related data as inherent attributes of the data, which facilitates subsequent tracing of the data's generation background and source. Data transmission adopts a combination of real-time transmission and cache backup. After the access data is generated, it is immediately transmitted to the data processing node through a designated transmission channel, and cache backup is performed on the local storage medium to prevent data loss due to network interruption, equipment failure, or other reasons during transmission. During transmission, the data is encrypted using a preset encryption algorithm to ensure that the data is not tampered with or illegally obtained during transmission. If the collection is interrupted, a dedicated recovery process is initiated after the interruption is restored to collect the access data that was not collected during the interruption. After the supplementary collection is completed, the data integrity is verified to ensure that no access data during the interruption is missed, thus ensuring the continuity and integrity of the overall data collection.

[0033] S2. Construct a flame graph and identify hotspot functions: S2.1. Perform multi-dimensional analysis on the categorized data, analyzing data distribution, peak access times, function call correlations, and trends: Data distribution analysis is conducted along two core dimensions: access type and time period. It statistically analyzes the distribution of different access types within each time period, clarifying the temporal distribution characteristics of various access types and identifying the peak periods for different access types. Access peak analysis identifies peak periods with relatively concentrated access and trough periods with lower access by statistically analyzing the total number of accesses within each time period, clarifying the fluctuation patterns of access volume. Function call correlation analysis constructs a function call graph by analyzing the correspondence between access requests and backend functions, clarifying the calling functions corresponding to each access request, as well as the call hierarchy and dependencies between functions, understanding the chain structure of function calls. Data trend analysis, based on multiple sets of historical access data, compares changes in access volume and function call frequency over different periods to predict future trends in access volume and function calls, providing a forward-looking reference for subsequent process configuration. Through multi-dimensional analysis, the key information contained in the data is comprehensively mined, laying the foundation for flame graph generation and hotspot function identification.

[0034] S2.2. Construct a flame graph according to preset rules. The horizontal axis of the flame graph represents the time dimension, and the vertical axis represents the function call dimension. The frequency of function calls is distinguished by color: The pre-defined chart generation rules comprise three core parts: data preprocessing standards, sampling specifications, and color coding rules. The data preprocessing standards clearly define the types of redundant information to be identified and removed. Redundant information includes duplicate function call records, invalid air usage records, and abnormal call records caused by system failures. These redundant information are identified and removed one by one according to the standards to reduce interference with flame chart generation. The sampling specifications determine the sampling interval and sampling point selection logic. The sampling interval is set based on the data volume and analysis accuracy requirements to ensure that the sampled data accurately reflects the overall access situation and function call characteristics. Sampling point selection uses a combination of random sampling and focused sampling. Based on overall random sampling, the sampling point density is increased for data corresponding to peak access periods and high-frequency function calls. The color coding rules clearly define the correspondence between function call frequency and color. Different color gradients correspond to call frequencies from low to high, allowing for intuitive differentiation of function call frequency through color depth.

[0035] The horizontal axis of the flame chart represents the time dimension. This time dimension can be divided using either equal time periods or dynamic time periods. Equal time periods divide the overall time axis into multiple equal time units of fixed length. Dynamic time periods adaptively adjust the length of the time units based on changes in traffic volume; peak periods with higher traffic have shorter time units, while off-peak periods have longer time units, ensuring accurate representation of function call details across different time periods. The vertical axis represents the function call dimension, displayed hierarchically according to the function call stack, arranged vertically from the top-level calling function to the bottom-level called function. The height of the vertical axis for each function is positively correlated with its call frequency; the higher the call frequency, the higher the vertical axis. Each function is also labeled with a unique identifier and name next to the vertical axis for easy identification. After the flame chart is generated, the chart data is compressed using a preset compression format to reduce data storage space while preserving the chart's complete parsing capabilities. The compressed flame chart is linked to the original data and stored together, facilitating subsequent chart reconstruction using parsing tools and tracing the data source from which the chart was generated.

[0036] In some embodiments, the division of the time dimension can be achieved by combining a fixed-duration equal division with a dynamic adaptive division. That is, a longer fixed-duration division is used for low-access periods, while a shorter dynamic-duration division is automatically used for high-access periods, in order to balance data statistics efficiency and detailed presentation. The color coding rules can add a function processing load dimension, taking into account both call frequency and processing load, and setting a color gradient according to the comprehensive result, so that the flame graph can simultaneously reflect the frequency of function calls and resource consumption.

[0037] S2.3. Set a threshold, identify frequently accessed functions based on the threshold, and determine the range of hotspot functions by combining the function's impact on access processing: The threshold setting includes two key parameters: call frequency threshold and duration threshold. The call frequency threshold is determined comprehensively based on factors such as the statistical results of historical access data and the upper limit of system processing capacity, reflecting the standard of how frequently a function is called. The duration threshold specifies the minimum time length for a function to continuously reach the call frequency threshold, ensuring that the identified high-frequency functions have stable high-frequency characteristics, rather than temporary high-frequency calls caused by short-term fluctuations. During the identification process, the call frequency of each function is statistically analyzed in real time. When the call frequency of a function exceeds the set call frequency threshold in multiple consecutive time granularities, and the duration reaches the duration threshold, the function is initially identified as a function corresponding to high-frequency access. Based on this, the scope of hot-spot functions is further determined by combining the function's impact on access processing. Factors such as the proportion of access requests processed by the function to the total number of access requests, the proportion of function processing time to the overall access processing time, and the impact of function call failures on the overall access processing are considered. High-frequency functions that have a significant impact on the access processing flow are included in the scope of hot-spot functions to avoid omitting key functions, while high-frequency call functions with minimal impact on the overall access processing are excluded, ensuring the accuracy of the scope of hot-spot functions.

[0038] S2.4. Mark the identifier, name, call path, and other information of hot functions, sort the hot functions according to call frequency and impact, and extract the core features of hot functions: Identified hotspot functions are comprehensively labeled, with labeling information including the function's unique identifier, function name, call path, call frequency statistics, associated access request type, processed resource type, and corresponding position information in the flame graph. This labeling information is associated with the original data of the hotspot functions, forming a complete set of hotspot function information for easy subsequent querying, analysis, and invocation. Hotspot functions are then sorted according to call frequency and impact. The sorting process begins with call frequency as the primary criterion, placing functions with higher call frequencies at the top. Then, impact is used as a secondary criterion, further sorting functions with similar or identical call frequencies, ultimately forming an ordered list of hotspot functions. A list is created to prioritize different hot-spot functions. The core features of these functions are extracted, including runtime, resource consumption, call dependencies, data volume processed, and interaction frequency with other functions. Resource consumption encompasses key metrics such as memory usage and CPU utilization. Call dependencies identify upstream and downstream functions called by the function. Data volume processed indicates the scale of data processed in each function call. Interaction frequency reflects the frequency of collaboration between the function and other related functions. These extracted core features are then structured and stored to form a standardized hot-spot function feature dataset, providing data support for the subsequent generation of a mapping table.

[0039] S3. Setup Time Period - Process Configuration Correspondence Table: S3.1. Divide the time periods according to preset standards, and statistically analyze the frequency and variation characteristics of hotspot functions of different ranking levels within each time period: The pre-defined time-segmentation criteria clearly define the basis, duration range, and boundary nodes for time-segmentation. The criteria are based primarily on historical patterns of visitor traffic, combined with fluctuations in the call frequency of hot-spot functions, ensuring that the segmented time periods accurately reflect different access scenarios. The entire day is divided into multiple continuous, non-overlapping time-segment intervals according to this standard, each with a clearly defined start and end time. Hot-spot functions within each time-segment are statistically analyzed. Based on a pre-determined ranking, the total frequency, average frequency, and peak frequency of high, medium, and low-priority hot-spot functions within that time period are calculated. The total frequency is the total number of times a hot-spot function is called within that time period; the average frequency is the ratio of the total frequency to the time period duration; and the peak frequency is the highest call frequency per unit time within that time period. Simultaneously, the changing characteristics of hot-spot functions at each ranking level within the time period are recorded, including the time distribution of the rising, falling, and stable phases of call frequency, as well as the mutual influence relationships between the call frequencies of hot-spot functions of different priorities, providing accurate time-segment data support for subsequent process configuration.

[0040] S3.2. Based on the frequency of occurrence, core characteristics, and processing load of hotspot functions, determine the range of the number of Nginx worker processes required for each time period: The processing load is calculated by multiplying the call duration weighted value of a function by its call frequency. The call duration weighted value is determined based on the ranking of hot functions; different ranking levels assign different weight coefficients to hot functions, with higher priority functions receiving larger weight coefficients. This ensures that the calculated processing load accurately reflects the system resource consumption requirements of high-priority functions. The call frequency is the number of times a hot function is called per unit time, calculated by the total number of calls within a statistical period and the period duration. Multiplying the call duration weighted value by the call frequency yields the processing load for each hot function. The processing loads of all hot functions within the same period are then summed to obtain the total processing load for that period. The total processing load is then categorized into three levels: low load, medium load, and high load, with different Nginx instances corresponding to each level. Worker process configuration ranges are defined as follows: low load level corresponds to fewer processes, medium load level to a medium number of processes, and high load level to a larger number of processes. The load level threshold is set comprehensively based on the overall system resource volume and access processing efficiency requirements. When determining the process configuration, process execution records of the same or similar load level periods in historical access data are referenced. The processing efficiency and resource consumption corresponding to different numbers of processes in historical periods are analyzed. Combined with the current system resource limit, the initially determined range of process numbers is revised to avoid excessive process numbers leading to system resource exhaustion or insufficient process numbers failing to meet processing demands. After the process configuration is determined, simulated access scenarios are used for testing. This simulates possible fluctuations in access volume and changes in hot function calls during the period, and observes the request processing response speed, success rate, and other indicators under different numbers of processes to verify the rationality and feasibility of the process configuration. After the test is passed, the range of process numbers is included in the configuration content of the corresponding relationship table.

[0041] In some embodiments, the calculation of processing load can introduce the resource occupancy coefficient of the function as a supplementary parameter. The resource occupancy coefficient is calculated by weighted average of memory usage and CPU utilization. Together with the call duration weighting value and call frequency, it constitutes the calculation factor of processing load, making the load assessment more comprehensive. The process configuration range can be set with a dynamic floating range. According to the fluctuation of real-time access volume and hot function calls, the number of processes can be flexibly adjusted within the range to improve the adaptability of process configuration.

[0042] S3.3. Construct a table mapping time periods to Nginx worker processes in chronological order, clearly defining the key fields in the table and the corresponding process configurations for each time period: The structure of the correspondence table includes several key fields, specifically: a unique identifier field, a time period start time field, a time period end time field, an Nginx worker process count field, a configuration activation condition field, an update time field, an activation status field, and a remarks field. The unique identifier field assigns a unique identification code to each time period configuration for easy querying and management. The time period start time and end time fields clearly define the time period interval corresponding to each configuration. The Nginx worker process count field records the specific number or range of processes corresponding to that time period. The configuration activation condition field specifies the activation conditions for that process configuration, including access volume thresholds, hotspot function call frequency thresholds, etc. The update time field records the last update time of the configuration. The activation status field indicates whether the configuration is currently available. The remarks field records special instructions for the configuration, the basis for adjustments, and other supplementary information. During the construction process, the process configurations corresponding to each time period are entered into the table sequentially according to the start time of the time period, ensuring that the data in the table is arranged chronologically, clearly organized, with a clear and unique number of processes corresponding to each time period, matching the configuration activation conditions with the number of processes, and providing detailed remarks for easy subsequent querying, understanding, and use.

[0043] S3.4. Check the rationality of the time period division, the logic of the process configuration, and the accuracy of the data in the corresponding relationship table. After adjusting the table, mark the version and store it: The time period segmentation rationality check mainly verifies whether the time period intervals are continuous and non-overlapping, whether the start and end times meet the preset segmentation standards, whether they accurately cover the entire day's time range, and whether they reflect different access characteristics. The process configuration logic check focuses on analyzing whether the number of processes in each time period matches the processing load, access volume, and hot function call patterns of that period; whether the number of processes in high-load periods is higher than in low-load periods; whether changes in the number of processes are consistent with load changes; whether the configuration activation conditions are reasonable; and whether they accurately trigger the corresponding process configurations. The data accuracy check verifies the accuracy of information in each key field of the table, whether unique identifiers are duplicated, whether the time field is formatted correctly, and the number of processes. Check whether the quantity is within a reasonable range and whether the update time and effective status are accurate. If problems such as discontinuous time period division, mismatch between process configuration and load, or data entry errors are found during the inspection, adjust the table based on the previous analysis data and statistical results, correct the time period boundaries, adjust the number of processes, and correct erroneous data to ensure the rationality, logic, and accuracy of the table. After the table adjustment is completed, version marking is performed. The marking content includes the version number, adjustment time, and a summary of the adjustment content to facilitate the differentiation of configuration tables from different periods and to trace the configuration change history. The marked corresponding relationship table is stored in the designated storage location, and a query index for the table is created. The index contains key information such as version number and time period range to facilitate subsequent fast querying, calling, and updating maintenance.

[0044] S4. Match time period configuration and dynamically adjust the number of processes: S4.1. Receive the corresponding relationship table, check the data integrity and format correctness of the table, and store the table to the specified path after the check is passed: The correspondence table is received through a pre-defined transmission channel. During the reception process, the table's data integrity and format correctness are double-checked. Data integrity verification checks for missing key fields, including unique identifiers, time period start and end times, process counts, and activation conditions, ensuring no critical information is omitted. It also checks for blank rows and invalid data rows. Format correctness verification checks whether the data format of each field conforms to pre-defined standards, whether the time field uses the specified time format, whether the process count field uses a valid numerical format, and whether the activation status field uses the pre-defined status identifier, ensuring consistent and standardized data formats. If missing fields or format errors are found during verification, error information is sent to the table's generator, specifying the problem type and location, and requesting a retransmission of the corrected correspondence table. If verification passes, the correspondence table is stored in a pre-defined path with stable storage performance and easy access. During storage, information such as storage time, storage path, and table version number is recorded to create a storage log for future tracking of the table's storage status. Access permissions are also set to ensure table storage security.

[0045] S4.2. Obtain the current system time, compare the current time with the time period information in the table, and determine the current time period: The system obtains the current system time through its built-in time acquisition module, providing complete time information including year, month, day, hour, minute, and second to ensure accuracy. The current time is then compared one by one with the start and end times of each time period in the corresponding relationship table, following the chronological order of the time periods. The system determines if the current time falls within the start and end time of a particular time period. If the current time falls within a time period's range, that time period is directly identified as the current time period. If the current time is at the junction of two time periods (i.e., the end time of the previous period or the start time of the next period), the time period is determined according to preset rules, prioritizing the next time period to ensure timely process configuration switching to adapt to subsequent access scenarios. If no corresponding time period is found for the current time, an exception handling mechanism is activated, using the default process configuration scheme and recording the exception details, including the current time and exception type, for later troubleshooting.

[0046] In some embodiments, time period comparison can be performed by combining time interval matching and fuzzy matching. For the current time near the boundary of a time period, precise interval matching is performed first. If no match is found, fuzzy matching is performed based on the similarity of access characteristics between the preceding and following time periods to determine the process configuration corresponding to the most suitable time period. At the same time, a time period pre-matching mechanism can be set to preload the process configuration of the next time period in advance within a preset time before the current time period ends, so as to ensure that the process configuration can be seamlessly connected when the time period is switched.

[0047] S4.3. Find the standard and dynamic adjustment rules for the number of Nginx worker processes corresponding to the current time period: Based on the determined current time period, search for the corresponding record in the relationship table. Quickly locate the target record using key information such as unique identifier and time period start time. Extract the Nginx worker process count standard for the time period from the target record. The process count standard may be a fixed value or a range. If it is a range, extract both the upper and lower limits of the range. Extract the dynamic adjustment rules for the time period. The dynamic adjustment rules specify the trigger conditions and adjustment range for the process count. The adjustment trigger conditions include thresholds for real-time changes in access volume, fluctuation thresholds for hot function call frequency, and process resource utilization thresholds. When a certain trigger condition is met, the process count adjustment is initiated. The adjustment range specifies the increase or decrease in the process count for each adjustment to ensure a smooth adjustment process and avoid large fluctuations in the process count. Associate and store the extracted process count standard with the dynamic adjustment rules, recording the extraction time and current time period information for quick retrieval during subsequent process adjustments.

[0048] S4.4. Query the number and status of currently running Nginx worker processes, terminate idle processes exceeding the configured number, start new processes below the configured number, and the new processes complete configuration loading and reverse proxy service connection: The process management module queries the number of currently running Nginx worker processes, counts the total number of active processes, and obtains the running status of each process, including running, idle, and abnormal states, with a focus on identifying idle processes. The total number of currently running processes is compared with the identified process count standard. If the current number of processes exceeds the configured limit, the excess idle processes are terminated in a preset order. The termination order is sorted by idle duration, prioritizing the termination of processes with the longest idle duration. Simultaneously, considering process resource usage, idle processes with lower resource usage are terminated first, ensuring that processes with stronger resource utilization can handle access requests. Before terminating a process, the running status is checked again to confirm that the process has no ongoing access requests, avoiding interruption or failure of request processing due to process termination. If the current number of processes is less than the configured limit, the remaining processes are started. The new processes execute a preset initialization process upon startup, loading Nginx. The configuration parameters required for the worker process include preset parameters such as connection timeout, request processing queue length, and resource usage limit, ensuring that the configuration of the new process is consistent with the system requirements. After the new process completes initialization, it actively establishes a connection with the reverse proxy service, sends a registration request to the reverse proxy service, submits information such as process identifier and running status, and waits to receive access requests assigned by the reverse proxy service after completing registration.

[0049] During process adjustment, a smooth switching approach is adopted to avoid the impact of sudden changes in the number of processes on access processing. After the new process starts and completes the connection with the reverse proxy service, the reverse proxy service gradually distributes new access requests to the new process, with the allocation ratio gradually increasing. At the same time, the request allocation to idle processes that exceed the configured number is gradually reduced, and no new access requests are allocated to them. After these processes have finished processing the access requests they are currently handling, they are terminated in sequence. During the adjustment process, the processing status of access requests is monitored in real time, and the response time, success rate, and process status changes are recorded. If delays or a decrease in the success rate are found in request processing, the process adjustment process is paused, the number of processes is restored to the configuration before the adjustment, the cause of the problem is investigated, and the adjustment process is restarted after the problem is resolved.

[0050] In some embodiments, the order of process termination can be improved by using the historical processing efficiency of the process as an auxiliary indicator. The historical processing efficiency is calculated by the average response time of the process in the past. Processes with longer idle time and lower historical processing efficiency are terminated first, so as to retain processes with better processing capabilities. The configuration parameters of the new process can be dynamically adjusted according to the access characteristics of the current time period, rather than using fixed preset parameters, so that the new process is more suitable for the current access processing needs.

[0051] S4.5. Monitor the running status and access request processing of the adjusted Nginx worker processes, and establish an exception handling process to deal with process exceptions: The adjusted Nginx worker process runtime status monitoring is achieved through real-time collection of process runtime data. Monitoring content includes process runtime status (running, idle, abnormal), resource usage (memory usage, CPU utilization), access request processing progress (number of received requests, number of processed requests, number of unprocessed requests), and processing results (number of successful processing, number of failed processing). Monitoring data is collected at preset time intervals, with the collection frequency adjusted according to access volume; the collection frequency is increased when access volume is high to ensure timely understanding of process runtime status. The collected monitoring data is recorded in real-time and formed into a monitoring log. The monitoring log includes monitoring time, process identifier, values ​​of various monitoring indicators, request processing details, etc. The log is stored in chronological order for easy subsequent querying and analysis. An exception handling process is established to handle... During process execution, abnormal situations may occur, including process unresponsiveness, excessive resource consumption, abnormal exit, and request processing failure rate exceeding a threshold. When an abnormality is detected, the system first identifies the abnormal type and the specific abnormal process, recording the time of occurrence, abnormal behavior, and relevant monitoring data. Then, the abnormal process is terminated, releasing the system resources it occupies to prevent the abnormality from spreading and affecting the normal operation of other processes. A new process is started to replace the abnormal process. The new process loads configuration parameters according to a preset initialization process, establishes a connection with the reverse proxy service, and restores the processing function of the abnormal process. Simultaneously, the abnormal record is stored along with the monitoring log. The abnormal record details the abnormal type, processing procedure, and processing result. This information is used for subsequent adjustments to the corresponding relationship table, providing a basis for optimizing process configuration.

[0052] In some embodiments, the monitoring process can introduce a process health assessment mechanism. The process health is calculated by comprehensively considering three dimensions: running status stability, resource usage stability, and request processing success rate. Each dimension is weighted and summed according to a preset weight to obtain the process health value. When the health value is lower than the set standard, even if no obvious abnormality occurs, the process replacement process is initiated to avoid potential risks in advance. An abnormality handling process can be supplemented with an abnormality cause analysis step. By analyzing data such as monitoring logs and process running records, the root cause of the abnormality can be found. If it is caused by unreasonable process configuration parameters, the feedback is sent to the corresponding relationship table adjustment stage to optimize the process configuration parameters for the relevant period.

[0053] This method, through systematic implementation, dynamically adjusts the number of Nginx worker processes, ensuring the process count matches the volume of Redfish access requests at different times. The data collection phase guarantees the integrity, consistency, and continuity of access-related data, providing a reliable data foundation for subsequent analysis and decision-making. The construction of flame graphs and the identification of hotspot functions accurately pinpoint key functions affecting access processing, enabling process configuration to be specifically matched to core processing needs. The establishment of a time-to-process configuration mapping table provides a clear basis and standard for adjusting the number of processes. Smooth switching and exception handling during process adjustment ensure the stability and continuity of access request processing. This series of processes effectively reduces system resource waste caused by an excessive number of processes during idle periods, while avoiding access request processing delays due to insufficient processes during peak periods, thus improving the processing efficiency of Redfish access requests. The entire implementation process requires no manual intervention, achieving automated operation through preset rules and mechanisms, reducing operational complexity. The exception handling mechanism and data traceability function enhance the reliability and maintainability of the method, ensuring its long-term stable operation.

[0054] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for optimizing BMC Redfish access efficiency, characterized in that, Includes the following steps: S1. Collect client access-related data, including access request details, access quantity, access time, access type, processing time, and request status, and perform preliminary data classification; S2. Generate a flame graph based on the collected and categorized data, preprocess the data to remove redundant interference, present the function call situation through the flame graph, and determine the hot functions and call patterns corresponding to high-frequency access. S3. Based on the calling patterns of hot functions and the access characteristics of different time periods, generate a table showing the correspondence between time periods and Nginx worker processes, and clarify the time period range, process configuration standards, and effective conditions; S4. Based on the corresponding relationship table, identify the current time period, match the corresponding process configuration, adjust the number of Nginx worker processes, and adapt to the Redfish access request volume.

2. The method of claim 1, wherein, Step S1 includes the following sub-steps: S1.

1. Collect the client's access request content, initiation order, access count statistics, access time nodes, access types, request processing time, and request status; S1.

2. Filter and remove data with missing key information, duplicates, and incorrect formats, and unify the format of the remaining data; S1.

3. Store the processed data according to time period and data type, create an index and mark the storage location and related information; S1.

4. Perform integrity and consistency checks on the stored data, correct any problems found, and then synchronize the data to subsequent processing steps.

3. The method of claim 1, wherein, Step S2 includes the following sub-steps: S2.

1. Perform multi-dimensional analysis on the categorized data, analyzing data distribution, access peaks, function call correlations, and trends; S2.

2. Construct a flame graph according to preset rules. The horizontal axis of the flame graph represents the time dimension, and the vertical axis represents the function call dimension. The frequency of function calls is distinguished by color. S2.

3. Set a threshold, identify the functions corresponding to high-frequency access based on the threshold, and determine the range of hotspot functions by combining the function's impact on access processing; S2.

4. Mark the identifier, name, and call path information of hot functions, sort the hot functions according to call frequency and impact, and extract the core features of hot functions.

4. The method of claim 1, wherein, Step S3 includes the following sub-steps: S3.

1. Divide the time period according to the preset standard, and count the frequency and change characteristics of hotspot functions of different ranking levels in each time period; S3.

2. Based on the frequency of occurrence, core characteristics, and processing load of hot functions, determine the range of the number of Nginx worker processes required for each time period; S3.

3. Construct a table mapping time periods to Nginx worker processes in chronological order, and clarify the key fields in the table and the process configuration corresponding to each time period; S3.

4. Check the rationality of the time period division, the logic of the process configuration, and the accuracy of the data in the corresponding relationship table. After adjusting the table, mark the version and store it.

5. The method of claim 1, wherein, Step S4 includes the following sub-steps: S4.

1. Receive the corresponding relationship table, check the data integrity and format correctness of the table, and store the table to the specified path after the check is passed; S4.

2. Obtain the current system time, compare the current time with the time period information in the table, and determine the current time period; S4.

3. Find the standard number of Nginx worker processes and the dynamic adjustment rules for the current time period; S4.

4. Query the number and status of currently running Nginx worker processes, terminate idle processes that exceed the configured number, start new processes that are less than the configured number, and the new processes complete the configuration loading and reverse proxy service connection; S4.

5. Monitor the running status and access request processing of the adjusted Nginx worker processes, and establish an exception handling process to deal with process exceptions.

6. The method of claim 1, wherein, In step S1, client access-related data is acquired through periodic collection. The collection frequency is adjusted according to changes in the access scenario. The data generation time and source identifier are recorded and stored along with the access-related data. Data is transmitted using a combination of real-time transmission and cache backup. Data is encrypted during transmission. If collection is interrupted, a recovery process is initiated to collect the data from the interrupted period.

7. The method of claim 3, wherein, In step S2.2, the preset chart generation rules include data preprocessing standards, sampling specifications, and color coding rules. The data preprocessing standards clarify the judgment type and removal method of redundant information. The sampling specifications determine the sampling interval and sampling point selection logic. The time dimension adopts equal time period division or dynamic time period division. The vertical axis is displayed according to the function call stack level and labeled with function identifiers and names. After the flame chart is generated, it is compressed. The compressed flame chart is stored in association with the original data.

8. The method of claim 4, wherein, In step S3.2, the processing load is calculated by weighting the function call duration and the call frequency. Hot functions of different sorting levels correspond to different weights. The processing load is divided into three levels: low, medium and high. Different levels correspond to different Nginx worker process configuration ranges. When determining the process configuration, the process running records in the historical access data are referenced. The process configuration is adjusted in combination with the total system resources. After testing the feasibility of the process configuration through simulated access scenarios, the configuration is included in the corresponding relationship table.

9. The method of claim 5, wherein, In step S4.4, idle processes exceeding the configured number are sorted by idle duration, and processes are terminated sequentially according to the sorting result. Before termination, it is checked whether there are any unfinished access requests in the process. When a new process starts, it loads the configuration parameters required by the Nginx worker process, establishes a connection with the reverse proxy service after initialization, and the process adjustment adopts a smooth switching method. After the new process is ready, access requests are gradually allocated. Processes exceeding the configured number are terminated after processing the current request.

10. The method of claim 5, wherein, In step S4.5, the monitoring content includes process running status, resource usage, access request processing progress and results, and records the monitoring data to form a monitoring log. The anomaly handling process includes identifying the anomaly type, terminating the abnormal process, and starting a new process to replace it. At the same time, the anomaly occurrence time, anomaly type and abnormal process identifier are recorded. The anomaly record is stored together with the monitoring log for reference in subsequent adjustments to the corresponding relationship table.

Images