A pressure testing method, device, medium, and product

Abstract

This invention discloses a stress testing method, device, medium, and product. It relates to the field of computer technology and is applicable to the fintech sector. The method includes: loading a stress test scenario configuration file and parsing the configuration file based on a configuration engine, converting the parsed configuration items into a unified memory object; the stress is the message queue pressure between the producer and consumer ends; based on the unified memory object, data points are embedded at both the producer and consumer ends to collect real-time indicator data; a rate adjustment instruction is generated based on the real-time indicator data; an optimized request object is formed based on the rate adjustment instruction, and the execution result is determined based on the optimized request. Through the technical solution of this invention, comprehensive testing of products supporting Kafka commands can be achieved, observing changes in key indicators during stress testing, and accurately reflecting the true performance of the software development kit (SDK) call chain.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology and are applicable to the field of financial technology, particularly to a stress testing method, device, medium, and product. Background Technology

[0002] Enterprises face significant testing challenges when deploying products that support Kafka commands, primarily due to incomplete feature coverage and fragmented tools. Current mainstream testing tools, such as Tool 1, lack real-time monitoring capabilities, failing to observe changes in key metrics during load testing, resulting in test results lacking process data support. While Tool 2 possesses basic stress testing functionality, its method of simulating protocol layer message requests differs fundamentally from real-world business scenarios—actual business operations are performed through the Software Development Kit (SDK). This disconnect between the testing method and the SSD call chain causes a 20%-30% deviation in the number of transactions per second measurement. More seriously, existing tools generally lack dynamic rate limiting mechanisms, failing to automatically adjust when test traffic exceeds system capacity. This affects the stability of the proxy node cluster and makes it difficult to simulate the traffic fluctuations characteristic of real-world business scenarios. These deficiencies mean that traditional tools, when validating Kafka products, cannot accurately reflect the true performance of the SSD call chain, nor can they effectively assess the system's stability under sudden traffic surges. Summary of the Invention

[0003] This invention provides a stress testing method, device, medium, and product to enable comprehensive testing of products supporting Kafka commands, observe changes in key indicators during stress testing, accurately reflect the true performance of the software development kit call chain, and effectively evaluate the system's stability under burst traffic.

[0004] According to one aspect of the present invention, a stress testing method is provided, comprising: Load the stress test scenario configuration file and parse the configuration file based on the configuration engine, then convert the parsed configuration items into a unified memory object; the stress refers to the message queue pressure between the producer and consumer. Based on the unified memory object, data points are embedded on both the producer and consumer sides to collect real-time indicator data from both sides. A rate adjustment instruction is generated based on the real-time indicator data; An optimized request object is formed based on the rate adjustment instruction, and the execution result is determined based on the optimized request.

[0005] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the stress testing method according to any embodiment of the present invention.

[0006] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the stress testing method according to any embodiment of the present invention.

[0007] According to another aspect of the present invention, embodiments of the present invention also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the stress testing method described in any embodiment of the present invention.

[0008] This invention loads a stress test scenario configuration file and parses it using a configuration engine, converting the parsed configuration items into a unified memory object. The stress refers to the message queue pressure between the producer and consumer. Based on the unified memory object, monitoring points are placed on both the producer and consumer sides to collect real-time metric data. Rate adjustment instructions are generated based on the real-time metric data. An optimized request object is formed based on the rate adjustment instructions, and the execution result is determined based on the optimized request. This invention enables comprehensive testing of products supporting Kafka commands, allowing observation of key metric changes during stress testing, accurately reflecting the true performance of the software development kit (SDK) call chain, and effectively evaluating the system's stability under sudden traffic surges.

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

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart of a pressure testing method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a pressure testing device according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device that implements the pressure testing method of this invention. Detailed Implementation

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

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

[0014] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0015] Example 1 Existing stress testing tools suffer from three core flaws that severely impact the effectiveness of enterprise-level Kafka testing. First, fragmented functionality prevents the construction of complete test scenarios. For example, Tool 1 lacks monitoring capabilities, and Tool 2 only supports message-level testing, failing to cover the entire software development kit (SDK) chain. Second, mismatch with the SSD call chain causes data distortion. Testing tools do not use the SSD interfaces actually used in business applications, resulting in a 15%-20% deviation in measured transactions per second and latency data deviating from the true value by more than 30%. Third, the lack of dynamic rate limiting mechanisms makes stability testing unreliable. Under sudden traffic surges, traditional tools, lacking rate control, exhibit significantly different test results compared to production environment performance. Real-world testing shows that when the proxy node load reaches 80%, the unrate-limited tool continues to send requests, while the actual business system triggers degradation protection.

