Hello, Karabas!
Karabas Barabas wrote:
Кстати, тест последовательного чтения/записи опять же некорректен ... ведь все процессы в тесте стартуют одновременно практически,
> т.о. читают/пишут один и тот же кусок файла ... наверное надо их с задержкой запускать ? прямо как при tpc-r - опять выводы идут не в ту сторону. 1. есть дисковая подсистема, которая обладает определенной РЕАЛЬНОЙ производительностью. 2. есть тест, который меряет производительность этой системы тестом, примерно напоминающим ОДНОПОЛЬЗОВАТЕЛЬСКУЮ работу с БД. 3. тест позволяет "померять" дисковую систему относительно других. то есть, я не вижу АБСОЛЮТНО никакой причины начинать подгонять тест под максимальную имитацию работы с базой IB/FB. Более того, я ж с самого начала сказал - тест и файл-то открывает в режиме no_buffering, чего ни IB ни FB НЕ ДЕЛАЮТ. Конечно, интересно сравнить многопользовательскую работу в SS/CS на конкретном диске, и таки выяснить, что же лучше - IDE, SATA или SCSI :-), но даже на этом этапе надо четко определиться, что будет представлять собой тест, то есть, что именно он будет тестировать. Включать-ли файловое кэширование виндов. Какими "блоками" делать seq read, и т.п. Все это выходит за рамки исходной задачи, и что самое печальное - я не вижу смысла в таком тесте. Было бы более полезно сделать или взять за основу какой-нибудь тест именно как ТЕСТ СЕРВЕРА - заливаем базу, выполняем запросы. Тогда уже можно было бы не просто "меряться цифрами", а попытаться а) сконфигурировать сервер IB/FB на максимальную производительность под конкретный тестовый паттерн б) использовать этот тест для повышения производительности кода IB/FB. Да и то, в отношении пункта а - в реальных условиях производительность системы определяется же не только крутостью сервера, а в основном приложениями - что они делают (какие запросы), какой трафик в сети, как идет управление транзакциями (мусор, свип), и т.д. И эти параметры находятся очень далеко от чистой производительности жесткого диска. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
