Thread: load testing
I wanted to do some quick load testing on a postgres database. Does anyone have any tips on how to go about doing this? Thanks much. Sally _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar � get it now! http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/
On Tuesday 09 March 2004 22:35, Sally Sally wrote: > I wanted to do some quick load testing on a postgres database. Does anyone > have any tips on how to go about doing this? See contrib/pgbench in the source distribution. It might also be packaged as RPMs/debs etc - not sure. -- Richard Huxton Archonet Ltd
On Tue, 9 Mar 2004, Sally Sally wrote: > I wanted to do some quick load testing on a postgres database. Does anyone > have any tips on how to go about doing this? > Thanks much. If you just wanna beat the database a bit to test for reliability etc, look at contrib/pgbench in the distro. If you want to test massive workloads, look at the OSDL tests on www.osdl.org: http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite/
> I wanted to do some quick load testing on a postgres database. Does anyone > have any tips on how to go about doing this? > Thanks much. Sure. Test after the manner in which the database is normally used, and with "real-world" data. I've seen far too many people "benchmark" a database system by opening a single connection, and issuing a number of queries. However, it's more common for a database server to be handling multiple queries at the same time. Also, I've seen far too many people use contrived test data and contrived queries. However, the nature of queries may be very different from the actual queries you run. Test with what you use! For my own benchmarking, I usually log ~10,000 queries from our production server, and start a Perl script that I whipped up quickly. It will split the queries into chunks, and test with 1 through 10 simultaneous connections, and that's been a very good indicator of how the machine in question will behave once it's put into production. steve