[0016] This invention proposes a message queue stress testing system, which adopts a modular design and consists of five core modules: configuration center, monitoring and data collection, dynamic rate limiting, extension and adaptation, and performance optimization. These modules are used to execute the stress testing method described in this embodiment.

[0017] Figure 1 This is a flowchart of a stress testing method according to an embodiment of the present invention. This embodiment is applicable to message queue stress testing. The method can be executed by the stress testing device according to the present invention, which can be implemented in software and / or hardware, such as... Figure 1 As shown, the method specifically includes the following steps: S101: Load the stress test scenario configuration file and parse the configuration file based on the configuration engine, then convert the parsed configuration items into a unified memory object.

[0018] The pressure refers to the message queue pressure between the producer and consumer sides.

[0019] In this embodiment, the message queue stress test measures three core metrics: throughput, latency, and backlog on both the producer and consumer sides, plus auxiliary dimensions such as error rate, CPU / memory, and network.

[0020] In the specific implementation, configuration items can include thread group configuration and message body template. The thread group configuration supports dynamically adjusting the ratio of producer and consumer threads, and the message body template allows embedding variables such as timestamps and random numbers.

[0021] It should be noted that the unified memory object can be understood as converting the configuration items parsed from the configuration center into a data shape (data structure) in memory at once and storing it in memory. The entire process only reads this one copy, ensuring that hot reloading takes effect in seconds, each module reads without locks, and zero-copy transfer.

[0022] Specifically, the configuration center uses dual configuration engines to parse the same test scenario configuration file in parallel, and automatically selects the corresponding parsing path based on the file extension, converting the parsed thread group parameters, message body templates and topic routing strategies into a unified memory object.

[0023] In practice, after being converted into a unified memory object, file system modification events are registered for the configuration file. When the event is triggered, debouncing is performed, and configuration hot reload is completed while keeping the current test task running, so as to achieve T+0 level configuration activation.

[0024] S102. Based on a unified memory object, embed tracking points on both the producer and consumer sides to collect real-time indicator data from both sides.

[0025] The real-time metric data can be collected from key metric collection points designed on both the producer and consumer sides. For example, the real-time metric data for the producer side includes: message sending rate, network latency, serialization time, and sending buffer queue depth; the real-time metric data for the consumer side includes: message consumption rate, processing latency, deserialization time, and current consumption backlog.

[0026] Specifically, based on the unified memory object obtained in the above steps, the monitoring and collection module collects real-time indicator data by embedding points on both the producer and consumer sides. The real-time indicator data includes at least message sending rate, network latency, serialization time, sending buffer queue depth, message consumption rate, processing latency, deserialization time, and consumption backlog.

[0027] S103. Generate rate adjustment instructions based on real-time indicator data.

[0028] Among them, the rate adjustment command can be used to adjust the message queue sending and receiving rate between the producer and consumer.

[0029] Specifically, the dynamic rate limiting module reads the real-time metric data pushed in the above steps and generates rate adjustment instructions based on the improved dual-mode token bucket algorithm. The dual modes include burst traffic buffering mode and smooth rate limiting mode. When the CPU utilization of the proxy node is detected to exceed the target threshold and / or the message backlog continues to increase, the module automatically switches from burst traffic buffering mode to smooth rate limiting mode.

[0030] S104. Generate an optimized request object based on the rate adjustment instruction, and determine the execution result based on the optimized request.

[0031] It should be noted that the optimized request object can be a single (or batch) network packet entity that has undergone layers of processing including rate limiting, batch processing, compression, and zero-copy. The execution result can be a response primitive returned by the proxy node, which typically includes: delay (send completion timestamp - entry timestamp), status code (0 = success, non-zero = error code), number of bytes (the number of bytes actually written to the network), and optional parameters (offset, delay time). This execution result will be immediately written back to the monitoring and acquisition module for use in the next round of rate limiting decisions.

