Comments 10
Здравствуйте!
Подскажите, пожалуйста, а насколько применимы вышеописанные оптимизации к Azure SQL Server?
Мы на работе используем CI и клонируем базу с продакшена для прогонки интеграционных тестов. Возможен ли выигрыш в скорости, если вместо клонирования мы будем копировать туда данные?
Я сам не очень разбираюсь в SQL, так что прошу прощения если вопрос глупый
Подскажите, пожалуйста, а насколько применимы вышеописанные оптимизации к Azure SQL Server?
Мы на работе используем CI и клонируем базу с продакшена для прогонки интеграционных тестов. Возможен ли выигрыш в скорости, если вместо клонирования мы будем копировать туда данные?
Я сам не очень разбираюсь в SQL, так что прошу прощения если вопрос глупый
применимы вышеописанные оптимизации к Azure SQL Server?
Azure SQL Database поддерживает возможность включения Delayed Durability (хотя SSMS в свойствах базы соответствующей опции не показывает)
если вместо клонирования мы будем копировать туда данные?
Сложно ответить на Ваш вопрос не зная специфики проекта и то как разворачивается тестовое окружение. Если уточните вопрос, то буду рад помочь.
Мне тесты достались тоже с кучей DELETE. После каждого TestCase данные удалялись «вручную». от этого все тесты рано или поздно ломались, если кто-то не все удалял за собой. Потому я переделал все на rollback до save point-а, до которого создавались таблички и минимальные данные.
А после того как поменял у себя в проекте DB2 на HSQLDB — юниттесты работающие с базой (в проекте каша с доступом к базе) ускорились с пары часов до 3 минут. Создание базы и наполнение данными происходит за секунду. Пришлось конечно SQL запросы, которые использовали DB2 фишки переписать на стандартный SQL понятный HSQLDB. Что не получилось переписать, я правлю в своем JDBC драйвере (к примеру заменяю «for update rs lock» на просто " for update").
Зато теперь юниттесты можно прогнать перед коммитом и убедиться, что ничего не поломалось. А не через пару часов после коммита, когда уже другими делами занялся.
А после того как поменял у себя в проекте DB2 на HSQLDB — юниттесты работающие с базой (в проекте каша с доступом к базе) ускорились с пары часов до 3 минут. Создание базы и наполнение данными происходит за секунду. Пришлось конечно SQL запросы, которые использовали DB2 фишки переписать на стандартный SQL понятный HSQLDB. Что не получилось переписать, я правлю в своем JDBC драйвере (к примеру заменяю «for update rs lock» на просто " for update").
Зато теперь юниттесты можно прогнать перед коммитом и убедиться, что ничего не поломалось. А не через пару часов после коммита, когда уже другими делами занялся.
По первой части — а не проще было сделать снапшот БД и после прогона тестов откатываться к снапшоту вместо ручной зачистки и сброса IDENTITY? Вроде бы снапшот для таких целей и был создан. Правда, у него есть существенный недостаток — требует Enterprise Edition, ну или Developer Edition, что в данном кейсе должно подойти — насколько я понял, тесты запускаются на машинах разработчиков.
Хммм, я думал SSD на компах разработчиков это уже несколько лет как стандарт индустрии.
Может кому прингодится.
Я у себя реализовал тестирование для MSSQL варианта след. образом:
* На тестовых Агентах стоит RAM Drive от ImDisk (2GB).
* Используется вариант LOCALDB, просто создается база на RAM драйве и заливаются исходные данные.
* Перед каждым тестом стартует транзакция (наш слой доступа к DB при етом не позволит сделать в теле теста Commit или Rollback)
* После теста делается Rollback.
Я у себя реализовал тестирование для MSSQL варианта след. образом:
* На тестовых Агентах стоит RAM Drive от ImDisk (2GB).
* Используется вариант LOCALDB, просто создается база на RAM драйве и заливаются исходные данные.
* Перед каждым тестом стартует транзакция (наш слой доступа к DB при етом не позволит сделать в теле теста Commit или Rollback)
* После теста делается Rollback.
Спасибо!
Sign up to leave a comment.
Delayed Durability или история о том как получилось ускорить выполнение автотестов с 11 до 2,5 минут