|
arniЕсть желание потестить влияние на скорость исполнения настроек сервера и базы: page size, page cache etc.
Реализовать не проблема, но не хочется изобретать велосипед. Нет ли готового money free решения, в котором можно было бы:
- указать файл БД (или несколько файлов, отресторенных с разным page size);
- указать перечень целевых величин page cache и, быть может, других "ручек", за которые можно подергать;
- указать команды для снятия бенчмарков в прямом виде (execute procedure или execute block), либо ссылки на скрипты, как в isql -i;
В итоге чтобы оно запускало все эти комбинации, снимало статистику, писало в какой-то формат, пригодный для импорта в Excel. Желательно, чтобы оно гоняло одни и теже тесты несколько раз, пропускало первый проход, когда "прогревается кеш", а остальные усредняла.
Такой софт есть?Есть что-то типа "каркаса", который создавался для имитации OLTP-нагрузки и проведения сравнительных тестов. Это батник и несколько .sql-скриптов.
Вот что он делает:
0) читает обычный текстовый файл-конфигурацию, в которой указаны хост/порт:база, а также параметры самого теста:
0.1) до какого числа документов довести базу, прежде чем начать запуски прикладных ХП,
0.2) сколько времени разогревать базу (т.е. просто вызывать прикладные ХП, но не учитывать время их работы в итоговом отчете),
0.3) сколько времени должны молотить ISQL'и (остановка по истечении этого времени будет выполнена автоматически);
0.4) вести ли "расширенное логирование" произв-сти с пом. mon$-таблиц (актуально только для ФБ-3);
1) создает (при необходимости) тестовую базу и все объекты в ней: таблицы, ХП и прочая;
2) (до-)заполняет тестовую базу тем кол-вом документов, которые указаны в конфиге;
3) (пере-)создает (при необходимости) большой SQL-скрипт, который будет скармливаться сеансам-молотилкам;
4) запускает то число окон, которое указано в аргументе командной строки его запуска;
5) заставляет *первое* из запущенных окон составить отчет и выкинуть его в текст. Отчет этот содержит:
5.1) данные mon$database ==>там будет видно page_size, page_buffers, forced_writes etc;
5.2) сводные данные о произв-сти: сколько всего вызовов прикладных модулей успешно завершились за заданный интервал работы;
5.3) данные об изменении произв-сти "в динамике", деление на 10 интервалов (но это число легко изменить) - т.е. "как уставал Firebird", пока шёл тест.
В планах еще было научить его вытряхивать вообще весь конфиг с сервака, с пом. fbsvcmgr'a, и также сохранять куда-нить. Но это доступно только в ФБ-3, к сож-ю.
Ну, а дальше уже надо руками работать: сохранить куда-то файл с отчетом, или вытряхнуть его в эксель и проч.
Теперь о том, как это можно применить у тебя.
Батник генерит sql-скрипт, который лезет в одну важную табличку с именем 'business_operations'. Эта табличка содержит перечень тех ХП, которые считаются top-level, т.е. это точки входа в "бизнес-операции". ХП выбираются именно этим батником.
Если выкинуть из business_operations всё, кроме твоей ХП, то молотилки будут вызывать только одну твою ХП.
Если добавить в начало и конец твоей ХП несложный код, выполняющий логирование времени её работы (по образу того, что сейчас есть в остальных ХП: он просто пишет два момента времени в базу, причём независимо от того, завалилась ХП по эксепшену или нет), - то ты получишь в итоге сведения о том, сколько эта ХП выполнялась.
Ключевой момент тут - сможешь ли ты вкрячить свою ХП и все объекты с данными, от которых она зависит, в эту тестоую базу. Или наоборот - все объекты тестовой базы перетащить в твою БД. Ну а если сможешь еще и на ФБ-3 это всё запустить, будет вообще шоколад: там есть замечательная табличка mon$table_stats, которая тебе о-очень поможет в отлове узких мест.
|
