Test the best
Чем занимается performance analyst?
далее
Галлерея белорусских программистов. Прежде чем приступить к публикации...
далее
Опыт о работе в Microsoft из первых рук. А также о собеседованиях в Go...
далее
 
 
техника
люди
СПОНСОРЫ
EPAM Systems
генеральный спонсор
ПАРТНЕРЫ
белорусский портал TUT.by
"Компьютерные Вести On-line"
компания Softline
портал белорусских программистов
Первый Белорусский Linux-портал
интернет-магазин Trinity.by
TECHLABS - Новости компьютерного рынка
СТАТЬИ / разное
  Специалисты по анализу производительности и оптимизации программного обеспечения: рваться не должно даже там, где «узко»

После 11 сентября 2001 г. в течение нескольких дней трафик на новостной сайт Microsoft был в три раза выше обычного уровня. В результате время отклика возросло до неприемлемого уровня, а веб-серверы приходилось перезагружать каждые два часа из-за критического падения объема доступной памяти. Позже было установлено, что это происходило из-за утечек памяти, которая происходила на сайте и ранее.


Угроза нестабильной работы сайта волнует большинство компаний, использующих веб-приложения для ведения своего бизнеса. Предупредить и устранить ошибки и угрозы помогают специалисты по анализу производительности и оптимизации программного обеспечения (performance analysts). Сегодня мы беседуем с представителями этой ИТ-профессии – специалистами отдела нагрузочного тестирования компании EPAM Systems.

- Какие приложения чаще всего тестирует performance analyst?
- Как правило, это многоуровневые веб-ориентированные приложения. В компании EPAM Systems мы занимается тестированием проектов как созданных нашими программистами, так и полученных от сторонних заказчиков.
Таким образом, у нас есть определенное веб-приложение и «железо», обеспечивающее его работоспособность. И заказчик хочет знать, одновременную работу скольких пользователей в данных условиях приложение сможет выдержать, а также желаемую или абсолютную максимальную нагрузку не только ПО, но и «железа» вкупе.

- Как имитируется среда заказчика?
- Мы ставим программное обеспечение, соответствующее один к одному софту заказчика, или во всяком случае тех же версий, то же «железо» и создаем такую же пропускную способность канала.

- Как пошагово выглядит процесс тестирования?
- По рекомендации заказчика база набивается данными. Пишется эмуляция реального пользователя – скрипт, имитирующий работу одного человека, который будет совершать стандартный для обычного пользователя набор действий: заходить в веб-приложение, переходить по страницам, что-то искать. Далее берется программа, запускающая этот скрипт с определенным количеством пользователей, и они все одновременно выполняют заданный нагрузочный сценарий. После такого тестирования обнаруживаются «узкие» места веб-приложений. Или не обнаруживаются и заказчик получает гарантию, что все будет корректно работать, если такое количество посетителей одновременно к нему придет.
Может быть написано несколько скриптов, которые потом будут запускаться параллельно: к примеру, 50 пользователей - серферы, т.е. просто ходят по веб-приложению случайным образом и якобы просматривают некоторую информацию; второй скрипт – предположим, заходит на сайт, авторизуется как зарегистрированный пользователь и выполняет какие-то функции по работе с внутренними данными. А сценарий - это разделение/раздача N-ного количества виртуальных пользователей скриптам для работы в течение какого-то времени, плюс снятие данных по загрузке железа и ошибкам.

- Какое программное обеспечение стандартно используется?
- Стандартно это редактор скриптов, эмулирующих обращение к серверу, и программа, которая запускает N-ное количество пользователей, а также инструменты для мониторинга и сбора статистики.

- На что больше похожа эта работа: на проверку надежности приложения по определенному списку технических требований или стандартов; или на «творческий осмотр» приложения с точки зрения юзабилити, логики и т.п., когда ты обращаешь внимание не на то, что указано в списке, а на то, что «режет» глаз?
- Проверка юзабилити относится скорее к компетенции функционального тестирования.

- С кем вам приходится решать больше вопросов - с разработчиками или с самим заказчиком?
- Общение с заказчиком чаще происходит в самом начале проекта. Он определяет область веб-приложения или все приложение со всем функционалом, где будет проводиться тестирование. В дальнейшем общение идет с разработчиками: мы получаем билд, начинаем его тестировать; если все начинает «сыпаться», то отсылаем список замечаний программистам, они вносят изменения и выпускают новый билд.

- Как вы в своей работе пересекаетесь со специалистами по функциональному тестированию?
- До того как попасть к нам на тестирование, приложение должно пройти определенные этапы функционального. Плюс существуют различные вопросы, связанные с бизнес-логикой, которую хорошо могут знать тестировщики. Тогда они нас консультируют.

- Вспомни, пожалуйста, примеры глюков, которые вам удалось отловить?
- Довольно часто мы замечаем deadlock’и – ситуацию, когда работа двух пользователей с одной, допустим, таблицей одновременно невозможна: если работает один, для второго она блокируется.
Часто замечаем, что веб-приложение не совсем адекватно работает при нажатии пользователем кнопки F5 (обновить): например, счетчик после прорефрешивания страницы засчитывает посетителя как нового; или при отправке сообщений через формы после обновления посланный текст появляется на странице еще раз. Чтобы избежать этого, мы рекомендуем проверять посетителей и сообщения на уникальность.
Кроме того, часто в веб-приложениях, где допускается авторизация пользователей, посетитель, который ввел свой логин и пароль, не может сразу понять, залогинился он или все еще является «анонимным» юзером. А это должно четко показываться. Иногда мы обнаруживаем накопление данных в памяти, которое происходит из-за некорректной очистки используемой памяти. В результате этого вся доступная память исчерпывается и сервер «виснет».

- Какие самые «узкие» места у веб-приложений, где чаще всего выявляются какие-то проблемы?
- Чаще всего это динамический поиск и обновление данных в базе. Поиск в больших объемах данных может выполняться долго, при этом происходит загрузка процессора, и сервер может «упасть». При обновлении данных и закачке больших объемов информации объем базы также быстро растет, из-за этого замедляется работа приложения, и сама база данных может перестать работать. Мы советуем, где и как хранить данные, как подправить index, чтобы все работало быстрее, даем рекомендации как по программным, так и по хардверным кластерам, по настройкам параметров, баз, веб-приложений, систем и т.п.

- Что происходит на этапе анализа результатов тестирования?
- Как правило, анализируется время запросов и откликов по цепочке: клиент – веб-ресурс -- база данных – веб-ресурс – клиент. И в зависимости от времени запроса/отклика и анализируется ситуация: "где именно", "почему долго" и "как это исправить". То есть после тестирования берется определенная цепочка, время выполнения которой нас не устраивает, "где именно", и раскладывается по составляющим от http-запросов клиента до SQL-запросов в базе, определяется причина "почему долго" и от чего это зависит. И после этого формулируется "как это исправить" - т.е. наши рекомендации разработчикам.

- Где в РБ можно получить образование для последующей работы performance аналитиком, и какой предыдущий жизненный опыт в этом помогает?
- Что касается образования, то нигде. По КЗОТу вообще нет такой профессии – есть только программист. Поэтому все навыки, необходимые в этой работе, приходят только с опытом: нужно очень много работать с веб-приложениями, знать, как они устроены и как должны функционировать, и тогда, посмотрев на внутреннюю организацию работы приложения, человек может сказать, где возможно находится «узкое» место. Такие люди и становятся специалистами по анализу производительности и оптимизации программного обеспечения.

Вакансия специалиста по анализу производительности и оптимизации программного обеспечения в EPAM Systems


  все статьи раздела "разное"

назад на