Доклад Сергея Михалева на SQA Days-15. 18-19 апреля, 2014, Москва. www.sqadays.com

1. Подход
Доктора Хауса к
тестированию
оптимизации
запросов
(пятая серия)
Автор: Михалев Сергей
f1incode.com

2. Это я 
Team Lead / Software
Developer in VIAcode
www.linkedin.com/in/ssmikhalev
vk.com/ssmikhalev
ssmikhalev@gmail.com
f1incode.com

3. У вас есть отличная команда
Но не докторов, а программистов,
которые занимаются оптимизацией
вашего приложения.

4. Воскресенье
Только они думают:
“Какого черта стакан
в два раза
больше, чем нужно!”

Все-таки
тестировщики
особенные
люди.
Почему?!

5. Я думаю, из
меня выйдет
хороший
тестировщик.
Я
замечательно
умею всё
ломать!
Лучше
занимайся
своим
делом!

6. Понедельник: на этой неделе я буду
тестировщиком

7. Понедельник
На этой недели я
буду
тестировщиком!
Понедельник

8. Понедельник Ладно, разбирайт
есь сами. Вот вам
новый кейс!
И постарайтесь
сделать
так, чтобы Хаус
ничего не нашел!

9. Анализ кейса: дифференциальный
анализ
У нас серьезно
замедлилась
страница
диагнозов.
Возможно, д
ело в
функции
list_diagnosis

10. Понедельник: подготовка к тестированию
Нужна серьезная подготовка к тестированию
производительности …

11. Обработка запросов
Запрос
1. Разбирает запрос
2. Оценивает окружение
3. Анализирует
распределение данных
4. Строит эффективный
план запроса
5. Выполняет запрос
Данные
Вывод: оптимизация очень сильно зависит от
конкретных условий выполнения.

12. Подготовка к тестированию
производительности запросов
Цель – быть как можно “ближе” к реальному
окружению.
Необходимо:
1. Проконтролировать одинаковость
тестового и реального окружений.
2. Сверить совпадение схем баз данных.
3. Собрать достаточное количество реальных
запросов.
4. Подготовить процесс запуска запросов и
сбора метрик.

13. Подготовка: 1 - тестовое окружение
Необходимо проверить:
1. Что тестовый сервер как можно ближе к
“реальному”: CPU, жесткий диск, RAID-
ы, оперативная память.
2. Совпадение операционных
систем, обновлений.
3. Настройки СУБД: версия, сколько памяти
выделено, на какие диски смонтированы базы, collation-
ы.

14. Подготовка: 2 - база данных
1. Проверить совпадение схем баз данных:
одинаковость
индексов, функций, статистики, collation.
2. Данные должны быть близкие к реальным.
Нет никакого смысла тестировать производительность
запросов на тестовых (смоделированных) данных.

15. Подготовка: 3 - запросы
Запрос
Запрос
1. Необходимо использовать только запросы
от реальных пользователей.
2. Количество запросов должно быть
достаточным.

16. Подготовка: 4 - процесс запуска
Цель - получать контролируемые результаты
для их дальнейшего анализа.
Необходимо создавать как можно более
стабильную из теста в тест нагрузку. Поэтому
важно контролировать:
1. Порядок запуска запросов (иначе возможны
серьезные расхождения в результатах из-за
разных закешированных планов запроса).
2. Создаваемую нагрузку (количество
параллельно запускаемых запросов).

17. Выводы
1. Обязательно контролировать, что тестируемые
сервера обладают сравнимой с продакшеном
производительностью.
2. Нет большого смысла тестировать
оптимизацию на смоделированных данных.
3. Необходимо стремиться воспроизводить как
можно более похожую на реальную нагрузку.
4. Если вы проигнорировали или не обеспечили
хотя бы один из подготовительных шагов –
вашим тестам нельзя доверять.

18. Вечер понедельника
Всё ли я
предусмотрел?
Всё ли
подготовил?

19. Вторник
Мы
исправили
кейс!!
Стало
быстрее в
10раз!!

20. Реакция Хауса

