Что я должен учитывать при тестировании производительности чтения и записи DB2?

Question

Обзвон всех парней из базы данных ...

Ситуация такая: У меня есть база данных DB2, в которую пишут и читают. Мне нужно провести тестирование производительности на программно выполненных операциях чтения / записи.

Я знаю, как написать программу для чтения / записи в эту базу данных, но я не уверен, какие факторы я должен учитывать в своем тесте производительности.

Нужно ли беспокоиться о разнице между чтением / записью одного сеанса и несколькими сеансами?

Как лучше всего взаимодействовать с самой DB2, чтобы узнать, сколько времени занимают эти выполнения?

Процесс, который я тестирую, в основном похож на непрерывный пакетный процесс, постоянно принимающий сообщения и сохраняющий их. Вероятно, в один и тот же момент времени в БД будет только один или два сеанса макс.

Действительно ли время, необходимое для чтения / записи, является наилучшим показателем?

Я уверен, что существует множество инструментов для такого рода тестирования. Любой совет приветствуется.

Дополнительная информация:

Одна вещь, которую я рассматриваю, состоит в том, чтобы попытаться запустить X число операций чтения / записи с моим API базы данных (homebrew) и попытаться «рассчитать», сколько времени это займет. К сожалению, DB2 буферизует эти сообщения. Есть ли способ заставить DB2 сделать обратный вызов, когда это делается с помощью чтения / записи? Или каким-то образом измерить время, которое занимают эти операции? (инструмент и т. д.)

Answer 1

Одним из важнейших факторов производительности DB2 является конфигурация буферных пулов. например http://www.ibm.com/developerworks/data/library/techarticle/0212wieser/0212wieser.html

Answer 2

Какова цель вашего тестирования производительности ?. Это тестирование производительности для одновременных пользователей или тестирование загрузки для пакетного процесса. На основании этого есть инструменты, доступные для проверки этого. Вы можете посмотреть Jmeter от Apache.

В этом случае вам может потребоваться запустить несколько параллельных процессов, чтобы симулировать CRUD-данные и отслеживать активность с помощью эксперта по производительности или чего-то подобного. В то время как вы делаете это, вы можете использовать больший вывод, чтобы вы могли найти любые узкие места с большими наборами данных. Поищите настройку производительности на сайте IBM Redbooks, и вы найдете несколько примеров для этого.