Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Подход доктора Хауса в тестировании оптимизации запросов (5 серия)

3,537 views

Published on

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

Published in: Education
  • Be the first to comment

Подход доктора Хауса в тестировании оптимизации запросов (5 серия)

  1. 1. Подход Доктора Хауса к тестированию оптимизации запросов (пятая серия) Автор: Михалев Сергей f1incode.com
  2. 2. Это я  Team Lead / Software Developer in VIAcode www.linkedin.com/in/ssmikhalev vk.com/ssmikhalev ssmikhalev@gmail.com f1incode.com
  3. 3. У вас есть отличная команда Но не докторов, а программистов, которые занимаются оптимизацией вашего приложения.
  4. 4. Воскресенье Только они думают: “Какого черта стакан в два раза больше, чем нужно!”  Все-таки тестировщики особенные люди. Почему?!
  5. 5. Я думаю, из меня выйдет хороший тестировщик. Я замечательно умею всё ломать! Лучше занимайся своим делом!
  6. 6. Понедельник: на этой неделе я буду тестировщиком
  7. 7. Понедельник На этой недели я буду тестировщиком! Понедельник
  8. 8. Понедельник Ладно, разбирайт есь сами. Вот вам новый кейс! И постарайтесь сделать так, чтобы Хаус ничего не нашел!
  9. 9. Анализ кейса: дифференциальный анализ У нас серьезно замедлилась страница диагнозов. Возможно, д ело в функции list_diagnosis
  10. 10. Понедельник: подготовка к тестированию Нужна серьезная подготовка к тестированию производительности …
  11. 11. Обработка запросов Запрос 1. Разбирает запрос 2. Оценивает окружение 3. Анализирует распределение данных 4. Строит эффективный план запроса 5. Выполняет запрос Данные Вывод: оптимизация очень сильно зависит от конкретных условий выполнения.
  12. 12. Подготовка к тестированию производительности запросов Цель – быть как можно “ближе” к реальному окружению. Необходимо: 1. Проконтролировать одинаковость тестового и реального окружений. 2. Сверить совпадение схем баз данных. 3. Собрать достаточное количество реальных запросов. 4. Подготовить процесс запуска запросов и сбора метрик.
  13. 13. Подготовка: 1 - тестовое окружение Необходимо проверить: 1. Что тестовый сервер как можно ближе к “реальному”: CPU, жесткий диск, RAID- ы, оперативная память. 2. Совпадение операционных систем, обновлений. 3. Настройки СУБД: версия, сколько памяти выделено, на какие диски смонтированы базы, collation- ы.
  14. 14. Подготовка: 2 - база данных 1. Проверить совпадение схем баз данных: одинаковость индексов, функций, статистики, collation. 2. Данные должны быть близкие к реальным. Нет никакого смысла тестировать производительность запросов на тестовых (смоделированных) данных.
  15. 15. Подготовка: 3 - запросы Запрос Запрос 1. Необходимо использовать только запросы от реальных пользователей. 2. Количество запросов должно быть достаточным.
  16. 16. Подготовка: 4 - процесс запуска Цель - получать контролируемые результаты для их дальнейшего анализа. Необходимо создавать как можно более стабильную из теста в тест нагрузку. Поэтому важно контролировать: 1. Порядок запуска запросов (иначе возможны серьезные расхождения в результатах из-за разных закешированных планов запроса). 2. Создаваемую нагрузку (количество параллельно запускаемых запросов).
  17. 17. Выводы 1. Обязательно контролировать, что тестируемые сервера обладают сравнимой с продакшеном производительностью. 2. Нет большого смысла тестировать оптимизацию на смоделированных данных. 3. Необходимо стремиться воспроизводить как можно более похожую на реальную нагрузку. 4. Если вы проигнорировали или не обеспечили хотя бы один из подготовительных шагов – вашим тестам нельзя доверять.
  18. 18. Вечер понедельника Всё ли я предусмотрел? Всё ли подготовил?
  19. 19. Вторник Мы исправили кейс!! Стало быстрее в 10раз!!
  20. 20. Реакция Хауса
  21. 21. Особенно программисты  Поэтому ВСЁ нужно перепроверять.
  22. 22. Экспресс анализ изменений Старая функция Новая функция
  23. 23. Запускаем тестовые трейсы запросов
  24. 24. Анализ результатов: метрики 1. Время выполнения запроса. 2. Количество логических чтений. 3. Время СУБД на обработку запроса. 4. Количество памяти, выделенное на обработку запроса.
  25. 25. Анализ результатов
  26. 26. Анализ результатов: распределение по времени выполнения. Главный пик сместился, т.е большинство запросов стало быстрее. Но появился новый пик, которого раньше не
  27. 27. Возвращаем кейс
  28. 28. Выводы 1. Практически невозможно оптимизировать запрос так, чтобы не замедлить что-то другое. 2. Обычно нет проблем оптимизировать один проблемный запрос. Наибольшая сложность - оптимизировать весь набор запросов. 3. Поэтому - чем более универсальный запрос, тем он медленнее! 4. Это первый из “балансов”. Можно оптимизировать какой-то конкретный запрос за счет других.
  29. 29. Вечер вторника
  30. 30. Среда Идет активная работа. И только тестировщик Хаус в это время …
  31. 31. Среда Команда находит и представляет новое решение.
  32. 32. Экспресс анализ изменений Старая функция Новая функция Куда исчезла логика?
  33. 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. 34. View vs Indexed View 1. Виртуальная (логическая) таблица, представляюща я собой поименованный запрос. 2. Физически данные не хранятся. SELECT вычисляется каждый раз, когда к нему обращаются. View Indexed View 1. Представление, на котором создан кластерный индекс. 2. Физически данные хранятся, как и в обычной таблице.
  35. 35. Баланс скорости чтения и скорости модификаций 1. Кластерное представление будет пересчитываться при каждой модификации исходных таблиц. 2. Модификация станет медленнее, а чтение, скорее всего, быстрее. 3. Баланс №2 – оптимизация скорости чтения за счет скорости модификаций или наоборот.
  36. 36. Анализ результатов: чтений
  37. 37. Анализ результатов: модификаций
  38. 38. Анализ результатов Выносить или нет …
  39. 39. Еще разок … Намного лучше. А можно сделать еще лучше?
  40. 40. Выводы 1. Наиболее важный баланс в оптимизации запросов – это баланс скорости чтений и скорости модификаций. 2. Практически всегда можно ускорить чтения, замедлив соответствующие изменения данных. 3. Принимать решения о приемлемости такой оптимизации необходимо, основываясь на знаниях о приложении.
  41. 41. Четверг Опять идет активная работа
  42. 42. Четверг Новое решение …
  43. 43. Экспресс анализ изменений Старая функция Новая функция Они одинаковые!!! Значит, измен илась схема базы!!! Индексы?!
  44. 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. 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. 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. 47. Представляйте себе книгу Кластерный индекс – это номера страниц в книге. Некластерный индекс – это предметный указатель.
  48. 48. Анализ результатов: добавление индексов
  49. 49. Анализ результатов: добавление индексов - модификация
  50. 50. Выводы 1. Изменения индексов – наиболее популярный и простой способ оптимизации. 2. Индексы, как и кластерные представления, замедляют операции модификации. 3. Обычно функциональное тестирование не требуется.
  51. 51. Пятница Совместный анализ всех результатов
  52. 52. Анализ результатов Выросший максимум Скорость функции Скорость модификаций
  53. 53. Выносим изменения
  54. 54. Выводы 1. Для любой задачи существует несколько путей и подходов оптимизации. 2. Оптимизация запросов – это всегда вопрос баланса, поэтому задача тестирования - правильно выявить этот баланс. 3. Выбор того или иного решения всегда зависит от специфики приложения.
  55. 55. Выводы недели 1. Подготовка к тестированию – самый важный этап. Если вы проигнорировали хотя бы один из подготовительных шагов – вашим тестам нельзя доверять. 2. Оптимизация – это вопрос баланса: • оптимизация какого-то конкретного запроса за счет других; • оптимизация чтений за счет модификаций; 3. Поэтому почти всегда можно найти, что в действительности стало медленнее.
  56. 56. Молодцы!!!
  57. 57. Помощь Командная работа или тестировщиков нужно всегда поддерживать!!!
  58. 58. Подводим итоги недели 1) Разобрались с операциями над множествами, такими как except и union. И даже реализовали except all. 2) Мы разработали метод функционального тестирования запросов. 3) Нашли очень замысловатую логическую ошибку и исправили старый функциональный баг. Подход Доктора Хауса к тестированию оптимизации запросов 1. Разбираться в проблеме до конца. 2. Быть одной командой. 3. Все врут, а значит - всё нужно перепроверять. 4. Не бояться резать по живому, но всегда контролировать. 5. Не сдаваться!!!
  59. 59. Вопросы? Team Lead / Software Developer in VIAcode www.linkedin.com/in/ssmikhalev vk.com/ssmikhalev ssmikhalev@gmail.com f1incode.com

×