21. Особенно программисты 
Поэтому ВСЁ нужно перепроверять.

22. Экспресс анализ изменений
Старая функция Новая функция

23. Запускаем
тестовые трейсы
запросов

24. Анализ результатов: метрики
1. Время выполнения запроса.
2. Количество логических чтений.
3. Время СУБД на обработку запроса.
4. Количество памяти, выделенное на
обработку запроса.

25. Анализ результатов

26. Анализ результатов: распределение
по времени выполнения.
Главный пик сместился, т.е
большинство запросов
стало быстрее.
Но появился новый
пик, которого раньше не

27. Возвращаем кейс

28. Выводы
1. Практически невозможно оптимизировать
запрос так, чтобы не замедлить что-то
другое.
2. Обычно нет проблем оптимизировать один
проблемный запрос. Наибольшая сложность
- оптимизировать весь набор запросов.
3. Поэтому - чем более универсальный
запрос, тем он медленнее!
4. Это первый из “балансов”. Можно
оптимизировать какой-то конкретный
запрос за счет других.

29. Вечер вторника

30. Среда
Идет активная работа.
И только
тестировщик
Хаус в это время …

31. Среда
Команда находит и представляет
новое решение.

32. Экспресс анализ изменений
Старая функция Новая функция
Куда исчезла логика?

33. Экспресс анализ изменений
create view dbo.v_diagnosis_clustered
with schemabinding as
select g.diagnosis_id, g.patient_id,
g.desease_name, g.create_time,
d.doctor_id, d.hospital_id, d.doctor_name
from DIAGNOSIS g
inner join DOCTOR d
on g.doctor_id = d.doctor_id
select …
from PATIENT p
cross apply
(
select top 1 desease_name, doctor_name
from V_DIAGNOSIS_CLUSTERED g
where g.patient_id = p.patient_id
and g.hospital_id = @hospital_id
order by g.create_time
) d
select …
from PATIENT p
cross apply
(
select top 1 desease_name, doctor_name
from DIAGNOSIS g
inner join DOCTOR d
on g.doctor_id = d.doctor_id
where g.patient_id = p.patient_id
and d.hospital_id = @hospital_id
order by g.create_time
) d
create unique clustered index clustered_index
on dbo.v_diagnosis_clustered
(hospital_id, patient_id)
Старая версия Новая версия

34. View vs Indexed View
1. Виртуальная
(логическая)
таблица, представляюща
я собой поименованный
запрос.
2. Физически данные не
хранятся. SELECT
вычисляется каждый
раз, когда к нему
обращаются.
View Indexed View
1. Представление, на
котором создан
кластерный индекс.
2. Физически данные
хранятся, как и в
обычной таблице.

35. Баланс скорости чтения и скорости
модификаций
1. Кластерное представление будет
пересчитываться при каждой модификации
исходных таблиц.
2. Модификация станет медленнее, а
чтение, скорее всего, быстрее.
3. Баланс №2 – оптимизация скорости чтения
за счет скорости модификаций или
наоборот.

36. Анализ результатов: чтений

37. Анализ результатов: модификаций

38. Анализ результатов
Выносить
или нет …

39. Еще разок …
Намного
лучше. А
можно сделать
еще лучше?

40. Выводы
1. Наиболее важный баланс в оптимизации
запросов – это баланс скорости чтений и
скорости модификаций.
2. Практически всегда можно ускорить
чтения, замедлив соответствующие
изменения данных.
3. Принимать решения о приемлемости такой
оптимизации необходимо, основываясь на
знаниях о приложении.

41. Четверг
Опять идет активная работа

42. Четверг
Новое решение …

43. Экспресс анализ изменений
Старая функция Новая функция
Они
одинаковые!!!
Значит, измен
илась схема
базы!!!
Индексы?!

44. Индексы: куча
extent
IndexAllocationMap
extent
extent
create table DOCTOR
(
doctor_id int identity(1,1) not null,
hospital_id int not null,
first_name nvarchar(50) not null,
last_name nvarchar(50) not null,
create_time datetime not null
)
Так как нет кластерного
индекса, очевидно, что
данные в куче
неупорядоченные.
Table Scan
Table Scan
Table Scan

