Данная статья описывает наиболее распространенные подходы к тестированию производительности приложений; пользуясь аналогиями «из жизни» и примерами из опыта автора, показывает, почему так делать нельзя; и, наконец, пытается заронить искру понимания важности нагрузочного тестирования в светлые умы разработчиков, менеджеров и прочих хороших людей.
Начнем с пары историй.
История А.
На днях разговаривал с одним программистом. Пишет он на С++, работает в крупной компании в Чикаго; софтом, к созданию которого он причастен, активно пользуются финансовые и трейдерские компании. У нас, говорит, в продукте 600 тысяч строк кода. Начиналось все с небольшого приложения для анализа биржевой статистики, и вот за 20 лет вымахал такой монстр. Здорово, говорю. Внушает уважение. И как вы его тестируете, вашего монстра? Для этого, отвечает мне программист, есть специальный индус. Он какие-то тест кейсы выполняет, отчеты пишет. А до него этим менеджер один занимался, но тот все больше ручное тестирование делал. Новые функции проверял, например. Теперь вот индус. Хорошо, продолжаю выпытывать я, это функциональное тестирование. А производительность вы как-то тестируете? Нет, говорит, если клиенты начинают жаловаться на медленную работу, мы тогда сами ищем узкие места и сами же из исправляем. Кто разрабатывает продукт, тот его и знает лучше. Какой тестер с этим справится?
Умный человек, подумал я, а говорит глупости.
История Б.
Захожу позавчера на Хабрахабр, натыкаюсь на статью «История развития и оптимизаций одного высоконагруженного ресурса». Для тех, кто не читал — автор пишет, как он начал работать админом некоего ресурса. Вскоре этот ресурс перестал справляться с возросшим числом пользователей и он, автор, улучшил производительность сервера и уменьшил нагрузку на БД в несколько раз, применив некоторые технологии. Читаю фразу «Нагрузка на MySQL снизилась в 4 раза», задаю вопрос в комментариях — как отразились все ваши оптимизации на времени отклика для пользователей"? Из ответа следует, что автора больше волнует не опыт пользователей, а количество открытых соединений и число SQL-запросов.
Умный человек, снова подумал я, но не до конца понимает, с какой целью он что-то делает.
Эти два случая описывают наиболее типичные подходы к нагрузочному тестированию. Совсем кратко их можно описать следующим образом:
А: «Когда будут проблемы с производительностью — тогда и будем решать. Сами. Никакие специальные тестеры нам не нужны.»
Б: "… И тут мы увидели, что CPU на сервере с базой данных не справляется! Погуглили «MySQL + CPU problem», нашли замечательную библиотеку, установили, и нагрузка уменьшилась в N раз. Теперь все хорошо."
Начнем с критики подхода Б (назовем его «админским», чтобы поменьше злоупотреблять алфавитом). Итак, ключевая проблема «админского» подхода – неверная точка зрения на проблему производительности.
Как видно из истории, приведенной выше, админ смотрит глазами админа. Индикатором проблемы для него является нагрузка на сервер, показателями, по которым он судит об изменении ситуации к лучшему – число и скорость запросов, соединений и т.п. Вопрос – сколько еще человек в мире видит ту же самую проблему на конкретном сайте точно так же? Правильный ответ – ноль. У пользователей, заходящих на сайт, нет желания беспокоиться об индексах в базе данных. Их не интересуют графики загрузки CPU и дисковой подсистемы. Максимум, что они могут сказать: «этот сайт тормозит». И еще: «поищу-ка я какой-нибудь такой же, но быстрый». Соотношение тех, кто измеряет быстродействие, опираясь на количество SQL запросов и тех, кому важно только «чтоб страничка не тормозила» — 1 к N, где N – все посетители сайта, а 1 – очень умный, но одинокий администратор.
… Когда я говорю все это админам, они обычно отвечают мне что-нибудь вроде «но ведь пользователи не знают, как все это работает. А мы – знаем. И потом, опираясь на мнение пользователей, почти невозможно определить источник проблемы». На это у меня есть готовый ответ, который действует безотказно. Когда вы приходите к врачу, о чем он вас спрашивает? О самочувствии. Давление и температуру измеряют уже потом, направление на анализы дают не сразу. А начинают с вопросов вроде – «Где болит?», или «Когда хуже – утром или вечером?». Вопросы простые, на них не всегда возможно дать математически точный ответ, но именно по ним определяют симптомы заболевания. И, в конечном итоге, именно избавление от симптомов радует больного больше всего. «Выпишите мне что-нибудь, чтобы не болело». Или, в нашем случае – «сделайте хоть 200 запросов на страницу, но чтоб не тормозило». Конечно, хороший врач никогда не поставит диагноз только по описанию самочувствия пациентом. Но точно так же он никогда не будет его недооценивать или, чего хуже, игнорировать.
Итого – «админский подход» плох, потому что не рассматривает проблемы производительности с точки зрения реальных пользователей приложения или сайта. Серверам, возможно, такой вариант подходит, а вот клиентам – не особенно. Впрочем, если число клиентов примерно равняется числу серверов… надеюсь, это не ваш случай.
Кроме того, в своей практике я неоднократно встречал ситуацию, когда оптимизация, использующая в качестве входных данных графики нагрузки на сервера и статистику по БД, приносила результат, близкий к нулевому.
Пример 1: анализ статистики Oracle показал, что некий запрос будет выполняться в два раза быстрее, если построить индекс. Индекс был создан, запрос стал выполняться 0.5 вместо 1 секунды, время отклика операции уменьшилось с 35 до 34.5 секунды.
Пример 2: некая операция была оптимизирована так, что при ее выполнении нагрузка на CPU сервера снизилась на 30%. К сожалению, доля этой операции среди всех прочих, выполняемых пользователями – 0.1%, так что ощутимого изменения в картине нагрузки на сервер не произошло, а пользователи не заметили улучшения.
И тому подобное. Возвращаясь к аналогии «врач-больной»:
-Пациент, у вас теперь нормальная температура и состав крови, вы здоровы.
– Но доктор, мне все еще плохо!..
Теперь поговорим о подходе А. Называть мы его будем, как уже можно догадаться, — «девелоперским»: точка зрения, озвученная моим знакомым, достаточно типична для разработчиков. «Кто, кроме нас, способен разобраться в нашем приложении?», «Тестирование – это когда проверяют, чтобы кнопочки на форме нажимались», и т.п. Пренебрежительное отношение к QA – вообще одна из бед отрасли, но эта тема достойна отдельной статьи, не будем отвлекаться.
В чем главный недостаток «девелоперского» подхода? Проблема осознается только после того, как с ней столкнулись пользователи. Другими словами — пока гром не грянет. Увы, часто оказывается, что креститься к этому моменту уже поздно. Система ушла в эксплуатацию и клиент будет недоволен, если окажется, что нужно что-то патчить и докручивать; тим лид разработки уехал в Тибет; невозможно определить причину низкой производительности, потому что медленно работает буквально все; денег на новый сервер нет – список возможных проблем можно продолжать до бесконечности. Обычно в такой ситуации несколько наиболее талантливых (в лучшем случае) или наименее загруженных (в худшем) разработчиков срочно создают костыль, который поддерживает хромую систему на ходу до следующего апдейта / пика нагрузки на Новый Год / квартального отчета. После чего в Тибет перебирается еще больше людей. Не всегда по своей воле, хо-хо.
Небольшая ремарка. В принципе, мне, как консультанту по производительности и нагрузочному тестированию, «девелоперский» подход обычно мешает так же мало, как и «админский». Когда система начинает «гореть», слова программистов и админов — «у нас все хорошо» или «мы сейчас все исправим» — перестают убеждать руководителей проекта. Принимается решение нанять пожарного специалиста по нагрузке, и – вуаля –у меня есть новый клиент. Так что, уважаемые программисты и администраторы – продолжайте в том же духе, большое спасибо. Конец рекламной паузы.
Для тех, кто не хочет терять клиентов и деньги или же столкнуться с необходимостью рассылать свое резюме, у меня есть новая аналогия в подарок. Ходить в спортзал можно как для улучшения самочувствия, так и для предотвращения его ухудшения. Не все выбирают второй вариант, но, согласитесь, он предпочтительней. И для здоровья и для кошелька.
Кроме того факта, что лучше избегать проблем, нежели героически сражаться с ними, есть еще один довод в пользу тестирования силами, выражаясь языком моего знакомого, «специальных тестеров». Любой человек подсознательно думает, что все, что он делает – безупречно. Или почти безупречно. Разработчики – не исключение. «Зачем тестировать, если я точно знаю, что все будет нормально, только потеряем время». Однако, опыт показывает, что а) человек со стороны более изобретателен и успешен в поиске ошибок, б) трата времени на QA оборачивается большой экономией и времени, и денег в будущем. Во всех индустриях, не исключая разработку ПО.
Итак, мы рассмотрели два подхода к нагрузочному тестированию приложений: с точки зрения администраторов системы и со стороны разработчиков. Оба они несовершенны, оба упускают из виду самый главный факт: приложения пишутся, системы разворачиваются, сайты открываются в первую очередь для пользователей. И лучше позаботиться об этих пользователях заранее.
О том, с чего начать тестирование производительности, какие бывают виды нагрузочного тестирования, какими методиками лучше пользоваться и т.п. – обо всем этом написано достаточно много, и я не ставлю своей задачей пересказать все своими словами. Вместо этого я планирую время от времени писать о том или ином аспекте тестирования производительности, делать обзоры утилит для тестирования, и так далее. Разумеется, в том случае, если эта тема будет интересна аудитории. Спасибо за внимание.
Начнем с пары историй.
История А.
На днях разговаривал с одним программистом. Пишет он на С++, работает в крупной компании в Чикаго; софтом, к созданию которого он причастен, активно пользуются финансовые и трейдерские компании. У нас, говорит, в продукте 600 тысяч строк кода. Начиналось все с небольшого приложения для анализа биржевой статистики, и вот за 20 лет вымахал такой монстр. Здорово, говорю. Внушает уважение. И как вы его тестируете, вашего монстра? Для этого, отвечает мне программист, есть специальный индус. Он какие-то тест кейсы выполняет, отчеты пишет. А до него этим менеджер один занимался, но тот все больше ручное тестирование делал. Новые функции проверял, например. Теперь вот индус. Хорошо, продолжаю выпытывать я, это функциональное тестирование. А производительность вы как-то тестируете? Нет, говорит, если клиенты начинают жаловаться на медленную работу, мы тогда сами ищем узкие места и сами же из исправляем. Кто разрабатывает продукт, тот его и знает лучше. Какой тестер с этим справится?
Умный человек, подумал я, а говорит глупости.
История Б.
Захожу позавчера на Хабрахабр, натыкаюсь на статью «История развития и оптимизаций одного высоконагруженного ресурса». Для тех, кто не читал — автор пишет, как он начал работать админом некоего ресурса. Вскоре этот ресурс перестал справляться с возросшим числом пользователей и он, автор, улучшил производительность сервера и уменьшил нагрузку на БД в несколько раз, применив некоторые технологии. Читаю фразу «Нагрузка на MySQL снизилась в 4 раза», задаю вопрос в комментариях — как отразились все ваши оптимизации на времени отклика для пользователей"? Из ответа следует, что автора больше волнует не опыт пользователей, а количество открытых соединений и число SQL-запросов.
Умный человек, снова подумал я, но не до конца понимает, с какой целью он что-то делает.
* * *
Эти два случая описывают наиболее типичные подходы к нагрузочному тестированию. Совсем кратко их можно описать следующим образом:
А: «Когда будут проблемы с производительностью — тогда и будем решать. Сами. Никакие специальные тестеры нам не нужны.»
Б: "… И тут мы увидели, что CPU на сервере с базой данных не справляется! Погуглили «MySQL + CPU problem», нашли замечательную библиотеку, установили, и нагрузка уменьшилась в N раз. Теперь все хорошо."
* * *
Начнем с критики подхода Б (назовем его «админским», чтобы поменьше злоупотреблять алфавитом). Итак, ключевая проблема «админского» подхода – неверная точка зрения на проблему производительности.
Как видно из истории, приведенной выше, админ смотрит глазами админа. Индикатором проблемы для него является нагрузка на сервер, показателями, по которым он судит об изменении ситуации к лучшему – число и скорость запросов, соединений и т.п. Вопрос – сколько еще человек в мире видит ту же самую проблему на конкретном сайте точно так же? Правильный ответ – ноль. У пользователей, заходящих на сайт, нет желания беспокоиться об индексах в базе данных. Их не интересуют графики загрузки CPU и дисковой подсистемы. Максимум, что они могут сказать: «этот сайт тормозит». И еще: «поищу-ка я какой-нибудь такой же, но быстрый». Соотношение тех, кто измеряет быстродействие, опираясь на количество SQL запросов и тех, кому важно только «чтоб страничка не тормозила» — 1 к N, где N – все посетители сайта, а 1 – очень умный, но одинокий администратор.
… Когда я говорю все это админам, они обычно отвечают мне что-нибудь вроде «но ведь пользователи не знают, как все это работает. А мы – знаем. И потом, опираясь на мнение пользователей, почти невозможно определить источник проблемы». На это у меня есть готовый ответ, который действует безотказно. Когда вы приходите к врачу, о чем он вас спрашивает? О самочувствии. Давление и температуру измеряют уже потом, направление на анализы дают не сразу. А начинают с вопросов вроде – «Где болит?», или «Когда хуже – утром или вечером?». Вопросы простые, на них не всегда возможно дать математически точный ответ, но именно по ним определяют симптомы заболевания. И, в конечном итоге, именно избавление от симптомов радует больного больше всего. «Выпишите мне что-нибудь, чтобы не болело». Или, в нашем случае – «сделайте хоть 200 запросов на страницу, но чтоб не тормозило». Конечно, хороший врач никогда не поставит диагноз только по описанию самочувствия пациентом. Но точно так же он никогда не будет его недооценивать или, чего хуже, игнорировать.
Итого – «админский подход» плох, потому что не рассматривает проблемы производительности с точки зрения реальных пользователей приложения или сайта. Серверам, возможно, такой вариант подходит, а вот клиентам – не особенно. Впрочем, если число клиентов примерно равняется числу серверов… надеюсь, это не ваш случай.
Кроме того, в своей практике я неоднократно встречал ситуацию, когда оптимизация, использующая в качестве входных данных графики нагрузки на сервера и статистику по БД, приносила результат, близкий к нулевому.
Пример 1: анализ статистики Oracle показал, что некий запрос будет выполняться в два раза быстрее, если построить индекс. Индекс был создан, запрос стал выполняться 0.5 вместо 1 секунды, время отклика операции уменьшилось с 35 до 34.5 секунды.
Пример 2: некая операция была оптимизирована так, что при ее выполнении нагрузка на CPU сервера снизилась на 30%. К сожалению, доля этой операции среди всех прочих, выполняемых пользователями – 0.1%, так что ощутимого изменения в картине нагрузки на сервер не произошло, а пользователи не заметили улучшения.
И тому подобное. Возвращаясь к аналогии «врач-больной»:
-Пациент, у вас теперь нормальная температура и состав крови, вы здоровы.
– Но доктор, мне все еще плохо!..
* * *
Теперь поговорим о подходе А. Называть мы его будем, как уже можно догадаться, — «девелоперским»: точка зрения, озвученная моим знакомым, достаточно типична для разработчиков. «Кто, кроме нас, способен разобраться в нашем приложении?», «Тестирование – это когда проверяют, чтобы кнопочки на форме нажимались», и т.п. Пренебрежительное отношение к QA – вообще одна из бед отрасли, но эта тема достойна отдельной статьи, не будем отвлекаться.
В чем главный недостаток «девелоперского» подхода? Проблема осознается только после того, как с ней столкнулись пользователи. Другими словами — пока гром не грянет. Увы, часто оказывается, что креститься к этому моменту уже поздно. Система ушла в эксплуатацию и клиент будет недоволен, если окажется, что нужно что-то патчить и докручивать; тим лид разработки уехал в Тибет; невозможно определить причину низкой производительности, потому что медленно работает буквально все; денег на новый сервер нет – список возможных проблем можно продолжать до бесконечности. Обычно в такой ситуации несколько наиболее талантливых (в лучшем случае) или наименее загруженных (в худшем) разработчиков срочно создают костыль, который поддерживает хромую систему на ходу до следующего апдейта / пика нагрузки на Новый Год / квартального отчета. После чего в Тибет перебирается еще больше людей. Не всегда по своей воле, хо-хо.
Небольшая ремарка. В принципе, мне, как консультанту по производительности и нагрузочному тестированию, «девелоперский» подход обычно мешает так же мало, как и «админский». Когда система начинает «гореть», слова программистов и админов — «у нас все хорошо» или «мы сейчас все исправим» — перестают убеждать руководителей проекта. Принимается решение нанять пожарного специалиста по нагрузке, и – вуаля –у меня есть новый клиент. Так что, уважаемые программисты и администраторы – продолжайте в том же духе, большое спасибо. Конец рекламной паузы.
Для тех, кто не хочет терять клиентов и деньги или же столкнуться с необходимостью рассылать свое резюме, у меня есть новая аналогия в подарок. Ходить в спортзал можно как для улучшения самочувствия, так и для предотвращения его ухудшения. Не все выбирают второй вариант, но, согласитесь, он предпочтительней. И для здоровья и для кошелька.
Кроме того факта, что лучше избегать проблем, нежели героически сражаться с ними, есть еще один довод в пользу тестирования силами, выражаясь языком моего знакомого, «специальных тестеров». Любой человек подсознательно думает, что все, что он делает – безупречно. Или почти безупречно. Разработчики – не исключение. «Зачем тестировать, если я точно знаю, что все будет нормально, только потеряем время». Однако, опыт показывает, что а) человек со стороны более изобретателен и успешен в поиске ошибок, б) трата времени на QA оборачивается большой экономией и времени, и денег в будущем. Во всех индустриях, не исключая разработку ПО.
* * *
Итак, мы рассмотрели два подхода к нагрузочному тестированию приложений: с точки зрения администраторов системы и со стороны разработчиков. Оба они несовершенны, оба упускают из виду самый главный факт: приложения пишутся, системы разворачиваются, сайты открываются в первую очередь для пользователей. И лучше позаботиться об этих пользователях заранее.
* * *
О том, с чего начать тестирование производительности, какие бывают виды нагрузочного тестирования, какими методиками лучше пользоваться и т.п. – обо всем этом написано достаточно много, и я не ставлю своей задачей пересказать все своими словами. Вместо этого я планирую время от времени писать о том или ином аспекте тестирования производительности, делать обзоры утилит для тестирования, и так далее. Разумеется, в том случае, если эта тема будет интересна аудитории. Спасибо за внимание.
