2

What are some rough performance limits (read/s, write/s) for a single database server (no master-slave architecture), assuming storage on disk? How many read/s, write/s, depending on the kind of disk? (SSD vs non-SSD) , assuming simple operations (select one row by primary key, update one row, correctly indexed). I assume this limit is dependent on disk seek/write.

EDIT: My question is more about getting rough metrics of the number of operations a database supports: to be able to know for example, if a new feature triggering 300 inserts/s can be supported without scaling out with additional servers.

2
  • Probably only benchmarks can tell you this not documentation. Dec 24, 2010 at 13:18
  • Impossible to anwser, it all depends on your needs. No benchmark did a test using your database nor using your application and hardware. Dec 24, 2010 at 13:26

3 Answers 3

0

You can read many benchmarks results here as if the website is a reliable source.

0

May I be so bold as to suggest you test it to get the answer for your own query. If you have windows run SSIO.exe on your development box to performance test the disk to understand how it performs doing nothing.

Then running performance monitor (assuming you are in MS-SQL TKProf maybe on Oracle - dont use mysql or others sorry there will be a similar tool.) Run your query and look at how many reads/ writes and how much CPU it took to do it. You can then compare the SSIO and Performance Monitor numbers and Scale the hardware requirements to handle the number of users / frequency that this update will need based on your current equipment.

Having said that 300 rows is a very small number of rows to be changing for any reasonable SQL Server even on fairly slow disks. Unless there are massive compounded indices or blobs etc. I have live in processes as the user watches a query that create 1.5M rows that run in fractions of a second on relatively modest hardware.

0

You can't judge without benchmarking your app and load.

It comes down to RAID levels, spindle speeds, size of transactions (not just "inserts"), triggers, foreign keys, hyperthreading, other apps on the server, RAM in the server, how disk are arranged (separate volumes for tempdb, one per DB t-log, MDFs etc), service pack level, RAID controller cache configuration, CPU Ls + L3 cache, number of cores, schema design, code...

Scaling up is easier then scaling out: you add overhead if you federate servers or partition tables. Cheaper to add RAM and more spindles.

A good article is Paul Nielson's 35k TPS. At least 100 times higher load than your 300 or so.

You must log in to answer this question.