45. Индексы: кластерный индекс
ALTER TABLE DOCTOR
ADD CONSTRAINT PK_DOCTOR
PRIMARY KEY CLUSTERED
(
doctor_id asc
)
Data Rows
264 …
… …
312 …
Data Rows
210 …
… …
263 …
Data Rows
157 …
… …
209 …
Data Rows
104 …
… …
156 …
Data Rows
53 …
… …
103 …
Data Rows
1 …
… …
52 …
Index Rows
157
210
264
Index Rows
1
53
104
Index Rows
1
157
Root
Intermediate Level
Leaf / Data Level
На листовых уровнях хранятся
значения всех столбцов
Определяет физический порядок
даных, поэтому может быть
создан только однин кластерный
индекс на таблице
Все индексы
организованы
как B-Tree

46. CREATE NONCLUSTERED INDEX IX_HOSPITAL
ON DOCTOR
(
hospital_id
)
Data Rows
264 …
… …
312 …
Data Rows
210 …
… …
263 …
Data Rows
157 …
… …
209 …
Data Rows
104 …
… …
156 …
Data Rows
53 …
… …
103 …
Data Rows
1 …
… …
52 …
Root
Intermediate
Level
Leaf Level
Index Rows
1
25
Index Rows
51
75
Index Rows
1
51
Index Rows
1
…
24
1
...
104
Index Rows
25
…
50
100
...
209
Index Rows
51
…
74
106
...
202
Index Rows
75
…
83
264
...
210
ClusteredIndex
Тоже организован как B-Tree
Не задает физический
порядок хранения данных
в таблице, а сортирует
данные в каком-то порядке
Содержит копии
данных из таблицы
На листовом уровне
содержатся ссылки на
кластерный индекс
Индексы: некластерный индекс

47. Представляйте себе книгу
Кластерный
индекс – это
номера
страниц в
книге.
Некластерный
индекс – это
предметный
указатель.

48. Анализ результатов: добавление
индексов

49. Анализ результатов: добавление
индексов - модификация

50. Выводы
1. Изменения индексов – наиболее
популярный и простой способ
оптимизации.
2. Индексы, как и кластерные
представления, замедляют операции
модификации.
3. Обычно функциональное тестирование
не требуется.

51. Пятница
Совместный анализ всех
результатов

52. Анализ результатов
Выросший
максимум
Скорость функции
Скорость модификаций

53. Выносим изменения

54. Выводы
1. Для любой задачи существует несколько
путей и подходов оптимизации.
2. Оптимизация запросов – это всегда
вопрос баланса, поэтому задача
тестирования - правильно выявить этот
баланс.
3. Выбор того или иного решения всегда
зависит от специфики приложения.

55. Выводы недели
1. Подготовка к тестированию – самый
важный этап. Если вы проигнорировали хотя
бы один из подготовительных шагов – вашим
тестам нельзя доверять.
2. Оптимизация – это вопрос баланса:
• оптимизация какого-то конкретного
запроса за счет других;
• оптимизация чтений за счет
модификаций;
3. Поэтому почти всегда можно найти, что в
действительности стало медленнее.

56. Молодцы!!!

57. Помощь
Командная работа или тестировщиков
нужно всегда поддерживать!!!

58. Подводим итоги недели
1) Разобрались с операциями над
множествами, такими как except и
union. И даже реализовали except all.
2) Мы разработали метод
функционального тестирования
запросов.
3) Нашли очень замысловатую
логическую ошибку и исправили
старый функциональный баг.
Подход Доктора Хауса к тестированию
оптимизации запросов
1. Разбираться в
проблеме до конца.
2. Быть одной
командой.
3. Все врут, а значит -
всё нужно
перепроверять.
4. Не бояться резать по
живому, но всегда
контролировать.
5. Не сдаваться!!!

59. Вопросы?
Team Lead / Software
Developer in VIAcode
www.linkedin.com/in/ssmikhalev
vk.com/ssmikhalev
ssmikhalev@gmail.com
f1incode.com