gSqwcw1lvFU

В чате автоматизаторов всё чаще возникают подозрительные вопросы. «Пацаны, посоветуйте, как с помощью webdriver нагрузить приложение?» У данного вида ереси даже начали появляться апологеты.  Давайте же разберёмся, что является глубинной причиной заблуждений этих еретиков.

А причины тут такие: низкий уровень инженерной культуры и желание с наименьшими (по их мнению) трудозатратами провести тестирование.

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

100 browsers

Поднимаем виртуалку с нашим приложением. Поднимаем 25 виртуалок клиентов (по 4 браузера на каждой)  и selenium grid. А, ну ещё машину с нашим тестовым кодом.  Вроде всё отлично. Запускаем…  Предположим, что мы получаем результаты после прогона. Теперь идём к заказчику с результатами, где нас ожидает предсказуемый разговор:

— Ну как, нагрузили приложение с помощью функциональных тестов?

— Да.

— Ну, и каков результат?

— А ну хер его знает. Чёт тупит)))))))))))))))

Результатом такого тестирования, если вы действительно нагрузили, станет тонна скриншотов и стектрейсов с ошибками. Все бережно расставленные вами слипы по 1.0025 секунд ничего не дадут, и всё свалиться к херам.  И вам придётся всё это говно после прогона разгребать большой лопатой (100 браузеров, Карл!). Конечно, в этот момент должны появиться дяди из EPAM со своим репорт порталом, но пока он не в опенсорс, так что извини, чувак.

Если вы геройски разгребёте всё это говно, то как узнать, что стало причиной ошибки? Затупил Back End? JS на Front End не справился? Может сам грид стал бутылочным горлышком? Что? Дай Бог, чтобы ответ скрывался в логах или в результатах профилирования (вы же подключили анализатор, верно?).  Хотел бы посмотреть, как вы объясняете программистам, что вы от них хотите, а главное, как это воспроизвести.

Теперь перейдём к любимому заказчиками аспекту вопроса: БАБОСИКИ!  Не считая человека-часов, потраченных на анализ результатов, и ещё человека-часов, которые потратит программист на то, чтобы понять, в чём причина, суть касается машинных ресурсов.  Вот вам, для затравки, скриншот taskmanager’a с моего компа.

taskmanager

Девственно чистый и запущенный «вот только что» Фаервокс изволил откушать 200 метров моей драгоценной оперативки. Теперь умножим это на 100 и получим примерно 20 гигабайт! Теперь добавим грид, сами тесты и на пиво. И, вуаля! 25 ГБ только оперативной памяти, только со старта! Самое время вспомнить фразу моего коллеги C-ка:  «Да вы охуели, 8 килобайт им не существенно!» Процессорное время я считать не берусь… Тупенький. И то, что вы эти виртуалки рисуете на раз-два, не отменяет того факта, что это ресурсы.

Ах, да! Чуть не забыл. Ещё у вас встанет вопрос с администрированием этого зоопарка и с утилизацией ресурсов после теста. Думаю, ваш заказчик не очень будет рад, что вы вместо рабского написания новых тестов будете тратить время на администрирование.

Конечно, адепты сей ереси скажут: «Так мы всю хуйню запустим в облаках, купим за копейки». Как бы дёшево это не стоило, всё равно идут БАБОСИКИ!  Если вы хотите запускать тесты постоянно (а вы же хотите?), то в конце года вам придёт внушительный чек.

Вывод напрашивает один: «Не делайте так!»


 

«Но, но…, — cкажете вы. —  Задача есть, как же нам её решать?» Давайте пофантазируем.

А что, если мы всё-таки вспомним свои инженерные корни и потратим немножечко времени на изучения Jmeter, написание пары простеньких скриптов для нагрузки и нагрузим сервер по-людски. Тогда схема будет примерно такая.

jmeter

В итоге имеем тачку с Jmeter скриптами, которые нагружают сервер как надо, и комп с вашими тестами, которые пытаются что-то там в браузере проверить. Говорят, для Jmeter уже сделали семплер для работы с WD. В общем, ресурсов тратится меньше, пользе в такой системе больше. Уже можно точно по хитам Jmeter сказать, какая часть api не соответствует требованиям и что нужно фиксить на бэкенде. Но вот браузер с end to end скриптами выглядит пятым колесом. Конкретно нельзя сказать при падении тестов, что стало причиной, если по таймингу не сравнивать время хитов из Jmeter и падение тестов в WebDriver. В общем, о производительности своего фронтенда вы всё равно будете знать мало.


 

А что, если начать тестировать производительность фронтенда и бэкенда отдельно? Что, если бэкенд нагружать отдельно, а фронтенду отдавать некорректные ответы или ответы с большим объёмом данных? Да ещё максимально изолировать фронтенд от бэкенда? Из плюсов мы получим возможность тестирования производительности отдельно, что избавит нас от нагрузки на бэкенд. Экономия ресурсов. Всегда понятно, что не работает. Предлагаемая мною схема будет такая.

true_way

Фронтенд отделен от бэкенда прокси сервером, который позволяет перехватывать определённые запросы и отправлять вместо реального ответа от бэкенда либо ответы с ошибками, либо задерживать запросы на определённое время. Конечно, если у вас в функциональных тестах бережно расставленные слипы, то скорее всего всё будет валиться. С другой стороны, это отличный повод, чтобы всё отрефакторить и переделать. Поверьте мне, написать такой прокси не составит труда. Лично писал похожее на Jetty за пару часов.

Бонусом вы получите возможность проверки работы вашего фронтенда на медленном интернете.  Про это есть поучительная история о факапе, который произошёл с продуктом одной крупной компании.

Однажды на сервис одной крупной и известной компании начался DDOS! Странно было то, что пользователей у этого сервиса было немного, да и конкурентам он не особо мешал. Но DDOS шёл, примерно с 10 часов утра и до 6 вечера. Компания обратилась за помощью к другой компании, которая специализируется  на защите от подобного рода атак. Спецы проанализировали атаку и пришли к выводу, что это серьёзный ботнет, причём ещё браузерный, имитирующий реальных пользователей. Начали резать  и банить этот злой ботнет. Но, как потом оказалось, резали они реальных пользователей. В JS была ошибка, которую не найти на быстром коннекте. Суть в том, что фронтенд отправлял запрос и, если не дожидался ответа за несколько секунд, то отправлял запрос повторно. И так бесконечно…

Так что тестирование производительности фронтенда  — это важно. Но не через жопу же.

P.S: Автор данной заметкой не хочет никого обидеть, но вы инженеры, блять! Во время работы всегда задавайте себе два вопроса: «Зачем?» и «Можно ли это сделать с меньшими затратами?»

Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс