MySQL Forums
Forum List  »  Performance

UPDATE performance - 30/second?
Posted by: dradon
Date: December 02, 2004 03:12PM

I'm doing some rough benchmarking to determine if MySQL is a viable option for me but I'm very disappointed with the numbers I'm seeing, so I'm hoping perhaps someone can tell me if these numbers are reasonable or not.

Basically, I need to be able to update a small number of tables as frequently as possible. The database structure will be very simple, and for my benchmarking I'm actually just using a table with two columns - an integer ID and another integer to represent data that might be updated often.

I threw together a quick testing app in C# using MySQL 4.1.7-nt on the backend, connecting via ODBC by using the MySQL ODBC 3.51 driver. Specifically, I'm using one OdbcConnection and one OdbcCommand.

I'm using the OdbcCommand to run UPDATE queries similar to something like:

UPDATE MyTable SET DataColumn = <some number> WHERE IDColumn = <some ID>;

Pretty simple in my opinion. The problem is the speed of the UPDATES - I'm seeing numbers in the neighborhood of 30 UPDATES going through per second, which is much slower than I would like to see. Am I being unreasonable? Is 30/second a decent number?

Assuming the 30/second number is too low, does anyone have any pointers on speeding things up?

Some possibly relevant info:
I'm using a fresh install of the latest MySQL release, basically straight out of the box. The machine this is running on is a Windows 2000 pc, 2.2Ghz, 512MB RAM with nothing else running that should impact the performance. The database currently has only 2 very simple tables, each with only 2 integer columns and each containing only about 1000 rows.

Thanks for any help

Options: ReplyQuote

Written By
UPDATE performance - 30/second?
December 02, 2004 03:12PM
December 02, 2004 08:07PM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.