I'm not too sure what could be causing a regression in that patch. All that is happening in the work I did is to remove some case labels from the switch statement in mysql_execute_command() and replace them with their own classes. The only other patch merged into revision 1126 of the staging branch is Monty's pandora build stuff I believe.
While I agree that looking at those numbers it looks like a regression, I'm not really convinced there is one. For example, I ran the lp:drizzle/build branch through the regression system today (which has the same stuff as lp:drizzle/staging) and these are the numbers I got: read-only lp:drizzle/build-1126 2 1517.868000 lp:drizzle/build-1126 4 2663.328000 lp:drizzle/build-1126 8 4157.183000 lp:drizzle/build-1126 16 5674.173000 lp:drizzle/build-1126 32 5500.743000 lp:drizzle/build-1126 64 4889.671000 lp:drizzle/build-1126 128 4363.030000 lp:drizzle/build-1126 256 3825.326000 lp:drizzle/build-1126 512 2621.991000 lp:drizzle/build-1126 1024 1283.329000 lp:drizzle/build-1126 2048 623.358000 read/write lp:drizzle/build-1126 2 696.863333 lp:drizzle/build-1126 4 1140.660000 lp:drizzle/build-1126 8 1660.763333 lp:drizzle/build-1126 16 2000.490000 lp:drizzle/build-1126 32 2151.023333 lp:drizzle/build-1126 64 1841.243333 lp:drizzle/build-1126 128 1660.250000 lp:drizzle/build-1126 256 1334.256667 lp:drizzle/build-1126 512 841.133333 lp:drizzle/build-1126 1024 819.710000 So it looks like at concurrency level 512, there still appears to be a regression. Although I bet if we ran it through again, we would probably see different numbers... I was curious to see if my patch was causing a regression so I ran my branch on its own through the regression system. This branch has the entire switch statement in mysql_execute_command() removed so it actually has more work done than the branch that was merged into staging. Here are the numbers I got: read-only lp:~posulliv/drizzle/cleanup-exec-command-1168 2 1544.278000 lp:~posulliv/drizzle/cleanup-exec-command-1168 4 2708.862000 lp:~posulliv/drizzle/cleanup-exec-command-1168 8 4137.718000 lp:~posulliv/drizzle/cleanup-exec-command-1168 16 5669.148000 lp:~posulliv/drizzle/cleanup-exec-command-1168 32 5475.368000 lp:~posulliv/drizzle/cleanup-exec-command-1168 64 4857.823000 lp:~posulliv/drizzle/cleanup-exec-command-1168 128 4291.008000 lp:~posulliv/drizzle/cleanup-exec-command-1168 256 3697.420000 lp:~posulliv/drizzle/cleanup-exec-command-1168 512 2049.596000 lp:~posulliv/drizzle/cleanup-exec-command-1168 1024 1011.149000 lp:~posulliv/drizzle/cleanup-exec-command-1168 2048 568.179000 read/write lp:~posulliv/drizzle/cleanup-exec-command-1168 2 751.633333 lp:~posulliv/drizzle/cleanup-exec-command-1168 4 1156.610000 lp:~posulliv/drizzle/cleanup-exec-command-1168 8 1683.083333 lp:~posulliv/drizzle/cleanup-exec-command-1168 16 2625.083333 lp:~posulliv/drizzle/cleanup-exec-command-1168 32 2202.903333 lp:~posulliv/drizzle/cleanup-exec-command-1168 64 1989.500000 lp:~posulliv/drizzle/cleanup-exec-command-1168 128 1726.480000 lp:~posulliv/drizzle/cleanup-exec-command-1168 256 1462.993333 lp:~posulliv/drizzle/cleanup-exec-command-1168 512 1440.783333 lp:~posulliv/drizzle/cleanup-exec-command-1168 1024 843.286667 As you can see, the numbers for read/write are pretty good at all concurrency levels (including 512 and 1024). These large variances (look at the spike for concurrency level 16 above) are making it impossible for me to glean any information from these reports. It makes no sense to me that the numbers for my branch would be so different to the numbers obtained from running the staging branch. So when I run my branch that is merged into staging on its own, the numbers come out fine and show no regression. Any other ideas on what could be causing a regression (if there definitely is one)? -Padraig On Thu, Aug 27, 2009 at 9:42 PM, Lee Bieber<[email protected]> wrote: > I think we have a pretty serious regression with readwrite, take a look at > this view of build 1125 vs 1126. 512 and 1024 connections seemed to have > dropped off significantly. Any ideas what might have caused this? > . > 1126 innodb_1000K_readonly 2 1,512.89 > 1125 innodb_1000K_readonly 2 1,523.13 > 1125 innodb_1000K_readonly 4 2,679.88 > 1126 innodb_1000K_readonly 4 2,689.73 > 1125 innodb_1000K_readonly 8 4,137.83 > 1126 innodb_1000K_readonly 8 4,142.85 > 1125 innodb_1000K_readonly 16 5,624.94 > 1126 innodb_1000K_readonly 16 5,663.29 > 1125 innodb_1000K_readonly 32 5,443.96 > 1126 innodb_1000K_readonly 32 5,592.64 > 1125 innodb_1000K_readonly 64 4,822.81 > 1126 innodb_1000K_readonly 64 4,922.61 > 1125 innodb_1000K_readonly 128 4,226.14 > 1126 innodb_1000K_readonly 128 4,330.35 > 1126 innodb_1000K_readonly 256 3,767.20 > 1125 innodb_1000K_readonly 256 3,646.06 > 1126 innodb_1000K_readonly 512 2,576.44 > 1125 innodb_1000K_readonly 512 2,030.83 > 1126 innodb_1000K_readonly 1024 1,277.10 > 1125 innodb_1000K_readonly 1024 1,002.95 > 1125 innodb_1000K_readonly 2048 566.67 > 1126 innodb_1000K_readonly 2048 632.28 > > 1125 innodb_1000K_readwrite 2 693.22 > 1126 innodb_1000K_readwrite 2 706.97 > 1125 innodb_1000K_readwrite 4 1,118.15 > 1126 innodb_1000K_readwrite 4 1,138.10 > 1125 innodb_1000K_readwrite 8 1,577.70 > 1126 innodb_1000K_readwrite 8 2,024.12 > 1125 innodb_1000K_readwrite 16 2,056.66 > 1126 innodb_1000K_readwrite 16 2,061.63 > 1125 innodb_1000K_readwrite 32 2,203.37 > 1126 innodb_1000K_readwrite 32 2,111.02 > 1126 innodb_1000K_readwrite 64 1,851.07 > 1125 innodb_1000K_readwrite 64 1,955.83 > 1126 innodb_1000K_readwrite 128 1,665.41 > 1125 innodb_1000K_readwrite 128 1,742.90 > 1126 innodb_1000K_readwrite 256 1,336.60 > 1125 innodb_1000K_readwrite 256 1,442.81 > 1125 innodb_1000K_readwrite 512 1,433.94 > 1126 innodb_1000K_readwrite 512 729.27 > 1125 innodb_1000K_readwrite 1024 843.55 > 1126 innodb_1000K_readwrite 1024 714.69 > > > Padraig O'Sullivan wrote: >> >> On Thu, Aug 27, 2009 at 12:31 AM, Brian Aker<[email protected]> wrote: >> >>> >>> Hi! >>> >>> On Aug 26, 2009, at 8:10 PM, Padraig O'Sullivan wrote: >>> >>> >>>> >>>> whether there is a regression or not due to the large variances in the >>>> >>> >>> Same here. Rerun the numbers? I'll kick off a job here in a moment. >>> >> >> Cool. I've finished the patch where the entire switch statement in >> mysql_execute_command() is gone. I've kicked off a job on that branch >> to see what kind of numbers I get from that. >> >> -Padraig >> >> >>> >>> Cheers, >>> -Brian >>> >>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~drizzle-benchmark >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~drizzle-benchmark >> More help : https://help.launchpad.net/ListHelp >> > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-benchmark Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-benchmark More help : https://help.launchpad.net/ListHelp