[0032] Specifically, the extended adaptation module, through reflection and dynamic proxy technology, adjusts the core parameters of the thread pool and / or message batch size online based on the rate adjustment instructions generated in the above steps, forming an optimized request and sending it to the performance optimization module. The performance optimization module performs high-concurrency random number generation and zero-copy string processing on the optimized request passed in from the above steps, obtains the execution result, and sends the execution result back to the monitoring and acquisition module, forming a closed-loop data flow of metrics-rate limiting-optimization.

[0033] This invention loads a stress test scenario configuration file and parses it using a configuration engine, converting the parsed configuration items into a unified memory object. The stress refers to the message queue pressure between the producer and consumer. Based on the unified memory object, monitoring points are placed on both the producer and consumer sides to collect real-time metric data. Rate adjustment instructions are generated based on the real-time metric data. An optimized request object is formed based on the rate adjustment instructions, and the execution result is determined based on the optimized request. This invention enables comprehensive testing of products supporting Kafka commands, allowing observation of key metric changes during stress testing, accurately reflecting the true performance of the software development kit (SDK) call chain, and effectively evaluating the system's stability under sudden traffic surges.

[0034] Optionally, after collecting real-time indicator data from both producers and consumers, the following may also be included: Real-time indicator data is packaged with multidimensional labels to obtain aggregated data.

[0035] The multidimensional tags include at least the following dimensions: client role differentiation dimension, target topic name dimension, client instance identifier dimension, and partition number dimension.

[0036] It should be noted that the client role differentiation dimension is used to differentiate client roles, the target topic name dimension is used to indicate the target topic name, the client instance identifier dimension is used to represent the client instance identifier, and the partition number dimension is used to represent the partition number (-1 for the producer side). Aggregated data can be data obtained by packaging real-time metric data with multi-dimensional labels.

[0037] Specifically, real-time indicator data is packaged into aggregated data using four dimensions: client role differentiation, target topic name, client instance identifier, and partition number.

[0038] The technical solution of this invention packages the collected real-time indicator data into a multi-dimensional tag model and pushes it to the monitoring system for monitoring via batch processing and compression. The tag system is constructed using a multi-dimensional data model, key indicator collection is optimized using zero-copy technology, indicator data is directly pushed to the monitoring system through a client library, and batch processing and compression transmission can reduce network overhead.

[0039] Optionally, after packaging the real-time indicator data with multidimensional labels to obtain aggregated data, it also includes: The aggregated data is rendered in real time to display cluster load heatmaps, percentile latency trend charts, and message throughput matrix charts, completing the visualization loop of the stress testing process.

[0040] Among them, the cluster load heatmap is used to display the distribution of CPU, memory, and network input / output utilization of the agent nodes using color gradients; the percentile latency trend chart is used to present the changing trend of key quantiles using a multi-curve overlay method; and the message throughput matrix chart is used to display the production / consumption rate matching of topic partitions in a dynamic table format.

[0041] In the implementation process, the visualization solution provides out-of-the-box monitoring dashboard templates, enabling real-time observation and analysis of test data through pre-built visualization components. The core dashboard includes three key views: a cluster load heatmap that displays the distribution of CPU, memory, and network I / O usage for each agent node using color gradients, facilitating quick identification of performance bottleneck nodes; a percentile latency trend chart that uses a multi-curve overlay method to present the changing trends of each key quantile, supporting time range scaling and outlier marking; and a message throughput matrix that displays the production / consumption rate matching of each topic partition in a dynamic table format, with built-in red and green threshold warning indicators.

[0042] The technical solution of this invention provides a ready-to-use monitoring dashboard template by rendering aggregated data in real time, and realizes real-time observation and analysis of test data through pre-built visualization components.

[0043] Optional configuration items include: thread group parameters, message body template, and topic routing strategy.

[0044] Load the stress test scenario configuration file and parse it based on the configuration engine. Convert the parsed configuration items into a unified memory object, including: Load the first and second format stress test scenario configuration files.

[0045] It should be noted that the first format and the second format can specifically be two lightweight text formats.

[0046] Specifically, the configuration center, as the system entry point, is responsible for loading test scenario configuration files in the first and second formats. This embodiment does not specifically limit the first and second formats.

[0047] It uses a dual configuration engine to parse configuration files in parallel.

[0048] The dual configuration engine includes a first format corresponding parsing engine and a second format corresponding parsing engine.

