RE: Tech Tip du Jour: Benchmarking
> Date: Mon, 21 Jul 2008 14:03:51 +0100 > Subject: Re: Tech Tip du Jour: Benchmarking > From: obnoxio@serendipita.com > To: im_gumby@hotmail.com > CC: informix-list@iiug.org > > > Ian Michael Gumby said: > > On Jul 20, 6:41 pm, Fernando Nunes <domusonl...@gmail.com> wrote: > >> Obnoxio The Clown wrote: > > [SNIP} > > > > I wouldn't rely on OAT. > > Wouldn't you. Thanks for that. > If you are going to develop a suite of in house tests, then you will want to develop the test suite to work against multiple databases. How many shops are single database shops? Especially the ones that can afford you to pay you to spend time on this, usually have other databases in house. Not to mention a couple of different IDEs and languages. By going to a common, portable language, you'll get the most out of your efforts. > > I said: "Do your users use ODBC or JDBC? Make sure you have a full suite > of network-based tests as well." > This isn't a test of "network based tests". If you're going to write a test platform, you want to use a portable language and one that have the most connectivity. Java fits the bill. Your initial issue of benchmarking is to see how the database is performing. Taking the network out of the testing is going to be important. Of course if you choose to use Java, you can test local to the server, and then test from a platform over the network. This would allow you to determine the amount of delays caused by your network. (Maybe it will be an excuse to get faster routers and faster Nic cards for your kit. ;-) You could start and test your java tests as part of a JUnit Suite, but in thinking it over, you're not really testing a "pass/fail", so it may not be such a good idea. > > You're going to want to track the number of records currently in your > > system, and choose records of live data at random. > > Of course, the tests will vary based on your data, security, and what > > you're trying to "benchmark". This works well on single table > > queries. > > Its when you want to test complex table joins, then you have a bit > > more work to do. Perhaps a modules where you could pass in the query > > that you want benchmarkes? ;-) > > I said: "take a number of your most common queries" -- nothing there about > single tables. > My point was that you're going to want to test the overall performance of the system. This would mean running a comprehensive set of tests. Basic tests as well as more complex tests. Single table queries is the basic form of testing. Then you have simple compound queries. Also it may be an issue of a not so common form of queries that kills your performance. ;-) You may notice things that cause all queries to perform slower. That some of your assumptions didn't pan out. I mean it could be that your database system is running out of resources because you have a second instance running and while no one is using it, it still takes up resources just sitting there. > Perhaps you might want to read what's written before rushing off to tell > us that you're going to point us down the right track. > I did read what you wrote. But when you blog, you open yourself up to criticism. ;-) _________________________________________________________________ Keep your kids safer online with Windows Live Family Safety. http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008