Подбираем эффективную конфигурацию под ваши нужды 
Отказ от ответственности.Всем привет! Меня зовут Иван Левиков, я старший инженер по тестированию.В этой статье мы рассмотрим конфигурацию, которую вы можете реализовать в своих проектах.
Имейте в виду несколько факторов:
• Результаты могут отличаться, если используются разные серверные машины.• Избыточные ресурсы не всегда хороши.
• Оптимизация оборудования должна идти параллельно с оптимизацией тестирования.
Во ВКонтакте я разрабатываю и ускоряю автотесты, анализирую и улучшаю инфраструктуру, создаю новые решения.
Проектируя инфраструктуру для автотестов на Android, приходится искать ответы на вопросы о Где можно запусти их и где лучше сделай это.
Давайте рассмотрим самые популярные места для запуска автотестов:
- облачные решения;
- решения на физических устройствах.
Облачные решения
В этой категории много предложений от разных компаний, например:- Амазонка,
- Испытательная лаборатория Firebase,
- Лаборатория Huawei DigiX,
- Удаленная тестовая лаборатория от Samsung,
- и другие.
В интернете много отзывов, поэтому не будем на этом останавливаться.
Если вы не хотите использовать внешние решения, а хотите построить что-то свое, вы можете обратиться к комбинации OpenSTF и физического устройства или к эмуляторам Android-устройств.
Давайте рассмотрим каждый вариант немного подробнее.
OpenSTF + физическое устройство
В нашем опыте будет использоваться Samsung Galaxy S20+ (6 ядер, 8 ГБ).По характеристикам это достаточно мощное устройство (см.
рейтинг производительности ), и его программное обеспечение будет обновляться еще долгое время.
Давайте воспримем это как эксперимент. 
Вот так выглядел один из первых прототипов нашей фермы.
Собран из смартфонов Samsung, которые питаются через USB-хаб и подключаются к ноутбуку с локально развернутым OpenSTF. Вы можете поиграть в «Угадай модель устройства по фото».
Мы жили так довольно долгое время, управляя физическими устройствами через OpenSTF. Несмотря на очевидные преимущества, были и трудности – перечислю их ниже.
Мы столкнулись со многими проблемами: например, с очисткой данных, закрытием всплывающих окон, падением производительности и странными тестовыми флагами.
В то время как мы регулярно занимались другими недостатками, отладка и отладка проваленных тестов становились ресурсоёмкими задачами.
В некоторых случаях это было связано с текущим состоянием устройства, а в других, похоже, было связано с фазой Луны и ретроградного Меркурия.
Ферма с виртуальными Android-устройствами
Мы решили провести разные эксперименты для повышения стабильности.Прежде всего нам необходимо улучшить нашу ферму, но не за счет покупки новых физических устройств, как обычно, а за счет создания параллельной фермы эмуляторов.
В итоге остановились на конфигурации с виртуальными Android-устройствами.
Мы начали с построения фермы из комбинации уже знакомых эмуляторов OpenSTF и QEMU. «Из коробки» наши эмуляторы в стандартной комплектации имели 2 виртуальных ядра и 4 гига ОЗУ.
В целом они нас устроили по производительности и жизнеспособности.
Но для некоторых ситуаций приходилось создавать свои решения: например, превентивно прогнозировать возможную деградацию эмулятора и провалы тестов из-за этого.
Винрейт (соотношение проваленных и пройденных тестов) в исходном состоянии из коробки составлял в среднем около 65%, а автотесты обнаруживали ошибки.
Ищем оптимальную аппаратную конфигурацию для эмуляторов
Но меня все равно не устраивало положение дел, поэтому я отправился в долгое приключение в поисках стабильности.Цель: найти оптимальную аппаратную конфигурацию эмуляторов.
Нашёл пару статей и readme в репозитории Google : они рекомендовали использовать конфиг на 4 виртуальных ядра и 12 гигов оперативки.
Я задавался вопросом, почему это так.
Что произойдет, если вы дадите больше или меньше? Меня заинтриговали эти вопросы, поэтому я решил углубиться в них.
Казалось бы, придется долго придумывать способ оценки производительности и сравнения нескольких конфигураций между собой.
Но все оказалось не так просто: в ходе работы нам пришлось делать массу анализов производительности и искать причины появления OOM (Out of Memory).
Поэтому это путешествие было непростым.
Это и стало тем самым «20-минутным приключением» — на полгода :) 
Я сравнил производительность эмуляторов и физических устройств, чтобы понять, куда мы движемся и не становится ли хуже.
Я обнаружил, что в текущей конфигурации разница во времени выполнения автотеста между эмулятором и физическим устройством составляет всего 12%.
Может показаться, что это много, но у меня было четкое ощущение, что мы можем выжать больше.
Сейчас я расскажу вам, как мы это сделали! В начале экспериментов я протестировал множество конфигураций серверных машин, которые использует ВКонтакте: от старенького Xeon E5-2680 до Xeon Gold 6283. Как это часто бывает, самое крутое железо не всегда подходило для наших задач.
Именно это и произошло с Xeon Gold: крутой частоты процессора можно было добиться только за счет отключения части ядер.
В противном случае под нагрузкой частота могла колебаться даже до 0,8 ГГц.
Плюс ко всему, немалую роль играет размер кэша L3. 
После первых подходов мы оценили результаты и решили остановиться на старом добром E5-2680. Поэтому мы выбрали серверные машины для следующего этапа.
Собирая серверные машины для экспериментов, я сформулировал для себя следующие вопросы ↓ 
Представим, что все машины собраны и эмуляторы подготовлены.
Что делать дальше? Правильно, мы собираем набор автотестов для оценки производительности различных разделов нашего приложения.
Таким образом, за короткое время мы получим больше данных, максимально приближенных к реальным.
Возьмем за стандарт среду выполнения на хорошо известном нам физическом устройстве — S20+.
Тренажеры собраны и определены конфигурации.
Начинать! На первом этапе мы оценили изменение времени работы для каждой из этих конфигураций.
В первом раунде в сравнении с S20+ была получена следующая таблица.
На еженедельном подведении итогов спринта мы с командой обсудили показатели и пришли к выводу, что результаты интересны и нужно продолжать экспериментировать, расширяя тестируемые значения.
Казалось бы, давайте возьмем и реализуем самый мощный конфиг, чтобы тесты запускались на 30% быстрее.
Но не все так просто, ведь в нашем уравнении еще есть несколько неизвестных.
Давайте копать дальше! На разных устройствах и эмуляторах я сталкивался с ситуацией, когда автотест вылетает, скажем, после шестого непрерывного запуска.
И где-то после третьего.
Или вообще не вылетает в первые десять запусков.
Это привело меня к мысли, что стабильность автотестов зависит еще и от конфигурации оборудования.
Эту гипотезу необходимо было проверить, прежде чем двигаться дальше.
В результате экспериментов были обнаружены следующие закономерности снижения тестов.
Это уже выглядит интереснее! В наш список вошли три конфигурации: 6-ядерная, 5-ядерная и 4-ядерная.
Попробуем разобраться, какие из них могут быть нам интересны и почему.
Для этого мы расширим конфигурации в пределах 4 и 5 ядер, добавив в эмуляторы оперативной памяти.
Неплохо, неплохо.
Получается, что нашим минимальным кандидатом обязательно будет конфигурация из 5 виртуальных ядер и 5 или 6 гигов ОЗУ.
Давайте попробуем опираться на эти ценности.
Во время прогонов эмуляторы иногда самопроизвольно выключались — и над этим мы ломали голову.
Мы подробно изучили логи и графики мониторинга и поняли, что это банальный ООМ.
Означает ли это, что эмулятору не хватает N гигабайт оперативной памяти, которую мы ему выделяем? Да все верно.
При создании более мощного конфига потребляется больше ресурсов — поэтому для безаварийной работы нам нужно зарезервировать даже больше, чем мы выделяем.
В процессе запуска автотестов наши эмуляторы разгонялись не сразу, а постепенно, иногда резко уходя вверх.
Путём экспериментов мы поняли, что для мирного существования эмуляторам желательно предусмотреть дополнительные ресурсы: минимум 1,5 гигабайта оперативной памяти и 1 ядро vCPU, помимо уже выделенных.
Это пригодится для нужд Java-кучи и модулей.
Но в целом такое решение сгладит скачки, повысит жизнеспособность эмуляторов и защитит вас от нестабильности в тестах из-за аппаратного обеспечения.
Что реализуем в итоге (и что учитываем)
Остановимся на базовой конфигурации эмулятора 6 VCPUS/6 ГБ и добавим сверху минимум 1,5 гигабайта ОЗУ.По расчетам мы ожидаем, что по сравнению с текущим конфигом эмулятора новый позволит ускориться на 20% и более.
А самое главное, это повысит стабильность прогонов автотестов — и мы будем в них увереннее.
Потом кратко поделюсь своими выводами.
Вот что важно не забыть при реализации конфига в своем проекте ↓ 
Вот некоторые вещи, которые следует учитывать при планировании экспериментов:
- Начать можно с конфигурации с 5 или 6 виртуальными ядрами для мощного эмулятора и 5,5 гигами ОЗУ для эмулятора.
- Разрыв между ядрами начал уменьшаться после 5 ядер (разница между 5 и 6 составляет около 1,5%).
- Увеличение оперативной памяти на 1 гигабайт дает прирост скорости до +0,5%.
- Избыточные ресурсы не всегда хороши.
- При изменении аппаратного обеспечения эти значения также могут стать другими.
А если вы хотите прокачать свои автотесты в нашей команде, посмотрите вакансии Здесь .
Давайте будем ВКонтакте! Теги: #Intel #Разработка мобильных приложений #it-инфраструктура #Kubernetes #вконтакте #Тестирование мобильных приложений #Тестирование ИТ-систем #Xeon #QEMU #OpenSTF #VKSTF
-
Интернет-Маркетинг Полон Проблем И Наград
19 Oct, 24 -
Скорость Флешек (Usb-Флешка)
19 Oct, 24 -
Railsclub 2016: Интервью С Заком Бриггсом
19 Oct, 24 -
Я Избранный
19 Oct, 24
