Need help w/ benchmarking.

G

grndzero

New Member
I'm running 9.1D on SLES 9. I know it's not officially suported, but works with the LD_ASSUME_KERNEL. My work let our DBA go right in the middle of a project, which I am trying to finish. My coworker talked to someone @ INFORUM that mentioned that Progress runs much faster if AI and BI are on separate drives than DB, which I'm trying to sell. I found this http://explore.qad.com/presentations/tuesday/Foreman.ppt that seems to support this idea. So far I have run 'proutils <database> -C dbanalys' against both databases and found the devel RAID 0 (trying to sell RAID 10) to be about 2x faster than the single RAID 1 for everything. Unfortunently benchmarking outside the servers with Brio (report writer) seems to be it's own bottleneck.

If there's anything I can do to have more information than just proutils dbanalys data to work with. Is there any way to benchmark against a Progress DB from outside the server. I have Progress 9.1D Shared Network Install on my workstation.
 
Benchmarking is a pretty complex topic. Simply running dbanalys is pretty superficial (which you seem to know). It does not, for instance, tell you anything about transaction throughput -- which is what moving the AI and BI files will improve.

You should really try working with something that gives you some insight into your application load. (I'm guessing that it is one of the Infor products...)

Having said that there are several "generic" benchmarking tools available:

1) The ATM benchmark is Progress' general purpose benchmark. You can find it on PSDN. It is very heavily skewed to optimizing transaction throughput.

2) Readprobe is a benchmark of mine which measures your systems ultimate record read rate -- this is an upper bound. You'll never actually get there but you can come close. http://www.greenfieldtech.com/articles/how_fast_will_it_go.shtml

3) PACE is a tunable read/write load simulator that might be useful. http://www.greenfieldtech.com/articles/load_simulation.shtml
 
I "benchmark" my system all the time. I've created a separate DB called "vst". Every 15 mins (24 x 7) I extract a whole lot of Unix details (iostat, vmstat, etc) -- plus a generous sample of VST details about all ten productions DBs that I have -- including stats about every table and index -- and write it to the vst database.

Every night, just after midnight a job runs to extract flat-file details. Next morning, if I wish, I can import the files into an Excel template -- which then displays a myriad of details graphically. There are separate graphs for monthly trends, weekly trend, daily trends -- and 15-minute trends.

If I suspect a performance issue -- or if I change tuning parameters -- I can check the graphs to try and spot the problem -- or see what has changed as a result of what's changed.

(I can't sleep at night -- unless I'm surrounded by statistics!)

Ron.
 
You must log in or register to reply here.
Back
Top