Pull to refresh

Comments 8

После того, как заказчик стал видеть графики, он стал более спокойным: он видел прогресс.

Не верю. Либо вы делали что-то еще, либо заказчик наблюдал увеличение производительности\снижение жалоб от сотрудников\более удобный UI.
А вот сбор статистики — дело полезное. Особенно, если заказчик чувствует, что статистика коррелирует с работой программы.

да, мы еще некоторые вещи делали. Но и графики в том числе, которые акцентировали внимание, что все хорошо. Тут получался дополнительный эффект от того, что мы выбирали характеристики измерения правильно (в абсолютном большинстве случаев) и это уходило в нашу «копилку» характеристик, которые мониторим. И так же величины становились измеримыми.
Одно из самых эффективных средств – собирать счетчики производительности с интервалом в неделю. Счетчиков реально много, они дают хорошие графики, их можно экспортировать в Excel, производить анализ и т.д. Жалко только, что мы не делали это с самого начала, когда было 5000 работ в неделю.

Также плюсом этого подхода является то, что заказчика очень легко уговорить на это – это встроенная возможность Windows, поэтому уговаривать даже почти не пришлось на запуск сбора статистики.


О чём речь? Где поподробнее про такие счётчики почитать?
Реализация этой программы заняла примерно 3 дня. После этого была создана копия живой БД, которая подверглась анонимизации

Не учли, что она будет долгой (как оказалась, чистое время анонимизации было около 5 дней). Анонимизация создавала доп. нагрузку на тот же самый физический диск, на котором была живая БД, что создало проблемы.

Вы не рассматривали возможность использовать уже готовые тулы для такого рода задач? Скопировать схему с продакшена и сгенерировать данные любым дата генератором (например, dbForge Data Generator)… это дело нескольких часов (в зависимости от размера БД и производительности сервера).

К слову будет сказано, недавно игрался с SQL Server 2016… Почитайте про новые фишки вроде Dynamic Data Masking и Always Encrypted. В Вашем случае они были бы полезны.

очередь с 400 работ

Это в контексте SQL Server Вы имели ввиду… или это термин бизнес-логики Вашего приложения?

попробовать перевести базу данных в snapshot mode. Неожиданно это дало необычайно хорошие результаты

Результаты может быть и хорошие, но нужно знать и об обратной стороне медали. Вот несколько статей в тему:
nickberardi.com/deadlocked-read-committed-snapshot-explained
sqlblog.com/blogs/alexander_kuznetsov/archive/2011/08/02/reads-involving-udfs-under-read-committed-snapshot-may-seem-inconsistent.aspx
используемая версия MS SQL 2008 или 2012. Что касается других инструментов генерации тестовых данных — основная проблема в том, что в то время мы не полностью понимали статистику распределения, это было в начале проекта. Поэтому нас интересовала исследовательская часть по нахождению этих правил. Из-за этого правила распределения были бы не верными при генерации тестовых данных.

400 работ — термин бизнес-логики. Работа — совокупность данных об одном пациенте (визите)
Спасибо за статью. Очень интересно и легко читается. И нашел подсказку для решения пары своих проблем :)
После недельного анализа мы решили попробовать перевести базу данных в snapshot mode. Неожиданно это дало необычайно хорошие результаты – очередь с 400 работ сократилась до 12 работ (но это уже было в пределах нормы).

Выводы, которые мы сделали по этой проблеме: в дополнение к созданию индексов не надо забывать о таком механизме, который есть в MS SQL

Интересно, а почему это не используется по умолчанию?
Практически любой разработчик, имевший дело с изначально версионными серверами (Oracle, Firebird), даже не пытается использовать MS SQL в режиме блокировщика.
Однако не в первый раз вижу, что узким специалистам по MS SQL это не только не приходит в голову сразу, но еще и удивляет результатами, хотя в случае гарантий неблокирующего чтения эффект для всякого рода расчетов и отчетов немного предсказуем.
Sign up to leave a comment.