Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Keve Nagy Newsgroups: comp.databases Subject: Re: Need suggestions on transaction performance comparison Date: Wed, 27 Apr 2011 11:42:59 +0200 Lines: 46 Message-ID: <91q6pcFoq3U1@mid.individual.net> References: <8umcroF55oU1@mid.individual.net> <201104071452.UTC.inkj2o$ogv$1@tioat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net HExiw2oC57uCSoZr4NPqZwLf/9WG5jRe2k1e97li8C3/v0RVKD Cancel-Lock: sha1:SAiKFfyUbhmmMaWHm4U66BHo9ak= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; hu; rv:1.9.1.18) Gecko/20110320 SeaMonkey/2.0.13 In-Reply-To: <201104071452.UTC.inkj2o$ogv$1@tioat.net> Xref: x330-a1.tempe.blueboxinc.net comp.databases:67 > Hard to imagine a single system (not to mention the communication > hardware) for that. 1) Do the math, say 50 million votes over 12 hours, > that would be over one thousand 'insert transactions' per second on > average. The peaks would likely be several or many times that. If there > are more elected positions per voter than just a single parliamentary > seat, multiply some more. 2) Look at all the plausible requirements, not > just the population. Eg., factors like how to size recovery logs or not > wanting to have to arrange a second election if the single system fails, > not to mention the arguments amongst the second set of losers. Some > things aren't naturally centralized, in most western countries votes are > counted on a local basis, eg. per riding. That might result in an > average load of only 100 transactions per second and several hundreds > peak. But in most (so-called) democracies the candidates will have their > own scrutineers and they'll want either paper ballots or paper output > from the voting systems. It's hard to imagine a computer system that can > do a judicial re-count. > > > I'm not up on current hardware but I'd say that besides doing the paper > analysis of the stuff above you could reasonably limit your stress-tests > to a much smaller scale. Thanks for pointing these out, Paul! Even though I was aware of these numbers, I didn't really think through their total effect the way you just highlighted. I have already amended the test plan accordingly, considering only a scaled-down version of the task. Having the election broken down to regions is a perfect example. In the meantime I have also made some progress in the implememtation of the load test. I concluded that Perl DBI can be my best friend here, allowing me to construct a tool that spawns and inserts data-records as required. And it can be run on virtually any O/S, and against any of my target database types. Where I still don't really have an answer is the measurement part. I don't see how to measure each database's performance of handling the INSERTs. Can't quite grab what to measure, how I could measure that, and how to feed it into something like gnuplot to get comparable graphs. Thoughts and pointers on such technical details would be more than welcome! Regards, -- Keve Nagy * Debrecen * Hungary keve(at)mail(dot)poliod(dot)hu