Benchmarking a new server with Readprobe.

[Dhubbuck]

Hi

Just wondering if any body can help.

We are in the process of installing a new server for a customer and came across the readprobe utility. We thought it would be a good idea to see what the difference in performance would be so ran readprobe on the new server and the results seem to drop by half for every new users connecting.

The customer is not using the enterprise database just the workgroup one.

New server is a 3ghz Xeon 5050 dual core server with 2Gb at the moment (4Gb later) and SAS Raid 10 disk array

We ran readprobe on the sports database and initially got 80,000 reads per second. When two users were connect we got 40,000, three user 20,000 until about 1300 read per second on average.

Is this normal?

Looking at the old test results we are a long way below them.

Are customers are only using databases of 200mb and around the 25user mark and are not complaining about performance on the old server but the results do seem a little strange.

Hope somebody can help

Thanks

Dale Hubbuck

 

[TomBascom]

You're using workgroup. Therefore you lack high volume concurrency features like -spin. Your best performance would be expected to be a single thread that has no competition -- So I'd say that no, it isn't very surprising that performance falls off a cliff when you run readprobe since the whole point is for each thread (process) to push as hard as it possibly can...

How does the 1 user result compare between the two machines? That's probably what you really need to know.

(FWIW very few of the tests on the web page are with workgroup -- almost all of them are with Enterprise...)

 

[Dhubbuck]

Thanks for the reply Tom.

I thought it was proberly due to the fact that it was the Workgroup Database.

The Live server results were
Number of CPUs: 1
Clock Speed: 2660
-Spin: 1
System Data:
1xXeon 2.66ghz 1Gb RAM
Workgroup Database Test on Live Server
sports 490
Progress Version 9.1D09 12/08/06 9:22 am
Startup: -spin 1
Users Time Rec/sec Blk/sec Lock/sec Busy/sec Spin/sec Wait/sec
==============================================================================
1 5.02 80097 161657
1 5.00 80334 162120
1 5.00 80344 162118
1 4.74 79805 161034
1 5.00 80508 162510
2 5.02 30267 61078
2 5.00 31869 64301
2 5.00 29847 60225
2 5.00 30177 60893
2 5.00 32695 65973

The New Server Results
Number of CPUs: 1
Clock Speed: 3000
-Spin: 1
System Data:
1xXeon 5050 Dual Core 3Ghz 2Gb Mem
Workgroup Server test on new Server
sports 490
Progress Version 9.1D09 12/08/06 9:29 am
Startup: -spin 1
Users Time Rec/sec Blk/sec Lock/sec Busy/sec Spin/sec Wait/sec
==============================================================================
1 4.39 78945 159276
1 5.36 79511 160468
1 5.00 79383 160223
1 5.00 79563 160562
1 5.02 79037 159473
2 4.27 36173 73008
2 5.00 36804 74266
2 5.00 36872 74396
2 5.00 39667 80068
2 5.00 36160 72944

So not a lot of difference but my only concern is that with a faster processer and memory I would have thought the new server would have had better results than the old one.

I will do some real application tests know we hopefully will show an improvement.

Thanks again

Dale

 

[TomBascom]

I'd have hoped the same thing.

On the bright side your degradation with too much load looks a bit less severe on the new server.

I'm just guessing but the difference might be explained by having multiple cores in the new server vs just the one in the old. You might be taking a performance hit as processes move around. Or something like that

BTW -- they're both Xeon processors. Is Hyper-threading enabled? If it is you might try it without just for kicks and grins.

While I'm thinking of it... 9.1d09 is ancient -- an upgrade might make a big difference.

In any event -- keep yourself clear on the key things that readprobe is telling you:

1) No report on these machines (as configured) will ever process more than 80,000 records per second. The real limit is probably a bit lower.

2) Don't try to break read-intense things up into parallel job streams (that's unusual -- it seems specific to this configuration and the workgroup license, you generally get the opposite result when using an Enterprise license.)

3) If you push it too hard things will get much worse in a hurry.