Shulou(Shulou.com)06/01 Report--

How to implement the framework of sysbench, I believe that many inexperienced people are at a loss about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Sysbench is a very classic comprehensive performance testing tool, which supports CPU,IO, memory, especially database performance testing. So how does it achieve versatility? in conclusion, a large number of overloaded methods are used.

Overall architecture of sysbench

Sysbench is an overall framework for operating performance measurement calculations, and the only thing each department needs to do is to declare the required implementation. You only need to understand these three struct:

/ * the overall structure of a test case * / typedef struct sb_test {const char * sname; const char * lname; / * is specified below * / sb_operations_t ops; sb_builtin_cmds_t builtin_cmds; sb_arg_t * args; sb_list_item_t listitem;} sb_test_t / * specific operational implementation structure of a test case * / typedef struct {sb_op_init * init; / * initialization function * / sb_op_prepare * prepare; / * called after timers start, but before thread execution * / sb_op_thread_init * thread_init / * thread initialization (called when each thread starts) * / sb_op_print_mode * print_mode; / * print mode function * / sb_op_next_event * next_event; / * event generation function * / sb_op_execute_event * execute_event; / * event execution function * / sb_op_report * report_intermediate / * intermediate reports handler * / sb_op_report * report_cumulative; / * cumulative reports handler * / sb_op_thread_run * thread_run; / * main thread loop * / sb_op_thread_done * thread_done; / * thread finalize function * / sb_op_cleanup * cleanup / * called after exit from thread, but before timers stop * / sb_op_done * done; / * finalize function * /} sb_operations_t;/* the three-phase implementation structure of a test case * / typedef struct {sb_builtin_cmd_func_t * help; / * print help * / sb_builtin_cmd_func_t * prepare / * prepare for the test * / sb_builtin_cmd_func_t * run; / * run the test * / sb_builtin_cmd_func_t * cleanup; / * cleanup the test database, files, etc. * /} sb_builtin_cmds_t

Take the simplest example of CPU performance calculation, which needs to be implemented:

Static sb_test_t cpu_test = {.sname = "cpu", / * case abbreviation * / .lname = "CPU performance test", / * case full name * / .ops = {.init = cpu_init, / * initialize case * / .print _ mode = cpu_print_mode, / * before case starts Give instructions * / .next _ event = cpu_next_event, / * get the data of the next event * / .execute _ event = cpu_execute_event, / * execute the event * / .report _ cumulative = cpu_report_cumulative, / * output the periodic report * / .done = cpu_done / * after the end of the case Clean up * /}, .args = cpu_args / * parameter description required by sub-case * /}

After seeing this, the description of what a case needs to do is clear, from what parameters are required to initialization, event by event, the definition of the function is very clear. Other case of sysbench also need a complete structural description, such as io operation, which requires an additional prepare and cleandown declaration of case.

What is the complete process of sysbench? The yellow part is what the test case needs to implement.

Cdn.com/5203d6c360f30a87864cb807a45b43890f2b481c.png ">

At this point, it is clear that the framework of sysbench is still very easy to understand.

There is a concept of event in the above struct, and the definition of different test event is different: for example, the test case of CPU, an event is to obtain all prime numbers less than a certain number (default 10000). For example, fileio's test case, a read or a write operation is an event.

Introduction to threading of sysbench

What is the specific implementation of worker_thread: take a look at how a child thread in sysbench.c executes. The code is very clear and easy to understand:

Static int thread_run (sb_test_t * test, int thread_id) {sb_event_t event; int rc = 0; while (sb_more_events (thread_id) & & rc = = 0) {event = test- > ops.next_event (thread_id); if (event.type = = SB_REQ_TYPE_NULL) break; sb_event_start (thread_id) Rc = test- > ops.execute_event (& event, thread_id); sb_event_stop (thread_id);} return rc;}

Intermediate_report thread: periodically outputs performance data. The parameter item is:-- report-interval=N. For example, the test case for CPU: sysbench cpu-- report-interval=1. The output of the intercepted part is as follows:

Threads started! [1s] thds: 1 eps: 922.10 lat (ms,95%): 1.08 [2s] thds: 1 eps: 925.19 lat (ms,95%): 1.08 [3s] thds: 1 eps: 926.00 lat (ms,95%): 1.08 [4s] thds: 1 eps: 926.00 lat (ms,95%): 1.08 [5s] thds: 1 eps: 926.00 lat (ms,95%): 1.08 [6s] thds: 1 eps: 926.00 lat (ms) Thds: 1 eps: 925.00 lat (ms,95%): 1.08 [8s] thds: 1 eps: 926.02 lat (ms,95%): 1.08 [9s] thds: 1 eps: 925.99 lat (ms,95%): 1.08 [10s] thds: 1 eps: 924.98 lat (ms,95%): 1.08

Output a result per second. Eps is the number of event per second, lat unit is millisecond, and 95 quartile delay data is 1.08.

Checkpoints_report thread: if the periodic output is not enough, it can be output as a whole at a certain point in time. The parameter item is:-- report-checkpoints= [LIST,...]

Or for an example of CPU test case: sysbench cpu-- report-checkpoints=3,8 run, the output of the intercepted part is as follows:

Threads started! [3s] Checkpoint report:CPU speed: events per second: 923.01General statistics: total time: 3.0001s total number of events: 2771Latency (ms): min: 1.08 avg: 1.08 max : 1.22 95th percentile: 1.08 sum: 3000.88Threads fairness: events (avg/stddev): 2773.0000 execution time (avg/stddev): 3.0009 Checkpoint report:CPU speed 0.00 [8s] Checkpoint report:CPU speed: events per second : 924.47General statistics: total time: 8.0001s total number of events: 4622Latency (ms): min: 1.08 avg: 1.08 max: 1.16 95th percentile: 1.08 sum: 4998.04Threads fairness: events (avg/stddev): 4621.00000.00 execution time (avg/stddev): 4.99800.00

Tx_rate_controll thread, a thread that controls the output per second: the parameter entry is:-- rate=N, which is not controlled by default.

Or take the CPU test case as an example, control to run 10 event:sysbench cpu run-rate=10 per second, and capture part of the output as follows:

Running the test with following options:Number of threads: 1Target transaction rate: 10/secInitializing random number generator from current timePrime numbers limit: 10000Initializing worker threads...Threads startedCPU speed: events per second: 8.87 # not so accurate

Where is the output rate control? Sharp-eyed people can immediately see that it is in the sb_more_events function. So what does the sb_more_events function mainly do:

Determine whether to time out. The default is 10 seconds.

Determine whether the maximum number of event has been reached, if set

It's rate control.

In summary, it gives an overview of the overall implementation of the sysbench framework.

After reading the above, have you mastered how to implement the framework of sysbench? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.