[0049] Specifically, it adopts a dual configuration engine design with first and second formats to realize the parsing and conversion of configuration files and support real-time conversion between the two formats.

[0050] The parsing path is determined by the file extension of the configuration file, and the parsed thread group parameters, message body templates, and topic routing strategies are converted into a unified memory object.

[0051] Specifically, the parsing path is determined by the file extension of the configuration file, and the parsed configuration items, including thread group parameters, message body templates, and topic routing strategies, are converted into a unified memory object.

[0052] The technical solution of this invention adopts a dual configuration engine design with two formats to realize the parsing and conversion of configuration files, supports real-time mutual conversion between the two formats, supports synchronous / asynchronous dual mode, improves throughput by 40% in asynchronous mode, and supports dual-format nested structure, including variable placeholders and loop constructors.

[0053] Optionally, generate rate adjustment instructions based on real-time indicator data, including: When the CPU utilization of the agent node is detected to exceed the target threshold and / or the message backlog continues to increase within the target time, a rate adjustment instruction is generated: switching from burst traffic buffering mode to smooth rate limiting mode.

[0054] The target threshold can be a threshold set according to actual needs or experience. This embodiment does not specifically limit the target threshold and it can be adjusted as needed.

[0055] Specifically, the dynamic rate limiting module implements flow control based on the improved token bucket algorithm, and automatically triggers a rate reduction mechanism when the central processing unit of the proxy node exceeds the threshold.

[0056] In practice, the improved token bucket algorithm achieves flexible traffic control through a dual-mode switching mechanism. In burst traffic buffering mode, it allows for the short-term consumption of pre-stored token reserves (default capacity of 1000 tokens). When a sustained high load is detected, it automatically switches to a smooth rate-limiting mode. The dynamic token generation rate adjustment strategy is based on a sliding window algorithm, calculating the token generation rate for the next cycle every 5 seconds based on the actual request volume, with adjustments not exceeding ±20% of the current rate to prevent drastic fluctuations.

[0057] The technical solution of this invention, the improved token bucket algorithm, achieves flexible flow control through a dual-mode switching mechanism. The system maintains two independent token bucket instances to handle producer and consumer flow control respectively, ensuring thread-safe token operations.

[0058] Optionally, an optimized request object is formed based on the rate adjustment instruction, and the execution result is determined based on the optimized request, including: The target parameters of the thread pool are adjusted based on the rate adjustment instruction to form an optimized request object.

[0059] The target parameters for the thread pool may include, for example, the core parameters of the thread pool and / or the message batch size.

[0060] Specifically, the extended adaptation module uses reflection and dynamic proxy technology to adjust the core parameters of the thread pool and / or the message batch size online according to the rate adjustment instructions generated in the above steps, forming an optimized request and sending it to the performance optimization module.

[0061] The optimized request object is processed with high-concurrency random number generation and zero-copy string processing to obtain the execution result.

[0062] The execution results include: response time, status code, and number of bytes.

[0063] Specifically, the performance optimization module performs high-concurrency random number generation and zero-copy string processing on the optimized requests passed in from the above steps, obtains the execution results, and sends the execution results back to the monitoring and acquisition module, forming a closed-loop data flow of indicators-rate limiting-optimization.

[0064] The technical solution of this invention includes an extension adaptation module and a performance optimization module. The extension adaptation module provides pluggable extension capabilities through reflection and dynamic proxies, while the performance optimization module improves execution efficiency by employing thread-isolated random number generation and zero-copy string processing techniques.

[0065] Optionally, the real-time metrics for the producer side include: message sending rate, network latency, serialization time, and send buffer queue depth; the real-time metrics for the consumer side include: message consumption rate, processing latency, deserialization time, and current consumption backlog.

[0066] Among them, network latency can be the time difference from when a message enters the sending queue to when the acknowledgment is received from the broker node; serialization time can be the time to convert a message object into a byte array; processing latency can be the time difference from when a message is retrieved to when the message sequence number is committed; and the current consumption backlog can be the difference between the latest consumed message sequence number and the partition high watermark (the upper boundary of committed messages).

[0067] The technical solution of this invention can collect more than 20 producer / consumer indicators by simultaneously collecting key indicators from both the producer and consumer sides, including in-depth data such as network latency and serialization time, to achieve comprehensive data monitoring.

