performance regression when running sysbench with inno log turned on

Monty, Brian thought you may know why this is happening, if thats not the case move it to unassigned for now.

Part of this could be tied to us not re-setting the server between the iterations for a concurrency level:
  # Run the benchmarks for the specified config
  for concurrency in concurrency_levels:
    for iteration in range(iterations):

So what happens is that on the second run of iteration N, we have the data in the logs from the first run and so on.
We do reset the server between concurrency levels.

However, this is still looking problematic as we are seeing a fair bit of slowdown as the log ages / grows.

Working on integrating dbqp / sysbench so we can use valgrind and whatnot more effectively to see wtf is up

Ran the benchmark for several iterations with the following settings via drizzle-automation for sysbench readwrite.
1) w/o the log turned on and no reset between iterations of a concurrency level.
2) with the log turned on and no reset
3) log on with a reset between iterations

Could not duplicate the drop off in performance noted above on my machine. The only difference noted was between the runs with and without the log enabled (which was expected). It should be noted that there is not *that* much of a performance hit when using the log, which is very nice news.

Posted the data above for others to check out.

Will be running the same tests with a profiler soon and will post anything of note when complete.

Thanks for running this. It may be hard to tell on a slower machine as 10% of 500tps isnt as much as 10% of 2000tps on a faster machine, it does look like the first run is always faster then the latter runs at higher concurrency levels nothing like the original numbers though. This may tell us though that cleaning out the inno replication table didnt have much impact though. Is there any way to run this on the sysbench machines without goofing up every other sysbench run? Maybe there was some anomaly when it ran before, the code has changed a bit as well sense the original test. Thanks again for running this!

I ran the GA release through sysbench with the inno replication log turned on results below its about a 10% hit. It did not exhibit the behavior described in this bug, in fact the performance numbers were significantly better. I wonder if the reorg of this table removing the gpb string made a difference, although I dont know why it would.

https://lists.launchpad.net/drizzle-benchmark/msg09626.html

moved to invalid, I suspect the problem may have been related to GPB being transposed to a string and stored in the sys_replication_log but its gone now