|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Most benchmarking that we hear about in the PROGRESS community is focused on transaction throughput. "The ATM benchmark" is frequently cited in these conversations and is the source of many comparative numbers over the years.
Many real world performance problems are, however, related to how fast records can be read from the database -- not how fast you can write them. After all the read:write ratio for most applications is hundreds to one -- read performance is far more likely to be an issue than write performance!
An interesting question, therefore, is "how many records can my machine read per second?" The ultimate answer depends on a great many factors such as the amount of memory, the capabilities of the disk subsystem, the number of CPUs, their speed, type and configuration and the "other" workload on the machine. Many of these factors are highly variable and difficult to predict or simulate.
It is, however, possible to determine what the upper limit for a given box is under ideal circumstances. The readprobe.p tool is designed to determine what this limit is. The probe loads the entire sports database into memory and deliberately does no IO (Remember these are ideal conditions. You'll never go this fast in real life but you should be able to come very close.)
This is useful because if you know that you need to read records faster than this rate in order to meet a requirement then you know you need a faster machine. Suppose, for instance, that you know that a certain process needs to be able to regularly read a price table of 10,000 records in less than 0.5 seconds. You need a machine that can handle 20,000 reads per second in order to meet that requirement. Can your machine do that? (See Investigating Suspicious Code for tips on determining if you really need to read that many records...)
Another example might be a nightly batch process. Suppose that you have a process that is single threaded and which takes 60 minutes to complete. Using readprobe results you can estimate that, at worst, it processes 3600 x N records where N is the peak single user read rate. You can then gauge the impact of multiple threads by examining the read throughput at different "user" load levels and determine the expected impact on runtime of different approaches to parallelizing the process. You can even determine the likely impact of other competing processes on runtime.
In a similar manner you can determine the degree of improvement that can be expected from a server upgrade. Calculate the number of read operations performed during the current run of the process and then determine the amount of time that those operations will require on the new server. This isn't perfect. Processing unrelated to reading records takes place too although it will scale in a very similar manner. A larger source of variation will be from any unbuffered disk IO operations. Even if the disks are upgraded they won't improve as much as the rest of the system so more "windage" needs to be allowed if you know that there will be a substantial IO load.
Even if you don't know what your requirements are it's good to know your limits. If you are near this limit then you are pushing the machine about as hard as it can go and tuning efforts will have a diminishing return (if any). Pushing it harder (increasing the load through more users or more activity) is very likely to result in "unpleasant" performance issues (see the 1,000 user stress test below...)
The data is also useful for determining how well tuned your system is -- if you are achieving results that are close to these ideal numbers then you're out of tuning options. You need faster CPUs to go any faster. But if you are not getting results that are close to these numbers you have room to improve through other changes.
Readprobe doesn't tell you everything about a machine. It shows one very specific metric -- how many records can be read under ideal circumstances. This happens to be a very useful thing to know. But it is not everything that you need to know nor can you make an informed decision based solely on that result. If you would like help applying these lessons to your situation contact Greenfield Technologies today to schedule an appointment!
The following table summarizes the performance leaders in each category:
Greenfield Technologies knowledge of business, applications, and infrastructure helps companies to develop and deploy applications which are built to last and designed to exceed user expectations.
-- Rob Lux
Enterprise Services Manager
Large Global IT Outsourcing Firm
With technology evolving at an increasingly challenging rate, it’s great to have a partner that you trust, and one that you can leverage to help your business take advantage of a constantly changing technology landscape. Greenfield Technologies has been there for us in the past, and will be THE partner we go to in the future when we need in-depth expertise.
-- Todd Lunsford
CIO
Quicken Loans
Greenfield Technologies in depth knowledge of the Progress database and our application made it possible to not only prepare our hardware, operating system and Progress software upgrade to a point that we felt very comfortable to go ahead with it, but also enabled us to execute it in less time than anticipated and resulted in a much larger performance improvement than we expected! Tom’s motto to prepare well and test twice beforehand paid off fully.
-- Gabriela Summerer-Herndon
Unix Admin, Progress DBA
Columbia National Inc.
We just watched! You deserve the credit! Thanks again!
-- Alex Hillman
Thank you for your extraordinary efforts during the past few days. All of us really appreciate it. Given our volume and customer service requirements, your support -- which extended far beyond the normal work day and schedule -- was invaluable.
-- Jenne Britell
Thank you again for going the "extra mile".
-- Ben Smith
Tom, you especially have gone beyond the call of duty in monitoring our system and getting issues regarding capacity etc resolved.
-- Matt White
Great program! Great features!.
-- Scott Cooper
Thank you for your work on the [...] rehosting project. Expediting the conversion of the Progress Database was critical to our success. The knowledge that you brought to the team about Progress tuning and database management helped not only with this effort but will improve our on-going management of the database. Thank you!
-- Anonymous CIO
| Address: |
White Star Software PO Box 3058 Nashua, NH 03061 |
| Cell: | +1 603 396 4886 |
| E-mail: | mailwss.com |
| wss.com | |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
