Delayed Durability или история о том как получилось ускорить выполнение автотестов с 11 до 2,5 минут

[netaholic]

Здравствуйте!
Подскажите, пожалуйста, а насколько применимы вышеописанные оптимизации к Azure SQL Server?
Мы на работе используем CI и клонируем базу с продакшена для прогонки интеграционных тестов. Возможен ли выигрыш в скорости, если вместо клонирования мы будем копировать туда данные?
Я сам не очень разбираюсь в SQL, так что прошу прощения если вопрос глупый

[AlanDenton]

применимы вышеописанные оптимизации к Azure SQL Server?

Azure SQL Database поддерживает возможность включения Delayed Durability (хотя SSMS в свойствах базы соответствующей опции не показывает)

если вместо клонирования мы будем копировать туда данные?

Сложно ответить на Ваш вопрос не зная специфики проекта и то как разворачивается тестовое окружение. Если уточните вопрос, то буду рад помочь.

[gsaw]

Мне тесты достались тоже с кучей DELETE. После каждого TestCase данные удалялись «вручную». от этого все тесты рано или поздно ломались, если кто-то не все удалял за собой. Потому я переделал все на rollback до save point-а, до которого создавались таблички и минимальные данные.

А после того как поменял у себя в проекте DB2 на HSQLDB — юниттесты работающие с базой (в проекте каша с доступом к базе) ускорились с пары часов до 3 минут. Создание базы и наполнение данными происходит за секунду. Пришлось конечно SQL запросы, которые использовали DB2 фишки переписать на стандартный SQL понятный HSQLDB. Что не получилось переписать, я правлю в своем JDBC драйвере (к примеру заменяю «for update rs lock» на просто " for update").

Зато теперь юниттесты можно прогнать перед коммитом и убедиться, что ничего не поломалось. А не через пару часов после коммита, когда уже другими делами занялся.

[minamoto]

По первой части — а не проще было сделать снапшот БД и после прогона тестов откатываться к снапшоту вместо ручной зачистки и сброса IDENTITY? Вроде бы снапшот для таких целей и был создан. Правда, у него есть существенный недостаток — требует Enterprise Edition, ну или Developer Edition, что в данном кейсе должно подойти — насколько я понял, тесты запускаются на машинах разработчиков.

[AlanDenton]

Такой вариант уже рассматривали. К слову он лучше на порядок, но сейчас все на Express работает и этого вполне хватает. В планах миграция, когда пользователей TMetric больше станет.

[minamoto]

Можно уже сейчас реализовать с проверкой доступности фичи — если доступна — использовать ее, если нет — старый способ :)

[niq]

Хммм, я думал SSD на компах разработчиков это уже несколько лет как стандарт индустрии.

[tsabir]

тупо переход на SSD ускорит WRITELOG примерно в 2 раза, так как характер записи последовательный. А автор ускорил тесты в 4 раза.

[trantor1]

Может кому прингодится.

Я у себя реализовал тестирование для MSSQL варианта след. образом:

* На тестовых Агентах стоит RAM Drive от ImDisk (2GB).
* Используется вариант LOCALDB, просто создается база на RAM драйве и заливаются исходные данные.
* Перед каждым тестом стартует транзакция (наш слой доступа к DB при етом не позволит сделать в теле теста Commit или Rollback)
* После теста делается Rollback.

[shurupkirov]

Спасибо!