[0068] The technical solution of this invention provides a message queue stress testing method that supports Kafka commands. Using this method, products that support Kafka commands can be tested in all aspects, and it also performs well in terms of functional scalability.

[0069] Example 2 This embodiment will now describe in detail the message queue stress testing system involved in the above embodiments.

[0070] The system adopts a modular design, consisting of five core modules: configuration center, monitoring and data collection, dynamic rate limiting, extension and adaptation, and performance optimization. The configuration center, serving as the system entry point, is responsible for loading the test scenario configurations for both primary and secondary formats, including thread group parameters, message templates, and topic routing strategies. The monitoring and data collection module uses data tracking technology to capture real-time metrics such as message backlog and network latency on both the producer and consumer sides. The dynamic rate limiting module implements flow control based on an improved token bucket algorithm, automatically triggering a rate-down mechanism when the central processing unit of a proxy node exceeds a threshold. The extension and adaptation module provides pluggable extension capabilities through reflection and dynamic proxies. The performance optimization module uses thread-isolated random number generation and zero-copy string processing techniques to improve execution efficiency. All modules interact through standardized interfaces, forming a closed-loop data flow of "configuration loading → test execution → metric collection → dynamic adjustment → result output."

[0071] Specifically, the implementation details of each key module are as follows: 1. Configuration Center: Employs a dual-engine design with both primary and secondary configuration formats to parse and convert configuration files, supporting real-time conversion between the two formats. A hot-reload mechanism monitors configuration file change events and ensures existing test tasks continue running when configuration reload is triggered. Test scenario parameterization includes the following configurable items: thread group parameters, message body templates, and topic routing strategies.

[0072] The thread group configuration supports dynamically adjusting the ratio of producer and consumer threads, and the message body template allows embedding variables such as timestamps and random numbers. The topic routing strategy provides three distribution modes, with the hash strategy determining the target partition based on the hash value of the message key. All configuration changes take effect in real time via the Hypertext Transfer Protocol interface or file monitoring, without requiring a restart of the test process.

[0073] 2. Monitoring and data acquisition module: A. Tracking Strategy: In the tracking technology solution, the key metrics collected on the producer side include message sending rate, network latency (the time difference between a message entering the sending queue and receiving confirmation from the broker node), serialization time (the time to convert a message object into a byte array), and sending buffer queue depth. On the consumer side, the focus is on monitoring message consumption rate, processing latency (the time difference between retrieving a message and committing its sequence number), deserialization time, and the current backlog of consumed messages (the difference between the latest consumed message sequence number and the partition high-water mark).

[0074] The tag system is constructed using a multi-dimensional data model. The core tag dimensions include: client role differentiation dimension, target topic name dimension, client instance identifier dimension, and partition number dimension.

[0075] The sampling frequency adopts a dynamic adjustment mechanism. The basic sampling interval is 5 seconds. When any of the following conditions are detected, it will automatically switch to 1-second high-frequency sampling: the producer's sending buffer usage exceeds 70%, the consumer's message backlog continues to increase for 3 cycles, or the network latency value exceeds the configured threshold.

[0076] Key metric collection is optimized using zero-copy technology. A thread-local random number generator is used to generate tracking identifiers, avoiding thread contention. A string builder with a preset capacity of 256 bytes reduces memory allocation. Metric data is directly pushed to the monitoring system, and batch processing compression is used to reduce network overhead.

[0077] B. Visualization Solution: The visualization solution provides out-of-the-box monitoring dashboard templates, enabling real-time observation and analysis of test data through pre-built visualization components. The core dashboard includes three key views: a cluster load heatmap that displays the distribution of CPU, memory, and network I / O usage for each agent node using color gradients, facilitating quick identification of performance bottleneck nodes; a percentile latency trend chart that uses a multi-curve overlay method to present the changing trends of each key quantile, supporting time range scaling and outlier marking; and a message throughput matrix chart that displays the production / consumption rate matching of each topic partition in a dynamic table format, with built-in red and green threshold warning indicators.

[0078] Custom metric expansion is achieved by modifying the data source configuration. Users can add new expressions to the panel and use syntax to combine basic metrics to generate composite monitoring items. Expanded metrics must follow preset naming conventions. All custom panel configurations can be exported as fixed templates for easy sharing and reuse among teams.

