Measuring DB performance

[Mag0007]

This is a very broad question, but here is my situation:

I have a server now (which runs fine) and we are going to replace it with a faster server. This server(s) run a RDBMS.

My questions are, how do we know if the database is performing well? What are some things to to measure a database (transcations per sec) , etc..etc..


**Notice: I did not mention the RDBMS + OS + Server specs because this is just a broad question.....

TIA!

 

[alvechurchdata]

**Notice: I did not mention the RDBMS + OS + Server specs because this is just a broad question.....

You might get some more helpful responses if you give us a clue.

The type of measurement depends on the type of database, the type of application, and who's asking the question.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[ceh4702]

First figure out what your projected usage per second will be. What is the average use now by people? What is the maximum demand usage you are seeing now. What do trends tell you about projected usage in the future (10 Years). Manufacturers like IBM and Compaq are always conductiong tests to determine the transactions per second.

What are the maintenance costs?

One thing you might want to come up with is what does the higher transaction per second reate going to cost you per transaction?

Will the increase benefit you, or just cost you more?

If you want to quantify an expenditure you might want to have measurements of usage per second over time to show a graph or a trend. Sometimes going from a dual processor system to a quad processor system might increase the per processor cost. Using raid might have certain advantages also. Then there are the Backup and Recovery costs. The total amount of RAM has a direct affect to the speed of a server also. We have one server at school that the software for the server requires 4 gigs of RAM just to run right.

If you do not like my post feel free to point out your opinion or my errors.

 

[ceh4702]

It might be worth it to have a consultant come in and measure your current performance during peak processing times. Kind of like a survey of your current complete system. They look at different issues like network traffic that might interfere with a faster transaction speed. The speed of your client machines and the speed of your network play a part in this.

Then there is the modular concept of separating the Application and the SQL and the database on different boxes and having different specs for each layer/box.

If you do not like my post feel free to point out your opinion or my errors.

 

[ceh4702]

Sorry for he multiple posts but we just went through a dual upgrade of our system and our communication system. We are using and IP Phone system and the network had to be beefed up to hanle it. If your organization is thinking about IP Phones this is something to consider. You might have to look at the total organizational picture. We upgraded both our servers and our phones at the same time.

If you do not like my post feel free to point out your opinion or my errors.

 

[juliane26]

in an transaction system to compare it is usefule to measure transactions per second together with number of users connected (all this scalability staff)
don't forget: everything has to be tuned for each new system, hardware as well as software. Otherwise your result might be not complete or even wrong and you might not benefit from new hardware as much as you could.

Well: if you are happy with the system as of today, your database and application are performing well enough for your needs.

ceh4702 is right, that a few more details about the architecture would help. Not necessaryly the products you use, but whether it is a 3-tier Java Application with an App Server involved or 2-tier OLTP system in C with no additional software; is network traffic an issue; also system performance depends upon hardware issues like using a SAN or local discs or whatever, and of course memory.

So probably you would get better answers about what to look at if you give some more details on what system you come from and tend to be going to.


Juliane

 

[PRPhx]

You also have to consider the number of people accessing your db at any given time and what is the data being used for. Is it simply being retained for reports that are used on a regular basis, only infrequently, by a call center, etc.


I work in the Corporate Records department of a large company (I'm the IT guy). We have a fairly large db of approx 5-7 gigabyte. This db is used by a number of users to display documents, thru a web app. The data is used as indexes for document retrieval. A document can be as small as a single page or can contain hundreds of pages.

Depending on the users desktop pc, access can seem like it takes forever. And in fact at times can even stall the pc (YUCK.. Win95, 32-64 Megs of Ram, and a hard drive that may have never been defragged).