Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
Все ж таки было бы очень интересно почитать про методы и инструменты для нагрузочного тестирования.
Возможно пригодится
software-testing.ru/trainings/catalogue/online/64-performance-testing
software-testing.ru/trainings/catalogue/online/64-performance-testing
Не хватает практических советов. Ждем продолжения.
Однозначно. Продолжение с примерами и советами.
интересная статья, что по поводу тестеров, то тут нужен талант. Не каждый может стать тестером. тестер с которым я работаю — от Бога. Он такие тест кейсы придумывает и находит такое, что я сам не то что придумать не могу, но даже под «много пива, накуриться, утопиться и потом воскреснуть» никогда не подумаю что так вообще можно делать в здравом уме.
основываясь на своем опыте могу сказать что тестировать нужно ВСЕ. нагрузочное, функциональное, регрессивное, модульное, интеграционное — нужно применять все иначе со 100% вероятностью когда вы будете отдыхать на канарах система упадет и встанет вопрос — либо ты возвращаешься и чинишь либо ты уволен :)
основываясь на своем опыте могу сказать что тестировать нужно ВСЕ. нагрузочное, функциональное, регрессивное, модульное, интеграционное — нужно применять все иначе со 100% вероятностью когда вы будете отдыхать на канарах система упадет и встанет вопрос — либо ты возвращаешься и чинишь либо ты уволен :)
На «тестировать ВСЕ» нужен очень хороший бюджет.
тут вопрос в том, что если вам нужен хороший продукт — выделяйте хороший бюджет. (про распил речи не идет). если вам нужен продукт так себе — не выделяйте. но там не будут тестировать ВСЕ
Другое видение:
у вас есть возможность обеспечить ТОЛЬКО хорошее функциональное тестирование (что поделать, если бюджет мал — отсальное забрали спиногрызы-разработчики).
Я не спорю, что тестировать нужно все.
Но иногда, когда пытаешься предложить кастомеру автоматизацию или перфоманс — он отказывается просто потому что выйдет out of money.
Тестировать нужно то, что наиболее критично. А если позволяют деньги — то и все остальное :)
у вас есть возможность обеспечить ТОЛЬКО хорошее функциональное тестирование (что поделать, если бюджет мал — отсальное забрали спиногрызы-разработчики).
Я не спорю, что тестировать нужно все.
Но иногда, когда пытаешься предложить кастомеру автоматизацию или перфоманс — он отказывается просто потому что выйдет out of money.
Тестировать нужно то, что наиболее критично. А если позволяют деньги — то и все остальное :)
— Пример 1: анализ статистики Oracle показал, что некий запрос будет выполняться в два раза быстрее, если построить индекс. Индекс был создан, запрос стал выполняться 0.5 вместо 1 секунды, время отклика операции уменьшилось с 35 до 34.5 секунды.
Есть такая книжка с не очень оригинальным названием «Оракл. Оптимизация производительности». Миллсапа и Хольта (кстати, по-моему она вот тут лежит www.citycat.com.ua/doc/Optimization.pdf, качается очень медленно).
Как следует из названия она про оптимизацию Оракла, но это не совсем так: примерно половина книги посвящена именно определению того, что именно нужно оптимизировать и именно с точки зрения бизнеса, а не поставщика решений и посвящена манагерам, а не девелоперам/администраторам. Если кто интересуется вопросом, будет интересно почитать.
Есть такая книжка с не очень оригинальным названием «Оракл. Оптимизация производительности». Миллсапа и Хольта (кстати, по-моему она вот тут лежит www.citycat.com.ua/doc/Optimization.pdf, качается очень медленно).
Как следует из названия она про оптимизацию Оракла, но это не совсем так: примерно половина книги посвящена именно определению того, что именно нужно оптимизировать и именно с точки зрения бизнеса, а не поставщика решений и посвящена манагерам, а не девелоперам/администраторам. Если кто интересуется вопросом, будет интересно почитать.
Я думаю тут дело больше в том, насколько сам запрос оптимален. Можно написать запрос, который использует кластерные индексы, но сам запрос будет крайне непроизводительным из-за того, что сам по себе, использует какие-то вложенные лишние циклы, например. В итоге получится запрос, который выполняется 30 секунд, вместо положенных 2-3х секунд
ИМХО: с производительностью с любых точек зрения админа/программиста/владельца все достаточно просто ибо 100% будет работать любой нижеприведенный подход:
1. Апгрейдим железо пока не станет жалко денег — процесс может продолжаться вечно, ибо новое железо может стоить ГОРАЗДО меньше прибыли которую приносит проект.
2. Меняем софт. С этим тоже все понятно. сменили apache+mod-php на php-fpm + nginx или стали nginx-ом статику раздавать вроде стало полегче и т. д.
3. Тюнинг выбранного софта.
4. Тюнинг используемого приложения.
Повторюсь, работать до определенного момента будет любой подход, просто в определенные моменты времени нанять админа чтобы он сменил железо дешевле чем нанимать программиста чтобы тот переписал некоторые ключевые части софта.
1. Апгрейдим железо пока не станет жалко денег — процесс может продолжаться вечно, ибо новое железо может стоить ГОРАЗДО меньше прибыли которую приносит проект.
2. Меняем софт. С этим тоже все понятно. сменили apache+mod-php на php-fpm + nginx или стали nginx-ом статику раздавать вроде стало полегче и т. д.
3. Тюнинг выбранного софта.
4. Тюнинг используемого приложения.
Повторюсь, работать до определенного момента будет любой подход, просто в определенные моменты времени нанять админа чтобы он сменил железо дешевле чем нанимать программиста чтобы тот переписал некоторые ключевые части софта.
> в определенные моменты времени нанять админа чтобы он сменил железо дешевле чем нанимать программиста
Практика показывает, что когда идет взрывной рост, первое что эффективнее всего меняется — это как раз программная часть.
Достаточно просто посмотреть на список идущих к базе запросов на ключевых страницах. Смотришь и видишь, что потратив пару дней рабочего времени на пресловутые индексы + кеширование более-менее статичных кусков контента, ты убережешься от преждевременного апгрейда и, что более важно, купишь себе этим немного времени, чтобы нормально заняться пп. 2-4. Короче, делается то, что даст немедленный выигрыш по скорости и времени отклика. Покупка/настройка/запуск новой железки — это тоже время, не забываем об этом.
Реально нагруженные системы идут по пути увеличения парка машин, а не их качества (апгрейда процов/памяти). Примеров — тысячи, начиная с хрестоматийного Гугла. Пункт 1 вообще должен быть резервным вариантом, а не первоочередным.
Практика показывает, что когда идет взрывной рост, первое что эффективнее всего меняется — это как раз программная часть.
Достаточно просто посмотреть на список идущих к базе запросов на ключевых страницах. Смотришь и видишь, что потратив пару дней рабочего времени на пресловутые индексы + кеширование более-менее статичных кусков контента, ты убережешься от преждевременного апгрейда и, что более важно, купишь себе этим немного времени, чтобы нормально заняться пп. 2-4. Короче, делается то, что даст немедленный выигрыш по скорости и времени отклика. Покупка/настройка/запуск новой железки — это тоже время, не забываем об этом.
Реально нагруженные системы идут по пути увеличения парка машин, а не их качества (апгрейда процов/памяти). Примеров — тысячи, начиная с хрестоматийного Гугла. Пункт 1 вообще должен быть резервным вариантом, а не первоочередным.
все наоборот — думать о производительности надо тогда, когда самого кода еще нет. а не доставлять железо, когда стало вдруг очевидно, что дерьмо написали, которое переписать уже невозможно.
Апгрейдим железо пока не станет жалко денег — процесс может продолжаться вечноВертикальное масштабирование имеет вполне себе неиллюзорный предел, достигаемый очень быстро.
Горизонтальное много сложнее в реализации, особенно в крупных масштабах, но теоретически лишено предела масштабируемости.
В статье написано, что ресурс в том виде, котором окончилось его развитие состоял всего из трех серверов.
Тем более используется простейшая схема распределения ролей по серверам:
1. nginx
2. php-fpm
3. mysql
куда можно было бы расти дальше на мой взгляд вполне очевидно.
Тем более используется простейшая схема распределения ролей по серверам:
1. nginx
2. php-fpm
3. mysql
куда можно было бы расти дальше на мой взгляд вполне очевидно.
мой комментарий относился к вашему заблуждению насчет «вечного апгрейда», а не насчет схемы ТС.
Если говорить о сферическом проекте в вакууме, то вполне верным будет Ваше утверждение, что вертикальное масштабирование ограничено текущим технологическим потолком.
Капитан спасибо Вам, что открыли мне глаза :)
Капитан спасибо Вам, что открыли мне глаза :)
Вертикальное масштабирование в сферическом варианте не ограничено, а вот в рамках физических законов реального мира — вполне себе.
p.s.: а вы знаете, что упоминание Этого Самого не в тему (да и в тему тоже) чревато флуктуациями некоторых циферок в профиле упомянувшего всуе? Как правило, флуктуации имеют негативный характер.
p.s.: а вы знаете, что упоминание Этого Самого не в тему (да и в тему тоже) чревато флуктуациями некоторых циферок в профиле упомянувшего всуе? Как правило, флуктуации имеют негативный характер.
Насколько успешным будет любой из предложенных Вами подходов зависит от масштабов проекта.
К примеру: если речь о небольшом (или даже среднем) сайте — то да, в принципе, можно кидать деньги на ветер покупая новое железо. Может, конечно, оказаться, что узким местом является не CPU, а диски, ну дак диски тоже дешевые, купим, чего уж.
То же самое про все остальное — замена софта, тюнинг, и т.п. Это вполне рабочием механизмы улучшения производительности. Но а) только для не очень сложных систем, б) неэффективные с точки зрения стоимости.
К примеру: если речь о небольшом (или даже среднем) сайте — то да, в принципе, можно кидать деньги на ветер покупая новое железо. Может, конечно, оказаться, что узким местом является не CPU, а диски, ну дак диски тоже дешевые, купим, чего уж.
То же самое про все остальное — замена софта, тюнинг, и т.п. Это вполне рабочием механизмы улучшения производительности. Но а) только для не очень сложных систем, б) неэффективные с точки зрения стоимости.
Вы хорошо написали, как тестировать плохо. Хорошо бы написать про то, как тестировать хорошо. :)
loadimpact.com/ — нагрузочное тестирование.
Я сам просто писал скрипт, который по существующим логам имитировал работу клиентов — в несколько потоков отправлял запросы серверу.
Разделение на frontend и backend не повлияло практически на время загрузки, но увеличило производительность (запросы/сек).
Я сам просто писал скрипт, который по существующим логам имитировал работу клиентов — в несколько потоков отправлял запросы серверу.
Разделение на frontend и backend не повлияло практически на время загрузки, но увеличило производительность (запросы/сек).
Из ответа следует, что автора больше волнует не опыт пользователей, а количество открытых соединений и число SQL-запросов.
Начнем с критики подхода Б (назовем его «админским», чтобы поменьше злоупотреблять алфавитом). Итак, ключевая проблема «админского» подхода
Мне кажется, заранее объявлять подходы системных администраторов к оптимизации неправильными преждевременно. Системные администраторы серверов — не тестеры бизнес-приложения, не его пользователи. В их обязанности тестирование продукта и напрягание его разработчиков с просьбой устранить узкие места не входит. Их забота — серверы и нагрузка на эти серверы. Они ее оптимизируют и уменьшают. Если ваш системный администратор — прирожденный тестер и делает все то, что он по профессии своей делать не должен — это прекрасно. Но заранее требовать этого нельзя. Каждый должен заниматься своим делом, а не переваливать его на других. Дескать, «не знаю я ничего, это сисадмин должен мне рапортовать, как мне число запросов к базе уменьшить. А мой DBA и так занят выше крыши.»
Многие критикуют узкую специализацию, но все же узкая направленность специалистов — один из гарантов качества. Если ваш системный администратор по совместительству программист, тестер, менеджер и архитектор, а также жилетка, в которую с завидной регулярностью плачется главбух с требованием срочно заменить вот эту форму и переделать вооон тот глючный отчет в 1С, как можно требовать от него, чтобы пятьсот серверов вашего сервиса содержались в идеальном порядке и безукоризненно работали?
Очень популярный и довольно сложный инструмент — (HP LoadRunner) Mercury LoadRunner.
На нем можно тестировать нагрузку на определенные действия пользователя, создавая скрипт который можно модифицировать.
Тестирование, грубо говоря эмулирует действия пользователей на основе написанного (записанного) вами скрипта.
Вот тут написано о методологии в общих чертах
www.cio-world.ru/products/infrastructure/414686/
На нем можно тестировать нагрузку на определенные действия пользователя, создавая скрипт который можно модифицировать.
Тестирование, грубо говоря эмулирует действия пользователей на основе написанного (записанного) вами скрипта.
Вот тут написано о методологии в общих чертах
www.cio-world.ru/products/infrastructure/414686/
и стоит как паровоз. на первом этапе хватит Jmeter'а с хорошими плагинами.
Потом эти же скрипты — Synthetic End Users — можно использовать для мониторинга production системы — как дополнение к системному мониторингу, для того чтобы не было проблемы, охарактеризованной автором статьи как админский подход.
Мой любимый инструмент. Был соблазн написать что-нибудь про него, но к сожалению, большинство проектов себе его позволить не могут. Есть идея писать о чем-то более доступном, пусть и не настолько мощном.
«Админский» подход прямо уж так неверный? Админы допиливают сервер, оптимизируют, серверу от этого лучше, нагрузка меньше, значит меньше вероятность что сервер ляжет от большого количества запросов. Если этого не будет сделано, то пользователь будет недоволет не тормозами, а отсутствием доступа.
Так что админ делает свою часть работы. И немалую. Остальное — не его ответственность.
Так что админ делает свою часть работы. И немалую. Остальное — не его ответственность.
Я использую jMeter. Позволяет создавать любые типы запросов к серверу. Чтобы избежать рутины при создании скриптов, можно сначала с помощью Badboy записывать действия, затем экспортировать в формат jmeter и допиливать руками необходимый уровень кастомизации запросов (например список id'шников передавать из csv файла)
Касательно утилит для тестирования — ждем выхода «Лунапарка» от Яндекса. Кто смотрел их недавнюю конференцию, тот слышал о нем. Вроде все вполне серьезно, к тому же бесплатно.
Я правильно понимаю, что заслав бабло консультанту по безопасности, руководство получает красиво оформленный отчет примерно такого вида:
Глава 1. Все тормозит.
Глава 2. Девелоперам надо оптимизировать код.
Глава 3. Админам надо настроить сервера.
Или консультант по безопасности снимает костюм, надевает джинсы и идет править конфиги и курить код?
Глава 1. Все тормозит.
Глава 2. Девелоперам надо оптимизировать код.
Глава 3. Админам надо настроить сервера.
Или консультант по безопасности снимает костюм, надевает джинсы и идет править конфиги и курить код?
* то есть, конечно, консультант по производительности… да, впрочем, любой консультант
Смотря какой консультант. Не важно, причем, в какой области.
И — важно — смотря сколько времени и денег выделено на тестирование. Потому как процесс не очень быстрый, и некоторые его аспекты довольно затратны. Инструменты, например.
Обычно же отчет по результатам нагрузочного тестирования фокусируется на поиске узких мест (железо, софт, приложение, запросы к БД), рекомендациях по их устранению и показателях производительности системы в ее текущем состоянии (сможем пережить 100 пользователей в минуту с таким-то временем отклика по таким-то операциям).
И — важно — смотря сколько времени и денег выделено на тестирование. Потому как процесс не очень быстрый, и некоторые его аспекты довольно затратны. Инструменты, например.
Обычно же отчет по результатам нагрузочного тестирования фокусируется на поиске узких мест (железо, софт, приложение, запросы к БД), рекомендациях по их устранению и показателях производительности системы в ее текущем состоянии (сможем пережить 100 пользователей в минуту с таким-то временем отклика по таким-то операциям).
Обычно на первом этапе разработки начальство волнуют сроки и чтобы хоть как-то заработало. По крайней мере я в основном с таким сталкивался. Планирование на высокие нагрузки откладывается на потом.
Так вот, ИМХО, самое главное, уже на первом этапе заложить такие архитектурные решения, которые позволят в дальнейшем оптимизировать, т.е. находить и решать проблему «бутылочных горлышек».
Так вот, ИМХО, самое главное, уже на первом этапе заложить такие архитектурные решения, которые позволят в дальнейшем оптимизировать, т.е. находить и решать проблему «бутылочных горлышек».
Проблема в том, что развитие некоторых проектов часто идет по сценарию, описанному автором поста в истории А. Начинаются они в стиле «домашняя страница моего хомячка», а потом вырастают в системы корпоративного уровня. И в таких системах говорить о производительности язык не поворачивается.
Единственное решение — продумать архитектуру и переписать все с нуля, но это обычно возможно только до определенного этапа развития проекта. Иначе потом затраты на переделку и повторное внедрение становятся слишком большими, и приходится строить систему костылей, поддерживающую этого монстра.
Единственное решение — продумать архитектуру и переписать все с нуля, но это обычно возможно только до определенного этапа развития проекта. Иначе потом затраты на переделку и повторное внедрение становятся слишком большими, и приходится строить систему костылей, поддерживающую этого монстра.
>Для этого, отвечает мне программист, есть специальный индус.
Специальный индус для тестирования — это пять :)
Специальный индус для тестирования — это пять :)
Достаточно написать какой-нить простой скрипт и проверять им периодически, что ПО в текщей конфигурации на текущем железе держит двойную нагрузку спокойно и периодически гонять этим скриптом свое ПО на тестовых серверах, то есть один сервер, где скрипт генерит нагрузку, а второй где работает сам сервис. И отдельные тестеры далеко не всегда нужны.
Ок, давайте говорить более предметно.
— Что у нас за приложение?
— Что это будет за скрипт, какие действия он будет выполнять?
— Двойную нагрузку — как мы ее создаем? Одним скриптом?
— Что значит «держит спокойно»?
— Что у нас за приложение?
— Что это будет за скрипт, какие действия он будет выполнять?
— Двойную нагрузку — как мы ее создаем? Одним скриптом?
— Что значит «держит спокойно»?
Приложение — веб сервер (или любой другой сервер) в него можно много чего завернуть, про настольные приложения сложно сказать, можно что-нит аналогичное сообразить.
Скрипт, будет слать в порт запросы из логов запросов с продакшана.
Можно поместить лог запросов, ну допустим гигов 5 в оперативку целиком и слать запросы с удвоенной частотой относительно нагрузке в продашане, думаю скрипт на перле\питоне спавится с этим.
Ну спокойно — то есть допустим в течение полу часа, у него все ответы укладываются, например, в 300мс.
Если же при двойной нагрузке будет сильное замедление ответов, зачит скоро может быть туго… нужно тюнить приложение.
Скрипт, будет слать в порт запросы из логов запросов с продакшана.
Можно поместить лог запросов, ну допустим гигов 5 в оперативку целиком и слать запросы с удвоенной частотой относительно нагрузке в продашане, думаю скрипт на перле\питоне спавится с этим.
Ну спокойно — то есть допустим в течение полу часа, у него все ответы укладываются, например, в 300мс.
Если же при двойной нагрузке будет сильное замедление ответов, зачит скоро может быть туго… нужно тюнить приложение.
Подход понятен и имеет право на жизнь. :)
Есть, однако, несколько сложностей.
1. Что делать, если запрос нельзя выполнить повторно? Он меняет данные в БД, например. Или связан с куками, session id, прочими динамическими параметрами?
2. Почему пол часа и 300 мс? Почему не 10 минут/2 часа/месяц и 1 секунда/5 секунд/1 час? Как быть с тем, что для разных запросов разное приемлимое время выполнения?
3. Почему двойная нагрузка?
Итого — Ваша методика подойдет для очень грубого оценочного тестирования. Лучше чем ничего. Хуже, чем могло бы быть.
Есть, однако, несколько сложностей.
1. Что делать, если запрос нельзя выполнить повторно? Он меняет данные в БД, например. Или связан с куками, session id, прочими динамическими параметрами?
2. Почему пол часа и 300 мс? Почему не 10 минут/2 часа/месяц и 1 секунда/5 секунд/1 час? Как быть с тем, что для разных запросов разное приемлимое время выполнения?
3. Почему двойная нагрузка?
Итого — Ваша методика подойдет для очень грубого оценочного тестирования. Лучше чем ничего. Хуже, чем могло бы быть.
1. Можно 1 раз прогонять все запросы из лога, а не циклически их гонять, значит нужно нагенерить много запросов )
2. Пол часа и 300 мс это нужно уже подбирать более детально, я взял эти цифры с потолка.
3. Если мы справляемся с двойной нагрузкой, то значит еще довольно долго будет все в порядке(у нас например количество пользователей увеличивается в 2 раза за год), не в тех конечно случаях когда может быть за сутки 10 кратный рост.
2. Пол часа и 300 мс это нужно уже подбирать более детально, я взял эти цифры с потолка.
3. Если мы справляемся с двойной нагрузкой, то значит еще довольно долго будет все в порядке(у нас например количество пользователей увеличивается в 2 раза за год), не в тех конечно случаях когда может быть за сутки 10 кратный рост.
Скажу пару слов в защиту «админского» подхода. Казалось бы, действительно смотрят они не туда — изучают, что происходит на сервере, а не то, что видит клиент.
Но есть грань, когда проблемы производительности вдруг превращаются в функциональные проблемы. И происходит это не постепенно, а именно вдруг. Не было проблем, нормально всё с временем отклика — и вдруг как началось!
Кончились коннекшены к базе — и пользователи начинают получать пятисотые ошибки. Забилась файловая система — и опять пятисотые ошибки. Переполняются очереди в MQ — и появляются отказы в обслуживании. А ведь вроде бы ничего не предвещало, сколько ни наблюдай со стороны клиента.
Но есть грань, когда проблемы производительности вдруг превращаются в функциональные проблемы. И происходит это не постепенно, а именно вдруг. Не было проблем, нормально всё с временем отклика — и вдруг как началось!
Кончились коннекшены к базе — и пользователи начинают получать пятисотые ошибки. Забилась файловая система — и опять пятисотые ошибки. Переполняются очереди в MQ — и появляются отказы в обслуживании. А ведь вроде бы ничего не предвещало, сколько ни наблюдай со стороны клиента.
Всё-таки не стоит забывать, что как сказал Дональд Кнуд «Premature optimization is the root of all evil», т.е. преждевременная оптимизация — корень всех зол.
Оптимизировать безусловно надо и надо это делать с умом, но также не стоит забывать, что иногда проще и дешевле поставить ещё один сервер. Надо правильно оценивать return on investment.
И ещё одна очень мудрая мысль, принадлежащая кому-то из Гугла — если надо увеличить производительность на 20% мы поставим ещё несколько серверов, если же надо увеличить производительность в 10 раз, мы делаем редизайн.
Оптимизировать безусловно надо и надо это делать с умом, но также не стоит забывать, что иногда проще и дешевле поставить ещё один сервер. Надо правильно оценивать return on investment.
И ещё одна очень мудрая мысль, принадлежащая кому-то из Гугла — если надо увеличить производительность на 20% мы поставим ещё несколько серверов, если же надо увеличить производительность в 10 раз, мы делаем редизайн.
Спасибо за статью. Действительно верные мысли. Правда с историей Б вы немного ошиблись. :)
Пункты моей статьи были действительно ориентированы на повышение производительности сервера (т.к. прижало), однако это не главная цель. Пользователям становилось не комфортно посещать ресурс, исправить это и было основной целью. Достигается же это, путем повышения производительности.
В принципе, по каждому пункту в моей статье, пользователи наблюдают ускорение в работе. О пользователях мне тоже приходится думать, т.к. я сам являюсь пользователем ресурса ;)
Пункты моей статьи были действительно ориентированы на повышение производительности сервера (т.к. прижало), однако это не главная цель. Пользователям становилось не комфортно посещать ресурс, исправить это и было основной целью. Достигается же это, путем повышения производительности.
В принципе, по каждому пункту в моей статье, пользователи наблюдают ускорение в работе. О пользователях мне тоже приходится думать, т.к. я сам являюсь пользователем ресурса ;)
Мне нужна была иллюстрация к своим тезисам, Ваша статья подошла отлично. :)
Дело не в том, что Ваш (любого администратора) подход совсем уж плохой. Дело в том, что если посмотреть на проблему с другой стороны (end user), мы получим более полную картину. И, вполне возможно, некоторых действий, которые Вы описали в Вашей статье, можно было бы и не делать. Или делать другие.
Дело не в том, что Ваш (любого администратора) подход совсем уж плохой. Дело в том, что если посмотреть на проблему с другой стороны (end user), мы получим более полную картину. И, вполне возможно, некоторых действий, которые Вы описали в Вашей статье, можно было бы и не делать. Или делать другие.
А теперь пару слов в защиту «девелоперского» подхода.
Я тоже занимаюсь консультациями в области тестирования производительности, и иногда, когда я выслушиваю требования к производительности, у меня глаза на лоб лезут. С чего заказчик решил, что у него будет посещаемость веб-магазина сразу сто тыщ человек в день??? Это его маркетологи, оказывается, насчитали. Что-то на что-то умножили, и вот, получилось.
В такой ситуации как раз хорошо работает «прагматический» подход, который в статье назван «девелоперским». Сколько сейчас держит сайт? Пять тыщ всего? Ну и что — давайте запускать, зато уже сейчас, завтра, начнутся продажи. А когда посещаемость возрастёт до некоторой критической отметки, тогда уже и деньги будут для того, чтобы купить сервер подороже или заплатить программистам за оптимизацию. А то может эти сто тыщ никогда и не наступят.
Я тоже занимаюсь консультациями в области тестирования производительности, и иногда, когда я выслушиваю требования к производительности, у меня глаза на лоб лезут. С чего заказчик решил, что у него будет посещаемость веб-магазина сразу сто тыщ человек в день??? Это его маркетологи, оказывается, насчитали. Что-то на что-то умножили, и вот, получилось.
В такой ситуации как раз хорошо работает «прагматический» подход, который в статье назван «девелоперским». Сколько сейчас держит сайт? Пять тыщ всего? Ну и что — давайте запускать, зато уже сейчас, завтра, начнутся продажи. А когда посещаемость возрастёт до некоторой критической отметки, тогда уже и деньги будут для того, чтобы купить сервер подороже или заплатить программистам за оптимизацию. А то может эти сто тыщ никогда и не наступят.
а если, например, после размещения баннера, сайтик прилег на полдня, то эти «сто тысяч» могут вообще никогда не наступить.
Почему на полдня? Откатить изменения займёт минут 10-15.
какие изменения? вы одобрили интернет магазин на 5 тыщ. баннер пригнал 100. баннер снимать — деньги терять и магазин не ускорить в 20 раз за 10 минут. факап!
Ну а я про что — уменьшите частоту показа баннера, это займёт минут 15. В крайнем случае снимите его вообще. Деньги не потеряются ни при оплате за показы, ни при оплате за клики.
Господи, о чём люди беспокоятся! Покупателей слишком много! Поверьте, у большинства магазинов ровно противоположная проблема :)
Господи, о чём люди беспокоятся! Покупателей слишком много! Поверьте, у большинства магазинов ровно противоположная проблема :)
Оценка требований по производительности к системе — это отдельная песня. Но решать наобум, что 100 тысяч в сутки — это много, так что пусть будет 5 тысяч, а там посмотрим — это тоже пример плохой оценки.
Мне кажется некорректно сравнивать с врачебной ситуацией. Там как раз тестирование близкое к девелоперскому, ибо врач в точности знает как всё внутри пациента должно быть устроено (так же как разработчик имеет более менее точное представление о внутренних процессах но что-то может упускать из виду).
Перенося эту парадигму на тестирование нагрузочное, а я так понимаю вы пропагандируете тестирование по юзерским метрикам и общим данным без анализа исходного кода (ибо тестер не может его анализировать по определению ?), мы рискуем получить результаты ценность которых стремится к нулю. Нагрузочное тестирование сколько угодно умным и опытным тестером например вебприложения с многоуровневым кешированием и вытесняющимся кешем будет давать абсолютно протеворечивые результаты в зависимости от тестового сценария.
Пользовательские метрики в стиле время отклика, время загрузки ( особенно вне контекста зараченных ресурсов ) мне кажется дают картину не производительности ПО а качества конечного продукта.
Перенося эту парадигму на тестирование нагрузочное, а я так понимаю вы пропагандируете тестирование по юзерским метрикам и общим данным без анализа исходного кода (ибо тестер не может его анализировать по определению ?), мы рискуем получить результаты ценность которых стремится к нулю. Нагрузочное тестирование сколько угодно умным и опытным тестером например вебприложения с многоуровневым кешированием и вытесняющимся кешем будет давать абсолютно протеворечивые результаты в зависимости от тестового сценария.
Пользовательские метрики в стиле время отклика, время загрузки ( особенно вне контекста зараченных ресурсов ) мне кажется дают картину не производительности ПО а качества конечного продукта.
Любые аналогии — это всего лишь аналогии, а не соответствия.
Анализом исходного кода занимаются девелоперы, но им гораздо проще это делать, если QA скажет, где именно копать. Даже если это примерное направление (хотя обычно удается указать довольно точно).
Качество конечного продукта определяется в том числе его производительностью, так что здесь уже вопрос терминологии. Непринципиальный, на мой взгляд.
И, наконец, создание тестового сценария — это один из ключевых вопросов нагрузочного тестирования. Можно потратить массу времени и денег впустую, если сценарий создан неправильно.
Я полностью ответил на Ваш комментарий? Или Вы еще с чем-то не согласны?
Анализом исходного кода занимаются девелоперы, но им гораздо проще это делать, если QA скажет, где именно копать. Даже если это примерное направление (хотя обычно удается указать довольно точно).
Качество конечного продукта определяется в том числе его производительностью, так что здесь уже вопрос терминологии. Непринципиальный, на мой взгляд.
И, наконец, создание тестового сценария — это один из ключевых вопросов нагрузочного тестирования. Можно потратить массу времени и денег впустую, если сценарий создан неправильно.
Я полностью ответил на Ваш комментарий? Или Вы еще с чем-то не согласны?
Так и есть. Для большинства проектов лучше плохое/среднее решение сейчас, чем отличное через год. Потому, что через год этот проект может быть нафиг никому не нужен.
самопеар такой самопеар
пост ниочём.
пост ниочём.
Зря Вы противопоставляете подход админа/разработчика и тестирование скорости работы клиента. Это разные метрики, и сравнивать их не совсем корректно. Если у вас освободилось 30% процессора, это в любом случае очень хорошее достижение, даже если клиенты не заметят разницы в скорости. Хотя бы потому, что эти 30% можно занять чем-то полезным. Если вы разгрузили 10 машин на 30% каждую, вы можете освободить целых 3 машины! А клиенты ничего не заметят. По-моему, это офигенно.
> Возвращаясь к аналогии «врач-больной»:
> — Пациент, у вас теперь нормальная температура и состав крови, вы здоровы.
> – Но доктор, мне все еще плохо!..
Вы были в моей поликлинике? *SHOCKED*
> — Пациент, у вас теперь нормальная температура и состав крови, вы здоровы.
> – Но доктор, мне все еще плохо!..
Вы были в моей поликлинике? *SHOCKED*
Касаясь тестирования производительности было бы интересно рассмотреть вопросы поиска узких мест в ПО — во что именно упирается тот или иной продукт в данной системе. Но похоже ваши заметки будут про другое…
Что Вы имеете ввиду под «узкими местами в ПО»? Конкретно, условно говоря, куски кода, которые могут замедлять систему? Или что-то еще?
Есть, условно говоря, система. Закрытая — кода не посмотреть. Тормозит. Как определить во что в железе она упирается. Если с дисковой подсистемой все более-менее ясно, то вот производительность связки процессор-память уже не так очевидна.
В свое время пытался раскурить вот эту методику, однако докопаться до истинных причин так и не смог.
Хотелось бы почитать как искать узкие места в железе для высокопроизводительных систем.
В свое время пытался раскурить вот эту методику, однако докопаться до истинных причин так и не смог.
Хотелось бы почитать как искать узкие места в железе для высокопроизводительных систем.
Понятно.
Простой ответ — нужно иметь систему мониторинга (или утилиты, или консольные команды, не суть), по ряду показателей (CPU time, average load, memory ans swap usage, IO) можно определить, чего конкретно системе не хватает. В большинстве случаев этого хватает, чтобы понять, что «нужно докупить».
Насчет «хорошо бы почитать» — я собираюсь писать и о мониторинге тоже, поскольку это важная часть НТ. Вопрос в том — какие примеры выбрать. Очень простые — будет слишком скучно. А-ля «вот тут мы видим, что average load > 1, значит все плохо». Брать сложные — задолбаешься, прошу прощения, описывать.
Простой ответ — нужно иметь систему мониторинга (или утилиты, или консольные команды, не суть), по ряду показателей (CPU time, average load, memory ans swap usage, IO) можно определить, чего конкретно системе не хватает. В большинстве случаев этого хватает, чтобы понять, что «нужно докупить».
Насчет «хорошо бы почитать» — я собираюсь писать и о мониторинге тоже, поскольку это важная часть НТ. Вопрос в том — какие примеры выбрать. Очень простые — будет слишком скучно. А-ля «вот тут мы видим, что average load > 1, значит все плохо». Брать сложные — задолбаешься, прошу прощения, описывать.
Меня интересует несколько более узкая проблема — высокопроизводительные вычисления. Тут простыми счетчиками не отделаешься, ибо загрузка того же CPU всегда 100% (одного ядра), а swap usage 0.
Однако с ростом числа процессов (но не больше числа ядер) видно, что во что-то в системе они упираются… В общем наверное слишком специфичная задача.
Однако с ростом числа процессов (но не больше числа ядер) видно, что во что-то в системе они упираются… В общем наверное слишком специфичная задача.
Честно говоря, давно не встречал в веб-разработке, чтобы нагрузочное тестирование вообще не проводилось, даже если в ТЗ нет ни слова о нагрузке. Хотя бы для интереса нормальный разработчик посмотрит сколько генерируются различные (обязательно включая самые тяжелые с его точки зрения) страницы и даже оптимизирует бесплатно если на его взгляд слишком долго. Если же в ТЗ указаны параметры нагрузки (и методики их измерения), которые приложение должно выдерживать на заданном железе, то тут просто не сдать проект будет без тестирования. А нормальный админ заранее заметит необходимость оптимизации/масштабирования при плавном росте нагрузки.
«Баги» производительности могут быть, конечно, которые опытный тестер/тестировщик/тестист :) заметит, а разработчик своим «зашоренным» взглядом нет, но на мой взгляд, куда чаще случаются «баги» маркетинга, когда просто не верно указаны цифры в ТЗ (недооценили количество посетителей, их активность по времени суток, типичные сценарии поведения, максимально допустимые для них времена ответа и реакции и т. п.)
P.S. Хотя нет, вру, недавно плотно столкнулся с одним таким проектом, но всё же, имхо, это редкость
«Баги» производительности могут быть, конечно, которые опытный тестер/тестировщик/тестист :) заметит, а разработчик своим «зашоренным» взглядом нет, но на мой взгляд, куда чаще случаются «баги» маркетинга, когда просто не верно указаны цифры в ТЗ (недооценили количество посетителей, их активность по времени суток, типичные сценарии поведения, максимально допустимые для них времена ответа и реакции и т. п.)
P.S. Хотя нет, вру, недавно плотно столкнулся с одним таким проектом, но всё же, имхо, это редкость
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Два подхода к тестированию производительности. Выбираем