Тестирование пользовательской производительности решения ORM наверху - как к?

Question

Тестирование пользовательской производительности решения ORM наверху - как к?

Я создал прототип пользовательского инструмента ORM с помощью аспектно-ориентированного программирования (Пострезкое) и достигающее незнание персистентности (перед временем компиляции). Теперь я пытался узнать, сколько наверху делает это представляет по сравнению с использованием чистого DataReader и ADO.NET. Я сделал тестовый сценарий - вставляют, читают, удаляют данные (приблизительно 1 000 записей) в SQL Server MS 2008 и MySQL Community Edition. Я запускаю этот тест многократно с помощью чистого ADO.NET и моего инструмента пользователя.

Я ожидал, что результаты будут зависеть от многих факторов - память, свопинг, ЦП, другие процессы, таким образом, я запускал тесты для много раз (20-40). Но результаты были действительно неожиданны. Они просто отличались слишком много между теми случаями. Если бы были только некоторые экстремумы, то я мог бы проигнорировать их (возможно, свопинг произошел или что-то как этот), но они так отличались, что я уверен, что не могу доверять этому виду тестирования. Почти половина времен, которые мой ORM показал на 10% лучшей производительности, чем чистый ADO.NET, другие времена, это были-10%.

Есть ли какой-либо способ, которым я могу сделать те тесты надежными? У меня нет мощного компьютера с большой памятью, но возможно я так или иначе могу сделать MS SQL и MySQL или ADO.NET, чтобы быть максимально последовательным во время тех тестов? Как насчет количества записей - который более надежен, с помощью небольшого количества записей и работая больше раз или другого пути?

6

sql-server performance testing orm ado.net

задан JustAMartin 30 December 2009 в 21:23

3 ответа

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

Также убедитесь, что в файле базы данных и лог-файле выделено достаточно свободного места, чтобы вы не ждали, пока БД отрастит файл во время определенных тестов.

.

3

ответ дан 9 December 2019 в 22:35

Прежде всего, необходимо выяснить, откуда взялась эта дисперсия. Сам слой ORM или БД?

Во многих случаях источником такой дисперсии является сама БД. Базы данных - очень сложные системы, внутри которых много активных процессов, которые могут взаимодействовать с результатами измерений производительности. Чтобы достичь некоторых воспроизводимых результатов, вам нужно поместить базу данных в "лабораторные" условия и убедиться, что ничего неожиданного не случится. что это значит, зависит от поставщика, и вам нужно знать некоторые довольно продвинутые темы, чтобы поставить на карту что-то подобное. Например, в базе данных SQL Server типичными источниками вариаций являются:

cold cache vs. warm cache (как данные, так и процедуры)
log and database growth events
maintenance jobs
ghost cleanup
lazy writeer
checkpoints
external memory pressure

2

ответ дан 9 December 2019 в 22:35

Другие вопросы по тегам:

sql-server performance testing orm ado.net

Похожие вопросы:

score 6 · Accepted Answer

Вы видели ORMBattle.NET ? Смотрите FAQ там , есть некоторые идеи, связанные с измерением накладных расходов , введенные конкретным инструментом ORM. Тестовый набор - с открытым исходным кодом .

Что касается ваших результатов:

Некоторые инструменты ORM автоматически выполняют пакетные последовательности операторов (т.е. посылают несколько SQL-запросов вместе). Если эта функция хорошо реализована в ORM, то легко обойти простой ADO.NET в 2-4 раза при выполнении операций CRUD, если в ADO.NET тест не предусматривает пакетную обработку. Тесты на ORMBattle.NET тестируют в обоих случаях.
Многое зависит от того, как вы устанавливаете там границы транзакций. Пожалуйста, обратитесь к ORMBattle.NET FAQ для получения более подробной информации.
CRUD-тесты вообще не являются лучшим индикатором производительности. В общем, довольно легко получить Пиковая возможная производительность здесь, так как в целом СУБД в этом случае должна делать гораздо больше, чем ОРМ.

P.S. Я один из авторов ORMBattle.NET, поэтому если вас интересуют подробности / возможный вклад, вы можете связаться со мной напрямую (или присоединиться к ORMBattle.NET Google Groups).

.