JMeter-based performance test data storage method, device, equipment and storage medium
By combining time-series and relational databases, the problems of low efficiency and high cost of performance test data storage are solved, efficient and automated data management and analysis are achieved, and multi-dimensional query and optimization are supported.
Patent Information
- Application Number
- CN202510948046.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-10
- Publication Date
- 2025-09-30
- Estimated Expiration
- 2045-07-10
AI Technical Summary
Existing performance test data storage solutions have problems such as large file size, non-intuitive data display, prone to crashes in concurrent scenarios, and difficulty in data association. They also fail to effectively combine interface and host performance indicators, resulting in low efficiency and high cost.
A combination of time-series database and relational database is used to generate performance test data through JMeter, write it into the time-series database in real time, associate it with the relational database, and transfer it to the relational database to achieve efficient data storage and flexible query.
It realizes the fully automatic association and recording of performance test data, reduces storage resource usage, improves data management efficiency and accuracy, facilitates data traceability and bottleneck location, and supports multi-dimensional analysis and optimization.
Smart Images

Figure CN120448465B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the fields of software development and performance testing, and in particular to a JMeter-based performance testing data storage method, apparatus, device, and storage medium. Background Art
[0002] With the current booming software industry, performance testing is becoming increasingly critical to ensuring stable and efficient system operation. Its importance is growing, and diverse performance testing methods are constantly emerging. In performance testing, data storage and monitoring solutions, as key components for comprehensive and accurate system performance assessment, have long been a research hotspot in the testing field.
[0003] Currently, mainstream performance test result storage solutions have many flaws. First, JMeter's native local file storage method, while leveraging features like the result tree and aggregate reports to store results as local files in .jtl format, is bulky and the data presentation is unintuitive, making it difficult to adapt to large-scale testing and long-term data analysis needs. Second, the JMeter+MySQL storage solution, in high-concurrency scenarios, can easily lead to connection pool exhaustion, lock waits, and even service downtime, with a large number of threads concurrently executing operations on MySQL in high-concurrency scenarios. This makes it unsuitable for large-scale testing. Third, the JMeter+InfluxDB storage solution, although data is stored in InfluxDB, its query statements are complex, making it difficult for testers to directly obtain performance indicator data such as interfaces and hosts, and it is also difficult to accurately associate corresponding performance test data after multiple tests.
[0004] Furthermore, existing performance tests also have limitations in data collection. Some tests focus solely on data such as interface response time and throughput, or simply collect metrics like host CPU and memory usage, without integrating and automatically storing interface and host performance metrics. In summary, during performance testing, technologies for acquiring and storing relevant data suffer from low efficiency and high labor costs, leaving significant room for improvement. More efficient and comprehensive performance test data management solutions are urgently needed to enhance the quality and efficiency of performance testing and better support system performance evaluation and optimization. Summary of the Invention
[0005] Based on this, it is necessary to provide a JMeter-based performance test data storage method, device, equipment and storage medium to address the above technical problems, so as to solve at least one problem existing in the above-mentioned prior art.
[0006] In a first aspect, a JMeter-based performance test data storage method is provided, the method comprising:
[0007] Configuring a database, wherein the database includes a time series database and a relational database;
[0008] Configure and run the JMeter performance test script to generate performance test data, and write the performance test data into the time series database;
[0009] Based on the start and end time of the JMeter performance test, the performance index data of the target test host is obtained, and the performance index data is written into the time series database;
[0010] Querying the corresponding performance test data and performance indicator data in the time series database, correlating the performance test data and the performance indicator data, and generating a correlation result;
[0011] The association result is transferred to the relational database.
[0012] In a possible implementation, obtaining performance indicator data of the target test host and writing the performance indicator data into the time series database includes:
[0013] Configuring multiple target monitoring components in the target test host to monitor performance indicator data of the target test host;
[0014] The monitored performance indicator data is obtained and written into the storage bucket corresponding to the time series database.
[0015] In one possible implementation, configuring and running a JMeter performance test script includes:
[0016] Configure user-defined variables and abstract the key parameters of this performance test into variable parameters;
[0017] Add a backend listener of the time series database in the sampler, and configure the variable parameters into the parameter values of the backend listener;
[0018] A thread group is configured, and the variable parameters are passed to a post-script through a preset thread group, so that corresponding performance test data and performance indicator data are extracted from the time series database through the post-script.
[0019] In a possible implementation, querying the time series database for corresponding performance test data and performance indicator data includes:
[0020] Determining a query parameter based on the variable parameter, the query parameter including at least one of a time interval, a performance test identifier, a performance test scenario name, and a test user name;
[0021] Based on the query parameters, query conditions are constructed to query corresponding performance test data and performance indicator data from the time series database based on the query conditions.
[0022] In a possible implementation, the performance indicator data includes an average CPU usage rate, and the average CPU usage rate is obtained as follows:
[0023] Based on the query parameters, filter out the CPU idle time indicator;
[0024] Using a window aggregation function to group the CPU idle time indicators and calculate the average value;
[0025] The average value is converted into the average CPU usage.
[0026] In a possible implementation, the performance indicator data includes memory usage, and the memory usage is obtained in the following manner:
[0027] Based on the query parameters, filter out the current available memory amount and the total memory capacity;
[0028] A memory usage rate is calculated based on the available memory amount and the total memory capacity.
[0029] In a possible implementation, associating the performance test data with the performance indicator data includes:
[0030] Determine associated keywords, where the associated keywords include at least one of a performance test identifier, a test start and end time, and a target test host network address;
[0031] Associating the performance test data and the performance indicator data based on the associated keywords;
[0032] The performance test identifier is determined in the following manner:
[0033] Get the current time, and format the current time into a digital string as a timestamp;
[0034] The timestamp is set as a global property of JMeter as the performance test identifier.
[0035] In a second aspect, a JMeter-based performance test data storage device is provided, comprising:
[0036] A database configuration unit, configured to configure a database, wherein the database includes a time series database and a relational database;
[0037] A performance test execution unit, configured to configure and run a JMeter performance test script, generate performance test data, and write the performance test data into the time series database;
[0038] A performance indicator data storage unit is used to obtain the performance indicator data of the target test host based on the start and end time of the JMeter performance test, and write the performance indicator data into the time series database;
[0039] A data association unit, configured to query the time series database for corresponding performance test data and performance indicator data, associate the performance test data with the performance indicator data, and generate an association result;
[0040] The associated data transfer unit is used to transfer the associated result to the relational database.
[0041] In a third aspect, a computer device is provided, comprising a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, wherein when the processor executes the computer-readable instructions, the steps of the JMeter-based performance test data storage method as described above are implemented.
[0042] In a fourth aspect, a readable storage medium is provided, wherein the readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by a processor, the steps of the JMeter-based performance test data storage method as described above are implemented.
[0043] The above-mentioned JMeter-based performance test data storage method, device, computer equipment and storage medium, its method implementation includes: configuring a database, the database includes a time-series database and a relational database; configuring and running the JMeter performance test script, generating performance test data, and writing the performance test data into the time-series database; based on the start and end time of the JMeter performance test, obtaining the performance index data of the target test host, and writing the performance index data into the time-series database; querying the corresponding performance test data and performance index data in the time-series database, associating the performance test data and the performance index data, and generating an association result; transferring the association result to the relational database. In the embodiment of the present application, a time-series database and a relational database are constructed. In each independently initiated performance test process, the performance process data and the host performance index are batch-associated and stored in the time-series database. The time-series database characteristics are used to efficiently compress the time-series data, greatly reduce the storage resource occupancy, and alleviate the storage cost pressure in large-scale testing scenarios. At the same time, the data of a single performance test is mapped and converted, and the batch of time-series data is converted into relational data for storage. It realizes the fully automatic association and recording of performance test data, optimizes storage with the help of time-series database, and adapts to flexible query analysis based on relational database, effectively improving the efficiency and accuracy of data management, and can more conveniently carry out data tracing, bottleneck location and strategy optimization, solving the problem of performance test data storage and management in the whole link. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0045] Figure 1 This is a flow chart of a JMeter-based performance test data storage method in one embodiment of the present application;
[0046] Figure 2 This is a structural diagram of a JMeter-based performance test data storage device in one embodiment of the present application;
[0047] Figure 3 Schematic diagram of a computer device in one embodiment of the present application. DETAILED DESCRIPTION
[0048] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0049] In one embodiment, if Figure 1 As shown, a JMeter-based performance test data storage method is provided, including the following steps:
[0050] In step S110, a database is configured, wherein the database includes a time series database and a relational database;
[0051] Time-series databases, such as InfluxDB, TimescaleDB, and OpenTSDB, leverage targeted optimizations for time-series data to efficiently store time-stamped, continuous data during performance testing (e.g., changes in host CPU and memory metrics over time). They have built-in time series data compression algorithms to reduce storage usage and provide time window aggregation functions (such as aggregateWindow) to facilitate trend analysis by test period.
[0052] Relational databases such as MySQL, Oracle, and SQLite can be used to store structured business-related data, such as performance test metadata (test run ID, scenario name, user name, etc.). They can support complex SQL queries, and transaction mechanisms ensure data consistency.
[0053] Alternatively, taking InfluxDB as an example, its construction process is as follows: creating buckets (Buckets), which can be named according to test type or project to facilitate the distinction of data from different business lines. Key policy configurations, such as the time-to-live (TTL) policy, can set an automatic data expiration time (such as 30 days) to avoid the accumulation of historical test data; sharding strategies (Shard Group), such as dividing shards by day or week, to optimize time range query performance (such as querying test data for a certain week). Data structure design includes measurement (tables), which can be created by metric type, such as system_metrics for storing host metrics and api_metrics for storing interface metrics; tags (Tags), used to add test dimension identifiers, such as runId, for quick data filtering; fields (Fields), which store specific metric values and timestamps.
[0054] Taking MySQL as an example, the construction process can include creating a database and tables. These tables may include core tables for storing test metadata, interface performance results, host metric summaries, and relationships. The table structure may include primary keys and indexes. For example, setting runId as the primary key ensures unique data for each test, and creating indexes for commonly queried fields such as test_name and host_ip to improve retrieval efficiency.
[0055] It is understandable that by combining the deployment of a time-series database and a relational database, a dual-database architecture is formed for efficient storage of time-series data and flexible analysis of structured data. This can solve the high-throughput writing and time-dimensional analysis of real-time indicators in performance testing, as well as the structured management and multi-dimensional correlation queries of test metadata.
[0056] In step S120, a JMeter performance test script is configured and run to generate performance test data, and the performance test data is written into the time series database;
[0057] Among them, JMeter is an open source performance testing tool, which is mainly used for functional verification, performance testing, stress testing and load testing of software / systems.
[0058] Optionally, use JMeter to create and configure thread groups, user-defined variables, HTTP request samplers, backend listeners, teardown thread groups and other related components. The JMeter performance script implements the test logic through the combination of these components. The test execution process is loaded in the order of test plan, configuration elements, and pre-processors. Global parameter sharing is achieved through user-defined variables. The pre-processor is used to dynamically generate request parameters and the post-processor is used to extract cross-request data. With the help of tags such as runId, the backend listener can associate the test results with the execution environment in real time. After the test is completed, the teardown thread group is triggered to complete the finishing work. At the same time, the performance test data generated during the test process is stored in the time series database through the time series database plug-in.
[0059] Among them, user-defined variables are used to store reusable test parameters, such as URLs and user names; HTTP request samplers are used to send specific interface requests; backend listeners are used to write test results to the database; and teardown thread groups are used to perform cleanup operations after the test is completed.
[0060] In step S130, based on the start and end time of the JMeter performance test, the performance indicator data of the target test host is obtained, and the performance indicator data is written into the time series database;
[0061] Alternatively, deploy the Prometheus service using a containerized approach (such as Docker). After configuring the collection frequency and monitoring targets, Prometheus collects metrics from monitored objects (such as servers and applications) at the specified frequency and stores them as time series. Specifically, multiple monitoring components (Node Exporters) can be deployed on the target test host to expose system metrics such as CPU, memory, and disk I / O. Prometheus pulls these metrics via HTTP and stores them in a local TSDB database. It then writes the performance metric data to a time series database such as InfluxDB. For example, after initiating a performance test, host performance metric data is queried and obtained based on the test's active time interval and written to a time series database.
[0062] It's important to note that due to differences in data formats between Prometheus and time-series databases like InfluxDB, data conversion requires an intermediate adapter mechanism. For example, specialized adapters (such as the PrometheusInfluxDBWriter) can be used to receive Prometheus output data in real time and convert it to the LineProtocol format supported by InfluxDB. Alternatively, scheduled tasks (such as Python scripts) can be used to call the Prometheus API to query metric data and batch write data according to the InfluxDB table structure (including fields such as timestamps, metric names, host tags, and values).
[0063] In step S140, the corresponding performance test data and performance indicator data are searched in the time series database, the performance test data and the performance indicator data are associated to generate an association result;
[0064] Optionally, use Python scripts to query the corresponding performance test data and performance indicator data in a time-series database using key test parameters such as the test ID, scenario name, and time range as query conditions. Leveraging shared correlation fields such as timestamps and test identifiers, interface performance data and host resource indicator data within the same test period are matched, generating a correlation result that includes interface performance and host resource utilization, facilitating a comprehensive analysis of the relationship between performance bottlenecks and resource usage.
[0065] In step S150, the association result is transferred to the relational database.
[0066] Optionally, the performance test data, performance indicator data, and associated fields generated in the time-series database can be extracted according to the relational database's table structure. Through data conversion and mapping, these data can be transferred to the corresponding data tables in the relational database for structured storage. This facilitates subsequent in-depth exploration and application of performance test and indicator data through complex query and multi-dimensional analysis capabilities of the relational database. The automated recording of performance test process data can effectively reduce storage resource costs, minimize data costs, and maximize data preservation, while ensuring the effective preservation of critical data.
[0067] In an embodiment of the present application, a performance test data storage method based on JMeter is provided, including: configuring a database, the database including a time series database and a relational database; configuring and running a JMeter performance test script, generating performance test data, and writing the performance test data into the time series database; obtaining the performance index data of the target test host based on the start and end time of the JMeter performance test, and writing the performance index data into the time series database; querying the corresponding performance test data and performance index data in the time series database, associating the performance test data and the performance index data, and generating an association result; transferring the association result into the relational database. In an embodiment of the present application, a time series database and a relational database are constructed, and in each independently initiated performance test process, the performance process data and the host performance index are batch-associated and stored in the time series database, and the time series database characteristics are used to efficiently compress the time series data, greatly reducing the storage resource occupancy and alleviating the storage cost pressure in large-scale testing scenarios. At the same time, the data of a single performance test is mapped and transformed, and batches of time series data are converted into relational data for storage. It realizes the fully automatic association and recording of performance test data, optimizes storage with the help of time-series database, and adapts to flexible query analysis based on relational database, effectively improving the efficiency and accuracy of data management, and can more conveniently carry out data tracing, bottleneck location and strategy optimization, solving the problem of performance test data storage and management in the whole link.
[0068] In one embodiment of the present application, obtaining performance indicator data of the target test host and writing the performance indicator data into the time series database includes:
[0069] Configuring multiple target monitoring components in the target test host to monitor performance indicator data of the target test host;
[0070] The monitored performance indicator data is obtained and written into the storage bucket corresponding to the time series database.
[0071] Optionally, after deploying the Prometheus service, configure the Node Exporter as a monitoring component on the service host under test to monitor and obtain real-time system performance metrics such as CPU, memory, and disk I / O. Simultaneously, install the Telegraf agent service and use its plug-in mechanism to collect complementary or additional performance metrics (such as process-level metrics and network traffic). After data processing, store the metrics data in the corresponding bucket of the time series database.
[0072] This dual monitoring solution flexibly adapts to diverse monitoring needs: Prometheus combined with Node Exporter is suitable for collecting and alerting standardized system metrics, while Telegraf can expand monitoring scope through a rich set of plugins. Prometheus writes data to InfluxDB using remote_write or an adapter, while Telegraf writes directly using the outputs.influxdb plugin. Data from both is stored in the same bucket or in different buckets according to different measurements (such as prom_metrics and telegraf_metrics), providing comprehensive and reliable data support for subsequent performance analysis.
[0073] In one embodiment of the present application, configuring and running a JMeter performance test script includes:
[0074] Configure user-defined variables and abstract the key parameters of this performance test into variable parameters;
[0075] Add a backend listener of the time series database in the sampler, and configure the variable parameters into the parameter values of the backend listener;
[0076] A thread group is configured, and the variable parameters are passed to a post-script through a preset thread group, so that corresponding performance test data and performance indicator data are extracted from the time series database through the post-script.
[0077] Optionally, use JMeter to create and configure related components, such as thread groups, user-defined variables, HTTP request samplers, backend listeners, and teardown thread groups. Specifically, add the user-defined variables configuration element in JMeter and configure key variables for this performance test, such as the run ID (runId), version number (version), environment name (environment_name), thread number (users_num), duration (duration), InfluxDB bucket name (bucket), performance test scenario name (nodeName), test user name (testName), InfluxDB connection information (influxDBURL), influxDBToken, and host IP addresses (app_server_host and db_server_host). Then, add the InfluxDB backend listener to the HTTP sampler and assign the previously configured variables (test user name (testName), performance test scenario name (nodeName), run ID (runId), InfluxDB connection information (influxDBURL), influxDBToken, and InfluxDB bucket name (bucket)) to the listener's parameter values. Finally, the teardown thread group passes parameters through the user-defined variable parameters and calls the Python script after the performance test is completed to obtain, query, and calculate the performance test process data and result data. The data is then stored in the time series database through the time series database plug-in.
[0078] In one embodiment of the present application, querying the corresponding performance test data and performance indicator data in the time series database includes:
[0079] Determining a query parameter based on the variable parameter, the query parameter including at least one of a time interval, a performance test identifier, a performance test scenario name, and a test user name;
[0080] Based on the query parameters, query conditions are constructed to query corresponding performance test data and performance indicator data from the time series database based on the query conditions.
[0081] Optionally, establish a database connection using the client library provided by the time series database. Construct a precise query statement based on a time interval (such as the last 12 hours or 24 hours), at least one of the following filter criteria: the performance test unique identifier (runId), the scenario name (nodeName), and the test username (testName). Retrieve the target performance test data from the corresponding bucket. Convert the query results into a Python data structure (such as a dictionary or DataFrame). The query results include performance test data such as the request interface name, average response time, total number of request samples, request start and end times, number of successes and failures, and success rate.
[0082] In addition, the client library provided by the time series database is used to establish a database connection. Based on the time interval (such as the last 12 hours or 24 hours) and at least one of the following filter criteria: the performance test unique identifier (runId), the scenario name (nodeName), and the test username (testName), a precise query statement is constructed to retrieve the target performance indicator data from the corresponding storage bucket. The query results are converted into a Python data structure (such as a dictionary or DataFrame) containing performance indicator data such as timestamp, host name, CPU usage, and memory usage.
[0083] Specifically, the performance test identifier of JMeter is used to obtain the start and end time of the performance test. Based on the time interval and host IP, the server-related indicator data is obtained, and the interface data and host data during the performance test can be associated and recorded.
[0084] In a possible implementation, the performance indicator data includes an average CPU usage rate, and the average CPU usage rate is obtained as follows:
[0085] Based on the query parameters, filter out the CPU idle time indicator;
[0086] Using a window aggregation function to group the CPU idle time indicators and calculate the average value;
[0087] The average value is converted into the average CPU usage.
[0088] Optionally, based on a specified time interval (such as the test start and end time) and IP address, the node_CPU_seconds_total metric for the corresponding host is filtered from the time series database, and CPU idle time data with a mode value of "idle" is filtered out. Next, the derivative function is used to calculate the per-second rate of change of this metric to reflect real-time changes in CPU time. Non-idle time is aggregated and converted into a percentage of CPU utilization, facilitating an intuitive understanding of resource utilization. The aggregateWindow function is then used to group and aggregate the data at a granularity of one minute, calculating the average CPU utilization per minute. This reduces the dimensionality of the high-frequency sampled data into a more easily analyzable time series. Finally, the average values for all time windows are grouped and statistically analyzed, and the mean function is used again to calculate the average CPU utilization data for multiple consecutive groups within the test period. This provides a comprehensive and detailed overview of the dynamic CPU resource usage of the host throughout the performance test, providing reliable data support for subsequent analysis of system performance bottlenecks and resource optimization.
[0089] In a possible implementation, the performance indicator data includes an average memory usage rate, and the average memory usage rate is obtained by:
[0090] Based on the query parameters, filter out the current available memory amount and the total memory capacity;
[0091] A memory usage rate is calculated based on the available memory amount and the total memory capacity.
[0092] Optionally, based on a specified time interval (such as the start and end timestamps of the test execution) and the target host's IP address, we filter memory metric data for a specific host within that time range from the time series database. Specifically, this involves two core metrics: node_memory_MemAvailable_bytes (currently available system memory) and node_memory_MemTotal_bytes (total system memory). This step ensures that the acquired data is highly relevant and unbiased for the test through precise time filtering and IP location.
[0093] For the selected consecutive sets of memory data, the standard formula for calculating memory utilization is used: Memory utilization = 100% - (Available memory / Total memory × 100%). For example, if the system has 8GB of total memory (8,589,934,592 bytes) and available memory at a certain moment is 2GB (2,147,483,648 bytes), substituting this into the formula yields: 100% - (2,147,483,648 / 8,589,934,592 × 100%) ≈ 75%, meaning the memory utilization at that moment is 75%.
[0094] In one embodiment of the present application, associating the performance test data with the performance indicator data includes:
[0095] Determine associated keywords, where the associated keywords include at least one of a performance test identifier, a test start and end time, and a target test host network address;
[0096] Associating the performance test data and the performance indicator data based on the associated keywords;
[0097] The performance test identifier is determined in the following manner:
[0098] Get the current time, and format the current time into a digital string as a timestamp;
[0099] The timestamp is set as a global property of JMeter as the performance test identifier.
[0100] Optionally, to achieve structured storage and correlation analysis of performance test-related information, it is necessary to logically associate the various variables passed in with host performance metric data and then transfer them to a relational database. Specifically, the unique identifier of the performance test run, runId, the test start and end times, and the network address of the target test host are used as the primary key to achieve multi-dimensional correlation. Test metadata, such as the performance test scenario name nodeName, the test user name testName, the test version, test environment information (e.g., whether the test environment is production, test, or development), concurrency count, and duration, are associated with host performance metric data (e.g., average CPU usage, average memory usage, and disk I / O) collected and stored in InfluxDB via Prometheus or Telegraf. Design a reasonable table structure in MySQL. For example, create a master table to store basic test information, including fields such as runId, nodeName, testName, test version, test environment, concurrency count, and duration. Then, create a subtable to store host performance metric data, establishing a foreign key relationship with the master table using runId. During the transfer process, the host performance indicator data filtered by runId in the time series database is matched with the test metadata in the main table according to the time series or aggregated statistical results (such as average, maximum, minimum, etc.). This ensures that each performance indicator data can be clearly associated with the specific test scenario, tester, test version, environment, and other information, thereby forming a complete performance test data chain in the relational database. This facilitates subsequent multi-dimensional data analysis through SQL queries, such as comparing the performance differences between different versions by test version, analyzing the system performance in different environments by test environment, or combining the number of concurrent users with host performance indicators to evaluate the resource consumption of the system under different loads, etc., providing efficient and reliable data support for performance optimization and test report generation.
[0101] It's important to note that in JMeter performance testing, to generate a unique identifier for subsequent storage and querying of test data, the time and setProperty functions are used to create and set the runId property. The time function retrieves the current timestamp, specifying the format of year-month-day-hour-minute-second-millisecond (e.g., 20251025123045123) to ensure uniqueness and sequentiality. The setProperty function then sets this formatted timestamp as a JMeter property named runId. This runId persists throughout the test and is passed to various components and subsequent processing, allowing all test data to be associated with that specific test run. Whether stored in a database, written to a file, or used for results analysis, the runId serves as a key identifier to ensure test data consistency and traceability, preventing data confusion between different test runs and providing fundamental support for performance test data analysis and results tracking.
[0102] In the embodiment of the present application, a time-series database and a relational database are constructed. During each independently initiated performance test, the performance process data and the host performance indicators are batch-associated and stored in the time-series database. The time-series database characteristics are used to efficiently compress the time-series data, greatly reducing the storage resource usage and alleviating the storage cost pressure in large-scale testing scenarios. At the same time, the data of a single performance test is mapped and transformed, and batches of time-series data are converted into relational data for storage. The fully automatic association and recording of performance test data is achieved, which not only optimizes storage with the help of a time-series database, but also relies on the relational database to adapt to flexible query analysis, effectively improving the efficiency and accuracy of data management, and can more conveniently carry out data tracing, bottleneck location and strategy optimization, solving the problem of performance test data storage and management in the entire link.
[0103] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0104] In one embodiment, a JMeter-based performance test data storage device is provided, which corresponds one-to-one to the JMeter-based performance test data storage method in the above embodiment. Figure 2 As shown, the JMeter-based performance test data storage device includes a database configuration unit 10, a performance test execution unit 20, a performance indicator data storage unit 30, a data association unit 40, and an associated data transfer unit 50. The functional modules are described in detail as follows:
[0105] A database configuration unit 10 is used to configure a database, wherein the database includes a time series database and a relational database;
[0106] The performance test execution unit 20 is used to configure and run the JMeter performance test script, generate performance test data, and write the performance test data into the time series database;
[0107] The performance indicator data storage unit 30 is used to obtain the performance indicator data of the target test host based on the start and end time of the JMeter performance test, and write the performance indicator data into the time series database;
[0108] A data association unit 40 is configured to query the time series database for corresponding performance test data and performance indicator data, associate the performance test data with the performance indicator data, and generate an association result;
[0109] The associated data transfer unit 50 is used to transfer the associated result to the relational database.
[0110] In one embodiment of the present application, the performance indicator data storage unit 30 is further configured to:
[0111] Configuring multiple target monitoring components in the target test host to monitor performance indicator data of the target test host;
[0112] The monitored performance indicator data is obtained and written into the storage bucket corresponding to the time series database.
[0113] In one embodiment of the present application, the performance test execution unit 20 is further configured to:
[0114] Configure user-defined variables and abstract the key parameters of this performance test into variable parameters;
[0115] Add a backend listener of the time series database in the sampler, and configure the variable parameters into the parameter values of the backend listener;
[0116] A thread group is configured, and the variable parameters are passed to a post-script through a preset thread group, so that corresponding performance test data and performance indicator data are extracted from the time series database through the post-script.
[0117] In one embodiment of the present application, the data association unit 40 is further configured to:
[0118] Determining a query parameter based on the variable parameter, the query parameter including at least one of a time interval, a performance test identifier, a performance test scenario name, and a test user name;
[0119] Based on the query parameters, query conditions are constructed to query corresponding performance test data and performance indicator data from the time series database based on the query conditions.
[0120] In one embodiment of the present application, the performance indicator data includes an average CPU usage rate, and the average CPU usage rate is obtained by:
[0121] Based on the query parameters, filter out the CPU idle time indicator;
[0122] Using a window aggregation function to group the CPU idle time indicators and calculate the average value;
[0123] The average value is converted into the average CPU usage.
[0124] In one embodiment of the present application, the performance indicator data includes memory usage, and the memory usage is obtained in the following manner:
[0125] Based on the query parameters, filter out the current available memory amount and the total memory capacity;
[0126] A memory usage rate is calculated based on the available memory amount and the total memory capacity.
[0127] In one embodiment of the present application, the data association unit 40 is further configured to:
[0128] Determine associated keywords, where the associated keywords include at least one of a performance test identifier, a test start and end time, and a target test host network address;
[0129] Associating the performance test data and the performance indicator data based on the associated keywords;
[0130] The performance test identifier is determined in the following manner:
[0131] Get the current time, and format the current time into a digital string as a timestamp;
[0132] The timestamp is set as a global property of JMeter as the performance test identifier.
[0133] In the embodiment of the present application, a time-series database and a relational database are constructed. During each independently initiated performance test, the performance process data and the host performance indicators are batch-associated and stored in the time-series database. The time-series database characteristics are used to efficiently compress the time-series data, greatly reducing the storage resource usage and alleviating the storage cost pressure in large-scale testing scenarios. At the same time, the data of a single performance test is mapped and transformed, and batches of time-series data are converted into relational data for storage. The fully automatic association and recording of performance test data is achieved, which not only optimizes storage with the help of a time-series database, but also relies on the relational database to adapt to flexible query analysis, effectively improving the efficiency and accuracy of data management, and can more conveniently carry out data tracing, bottleneck location and strategy optimization, solving the problem of performance test data storage and management in the entire link.
[0134] For the specific definition of the JMeter-based performance test data storage device, please refer to the definition of the JMeter-based performance test data storage method above, which will not be repeated here. The various modules in the above-mentioned JMeter-based performance test data storage device can be implemented in whole or in part by software, hardware and their combination. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.
[0135] In one embodiment, a computer device is provided. The computer device may be a terminal device, and its internal structure diagram may be as follows: Figure 3 As shown. The computer device includes a processor, a memory, and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a readable storage medium. The readable storage medium stores computer-readable instructions. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer-readable instructions are executed by the processor, a performance test data storage method based on JMeter is implemented. The readable storage medium provided in this embodiment includes a non-volatile readable storage medium and a volatile readable storage medium.
[0136] In an embodiment of the present application, a computer device is provided, including a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor. When the processor executes the computer-readable instructions, the steps of the JMeter-based performance test data storage method are implemented.
[0137] In an embodiment of the application, a readable storage medium is provided, which stores computer-readable instructions. When the computer-readable instructions are executed by a processor, the steps of the above-mentioned JMeter-based performance test data storage method are implemented.
[0138] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware through computer-readable instructions. The computer-readable instructions can be stored in a non-volatile readable storage medium or a volatile readable storage medium. When the computer-readable instructions are executed, they can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0139] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0140] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.
Claims
1. A performance test data storage method based on JMeter, characterized in that: The method comprises: Configuring a database, wherein the database includes a time series database and a relational database; Configuring and running a JMeter performance test script to generate performance test data and write the performance test data into the time series database; wherein configuring and running the JMeter performance test script includes: configuring user-defined variables to abstract key parameters of this performance test into variable parameters; adding a backend listener of the time series database in a sampler and configuring the variable parameters into the parameter values of the backend listener; configuring a thread group and passing the variable parameters to a post-script through a preset thread group, so that the post-script can extract corresponding performance test data and performance indicator data from the time series database; Based on the start and end time of the JMeter performance test, multiple target monitoring components are configured in the target test host to monitor the performance indicator data of the target test host, wherein the performance indicator data includes at least one of the average CPU usage and the memory usage; the monitored performance indicator data is obtained and written into the storage bucket corresponding to the time series database; Query the corresponding performance test data and performance indicator data in the time series database: determine the query parameters based on the variable parameters, the query parameters including at least one of the time interval, the performance test identifier, the performance test scenario name and the test user name; construct the query conditions based on the query parameters to query the corresponding performance test data and performance indicator data from the time series database based on the query conditions; determine the associated keywords, the associated keywords including the current performance test identifier, the test start and end time and the target test host network address; associate the performance test data and the performance indicator data based on the associated keywords to generate an associated result; wherein the performance test identifier is determined in the following manner: obtain the current time, format the current time into a digital string as a timestamp; set the timestamp as a global property of JMeter as the performance test identifier; The association result is transferred to the relational database.
2. The JMeter-based performance test data storage method according to claim 1, wherein: The performance indicator data includes the average CPU usage, which is obtained by: Based on the query parameters, filter out the CPU idle time indicator; Using a window aggregation function to group the CPU idle time indicators and calculate the average value; The average value is converted into the average CPU usage.
3. The JMeter-based performance test data storage method according to claim 1, wherein: The performance indicator data includes memory usage, which is obtained by: Based on the query parameters, filter out the current available memory amount and the total memory capacity; A memory usage rate is calculated based on the available memory amount and the total memory capacity.
4. A performance test data storage device based on JMeter, characterized in that: The device comprises: A database configuration unit, configured to configure a database, wherein the database includes a time series database and a relational database; A performance test execution unit is configured to configure and run a JMeter performance test script, generate performance test data, and write the performance test data into the time series database; wherein, configuring and running the JMeter performance test script includes: configuring user-defined variables to abstract key parameters of this performance test into variable parameters; adding a backend listener of the time series database to a sampler, and configuring the variable parameters into the parameter values of the backend listener; configuring a thread group, and passing the variable parameters to a post-script through a preset thread group, so that the post-script can extract corresponding performance test data and performance indicator data from the time series database; A performance indicator data storage unit is configured to configure multiple target monitoring components in a target test host based on the start and end time of the JMeter performance test, and is configured to monitor performance indicator data of the target test host, wherein the performance indicator data includes at least one of average CPU usage and memory usage; obtain the monitored performance indicator data, and write the performance indicator data into a storage bucket corresponding to the time series database; A data association unit is used to query the corresponding performance test data and performance indicator data in the time series database: based on the variable parameters, determine the query parameters, the query parameters include at least one of the time interval, the performance test identifier, the performance test scenario name and the test user name; based on the query parameters, construct a query condition to query the corresponding performance test data and performance indicator data from the time series database based on the query condition; determine the associated keywords, the associated keywords include at least one of the current performance test identifier, the test start and end time and the target test host network address; based on the associated keywords, associate the performance test data and the performance indicator data to generate an associated result; wherein, the performance test identifier is determined in the following manner: obtain the current time, format the current time into a digital string as a timestamp; set the timestamp as a global property of JMeter as the performance test identifier; The associated data transfer unit is used to transfer the associated result to the relational database.
5. A computer device comprising a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, wherein: When the processor executes the computer-readable instructions, the steps of the JMeter-based performance test data storage method according to any one of claims 1 to 3 are implemented.
6. A readable storage medium storing computer-readable instructions, characterized in that: When the computer-readable instructions are executed by a processor, the steps of the JMeter-based performance test data storage method according to any one of claims 1 to 3 are implemented.
Citation Information
Patent Citations
Method for generating performance test report, electronic device and readable storage medium
CN108845914A
Data management method and device and storage medium
CN117435591A