[0079] 3. Dynamic rate limiting module: Optimized implementation of the token bucket algorithm The improved token bucket algorithm achieves flexible flow control through a dual-mode switching mechanism. In burst traffic buffering mode, it allows the consumption of pre-stored token reserves (default capacity of 1000 tokens) for a short period. When a sustained high load is detected, it automatically switches to a smooth rate-limiting mode. The dynamic token generation rate adjustment strategy is implemented based on a sliding window algorithm. Every 5 seconds, the actual request volume is counted and the token generation rate for the next cycle is calculated. The adjustment range does not exceed ±20% of the current rate to prevent drastic fluctuations. The thread sleep-wake mechanism uses condition variables for precise control. When tokens are insufficient, threads enter a waiting state with a 100-millisecond timeout. Once tokens are replenished, waiting threads are woken up in batches. The system maintains two independent token bucket instances to handle producer and consumer flow control respectively, ensuring thread-safe token operations.

[0080] 4. Extended Adaptive Architecture: Command Execution Abstraction Layer A generic execution method is implemented using reflection and dynamic proxy technology, constructing a bidirectional extension mechanism for client instance mapping and command object mapping. This design uses dynamic proxies to generate a unified interface for the command executor, and dynamically calls methods of specific implementation classes through reflection. This allows for expansion by simply registering new client instances and command objects when adding new protocol support.

[0081] The client instance mapping maintains the mapping relationship between client types and client instances, while the command object mapping stores the correspondence between command types and command executors. The execution flow is resolved through dual mapping: first, the specific instance is located based on the client type; then, the corresponding executor proxy object is obtained based on the command type; finally, the proxy object completes the reflection invocation. This two-way mapping mechanism decouples the execution logic from the specific implementation.

[0082] 5. Performance optimization strategies: A. High-concurrency random number generation: In high-concurrency scenarios, the performance of the random number generator directly impacts the overall throughput of stress testing tools. Benchmark tests comparing the performance of a random number generator and a thread-local random number generator at a query rate of 100,000 per second show that the thread-local random number generator achieves a throughput of 98,542 operations per millisecond, while the random number generator only manages 23,761 operations per millisecond, a performance difference of 315%. This difference stems from the thread-level seed isolation mechanism employed by the thread-local random number generator. Its internally maintained thread-local mapping table stores independent seed values ​​using the thread identifier as the key, completely eliminating the performance overhead caused by multi-threaded contention for the atomic random seed variable. The seed isolation storage principle is reflected in the fact that when each thread first calls the current instance's retrieval method, it generates an initial seed by mixing the thread identifier with the system nanosecond time using a hash algorithm. Subsequently, it updates the seed state in its respective thread-local space using a linear congruential formula, avoiding global lock contention.

[0083] B. Zero-copy string processing: The pre-allocated capacity optimization scheme for the string constructor effectively reduces the number of memory allocations during dynamic expansion by pre-allocating sufficient memory space. For a message size of 1 kilobyte, the default constructor results in 3 memory allocations, while the pre-allocated capacity reduces this to 1. For a 10 kilobyte message, the number of allocations is optimized from 7 to 2. For a 1 megabyte message, the number of allocations is significantly reduced from 15 to 3. This optimization significantly reduces memory fragmentation and garbage collection frequency per unit time, with particularly noticeable effects in stress testing scenarios that continuously generate a large number of messages.

[0084] To address high-frequency string manipulation scenarios, the solution introduces object pooling technology to manage string constructor instances. By reusing already created objects, frequent object creation and destruction operations are avoided. The object pool is implemented using a double-ended queue structure, with its maximum capacity dynamically adjusted based on the number of load testing threads. When a thread requests a string constructor instance, it prioritizes retrieving a free object from the pool; after use, the content is cleaned up and returned to the object pool. This technology reduces garbage collection pause time by approximately 40% per unit time, effectively ensuring stability during load testing.

[0085] As shown in Table 1, compared with traditional tools (such as Tool 1 and Tool 2), the technical solutions of the embodiments of the present invention have made progress in the following functional dimensions: Examples of typical test scenario combinations are as follows: Peak stress test: Asynchronous mode + dynamic key (32-byte random) + 3:7 read / write ratio + smooth rate limiting (50,000 records / second).

[0086] Stability verification: Synchronous mode + increment key + 1:1 read / write ratio + full collection of monitoring indicators - Anomaly recovery test: Asynchronous mode + hash key + 5:5 read / write ratio + burst rate limiting (peak 100,000 records / second).

[0087] The technical solution of this invention provides a message queue stress testing system that supports Kafka commands, which can perform comprehensive testing on products that support Kafka commands and also has good performance in terms of functional scalability.

[0088] Example 3 Figure 2 This is a schematic diagram of a stress testing device according to an embodiment of the present invention. This embodiment is applicable to message queue stress testing. The device can be implemented using software and / or hardware, and can be integrated into any device that provides stress testing functionality, such as… Figure 2 As shown, the pressure testing device specifically includes: a loading module 201, a data acquisition module 202, a generation module 203, and a determination module 204.

[0089] Among them, the loading module 201 is used to load the stress test scenario configuration file and parse the configuration file based on the configuration engine, and convert the parsed configuration items into a unified memory object; the stress is the message queue pressure between the producer and the consumer. The acquisition module 202 is used to collect real-time indicator data from the producer and consumer ends by embedding points on the producer end and the consumer end respectively based on the unified memory object. The generation module 203 is used to generate a rate adjustment instruction based on the real-time indicator data; The determination module 204 is used to form an optimized request object based on the rate adjustment instruction, and to determine the execution result based on the optimized request.

[0090] Optionally, the device further includes: The packaging unit is used to package the real-time indicator data with multi-dimensional labels to obtain aggregated data; the multi-dimensional labels include at least: client role differentiation dimension, target topic name dimension, client instance identifier dimension, and partition number dimension.

[0091] Optionally, the device further includes: The rendering unit is used to render the aggregated data in real time, displaying the cluster load heatmap, percentile latency trend map, and message throughput matrix map. The cluster load heatmap is used to display the distribution of CPU, memory, and network input / output usage of the proxy nodes using color gradients; the percentile latency trend chart is used to present the changing trend of key quantiles using a multi-curve overlay method; and the message throughput matrix chart is used to display the production / consumption rate matching of topic partitions in a dynamic table format.

[0092] Optionally, the configuration items include: thread group parameters, message body template, and topic routing strategy; The loading module 201 is specifically used for: Load the first and second format stress test scenario configuration files; The configuration file is parsed in parallel using a dual configuration engine; the dual configuration engine includes a first format-corresponding parsing engine and a second format-corresponding parsing engine. The parsing path is determined by the file extension of the configuration file, and the parsed thread group parameters, message body templates, and topic routing strategies are converted into a unified memory object.

[0093] Optionally, the generation module 203 is specifically used for: When the CPU utilization of the agent node is detected to exceed the target threshold and / or the message backlog continues to increase within the target time, a rate adjustment instruction is generated: switching from burst traffic buffering mode to smooth rate limiting mode.

[0094] Optionally, the determining module 204 is specifically used for: Based on the rate adjustment instruction, the target parameters of the thread pool are adjusted to form an optimized request object; The optimized request object is subjected to high-concurrency random number generation and zero-copy string processing to obtain the execution result; the execution result includes: response time, status code and number of bytes.

[0095] Optionally, the real-time metrics data corresponding to the producer side include: message sending rate, network latency, serialization time, and sending buffer queue depth; the real-time metrics data corresponding to the consumer side include: message consumption rate, processing latency, deserialization time, and current consumption backlog.

[0096] The above-mentioned products can perform the pressure testing method provided in any embodiment of the present invention, and have the corresponding functional modules and beneficial effects of performing the method.

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

[0098] like Figure 3 As shown, the electronic device 30 includes at least one processor 31 and a memory, such as a read-only memory 32 or a random access memory 33, communicatively connected to the at least one processor 31. The memory stores computer programs executable by the at least one processor. The processor 31 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 32 or loaded from storage unit 38 into the random access memory 33. The random access memory 33 can also store various programs and data required for the operation of the electronic device 30. The processor 31, read-only memory 32, and random access memory 33 are interconnected via a bus 34. An input / output interface 35 is also connected to the bus 34.

[0099] Multiple components in electronic device 30 are connected to input / output interface 35, including: input unit 36, such as keyboard, mouse, etc.; output unit 37, such as various types of monitors, speakers, etc.; storage unit 38, such as disk, optical disk, etc.; and communication unit 39, such as network card, modem, wireless transceiver, etc. Communication unit 39 allows electronic device 30 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0100] Processor 31 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 31 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 31 performs the various methods and processes described above, such as stress testing methods: Load the stress test scenario configuration file and parse the configuration file based on the configuration engine, then convert the parsed configuration items into a unified memory object; the stress refers to the message queue pressure between the producer and consumer. Based on the unified memory object, data points are embedded on both the producer and consumer sides to collect real-time indicator data from both sides. A rate adjustment instruction is generated based on the real-time indicator data; An optimized request object is formed based on the rate adjustment instruction, and the execution result is determined based on the optimized request.

[0101] In some embodiments, the stress testing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 38. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 30 via read-only memory 32 and / or communication unit 39. When the computer program is loaded into random access memory 33 and executed by processor 31, one or more steps of the stress testing method described above may be performed. Alternatively, in other embodiments, processor 31 may be configured to perform the stress testing method by any other suitable means (e.g., by means of firmware).

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

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

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

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

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

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

[0108] In one embodiment, the present invention further includes a computer program product, which includes a computer program that, when executed by a processor, implements the stress testing method of any embodiment of the present invention.

[0109] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

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

Claims

1. A method of pressure testing, characterized by, include: Load the stress test scenario configuration file and parse the configuration file based on the configuration engine, then convert the parsed configuration items into a unified memory object; The pressure refers to the message queue pressure between the producer and consumer ends. Based on the unified memory object, data points are embedded on both the producer and consumer sides to collect real-time indicator data from both sides. A rate adjustment instruction is generated based on the real-time indicator data; An optimized request object is formed based on the rate adjustment instruction, and the execution result is determined based on the optimized request.

2. The method of claim 1, wherein, After collecting real-time indicator data from the producer and consumer ends, the process also includes: The real-time indicator data is packaged with multi-dimensional labels to obtain aggregated data; the multi-dimensional labels include at least: client role differentiation dimension, target topic name dimension, client instance identifier dimension, and partition number dimension.

3. The method of claim 2, wherein, After packaging the real-time indicator data with multidimensional labels to obtain aggregated data, the process also includes: The aggregated data is rendered in real time to display a cluster load heatmap, a percentile latency trend chart, and a message throughput matrix chart. The cluster load heatmap is used to display the distribution of CPU, memory, and network input / output usage of the proxy nodes using color gradients; the percentile latency trend chart is used to present the changing trend of key quantiles using a multi-curve overlay method; and the message throughput matrix chart is used to display the production / consumption rate matching of topic partitions in a dynamic table format.

4. The method of claim 1, wherein, The configuration items include: thread group parameters, message body template, and topic routing strategy; Load the stress test scenario configuration file and parse the configuration file based on the configuration engine. Convert the parsed configuration items into a unified memory object, including: Load the first and second format stress test scenario configuration files; The configuration file is parsed in parallel using a dual configuration engine; the dual configuration engine includes a first format-corresponding parsing engine and a second format-corresponding parsing engine. The parsing path is determined by the file extension of the configuration file, and the parsed thread group parameters, message body templates, and topic routing strategies are converted into a unified memory object.

5. The method of claim 1, wherein, Generate rate adjustment instructions based on the real-time indicator data, including: When the CPU utilization of the agent node is detected to exceed the target threshold and / or the message backlog continues to increase within the target time, a rate adjustment instruction is generated: switching from burst traffic buffering mode to smooth rate limiting mode.

6. The method of claim 1, wherein, An optimized request object is generated based on the rate adjustment instruction, and the execution result is determined based on the optimized request, including: Based on the rate adjustment instruction, the target parameters of the thread pool are adjusted to form an optimized request object; The optimized request object is subjected to high-concurrency random number generation and zero-copy string processing to obtain the execution result; the execution result includes: response time, status code and number of bytes.

7. The method of claim 1, wherein, The real-time metrics data corresponding to the producer side include: message sending rate, network latency, serialization time, and sending buffer queue depth; the real-time metrics data corresponding to the consumer side include: message consumption rate, processing latency, deserialization time, and current consumption backlog.

8. An electronic device, comprising: The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the stress testing method according to any one of claims 1-7.

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

10. A computer program product comprising a computer program that, when executed by a processor, implements the stress testing method according to any one of claims 1-7.

Images