В этой статье мы поговорим о важном аспекте тестирования, с которым столкнулись в работе над одним из наших продуктов — шлюзом веб-безопасности Solar WebProxy (Secure Web Gateway, SWG). Эта система защиты, которую еще называют веб-прокси, контролирует передачу данных между сотрудниками, внутренними ресурсами организации-клиента и интернет-ресурсами.
Одна из ключевых задач при разработке такого продукта — это сайзинг, или подбор железа. Клиенты, как правило, не знают, какой профиль трафика у них планируется в зоне ответственности нашего продукта. Даже если бы такая информация у них была, сопоставить результаты синтетических нагрузочных тестов с реальностью крайне сложно и для реальных подсчетов они не подходят. В результате после запуска решения в эксплуатацию компания может столкнуться с нехваткой ресурсов или, напротив, с их простоем.
Чтобы решить эту проблему при создании Solar webProxy, мы разработали собственный калькулятор производительности, который дает нам и заказчику реальное представление о ресурсах, необходимых для эффективной работы нашего веб-прокси.
По каким показателям оценивать производительность SWG
В стандарте RFC 9411, который описывает подходы к бенчмаркингу сетевого оборудования, оценивать эффективность продукта предлагается по следующим показателям:
CPS (Connections Per Second) — количество новых соединений в секунду.
CC (Concurrent Connections) — количество одновременных соединений.
Throughput — пропускная способность.
Обычно для каждого из этих показателей проводят отдельные тесты со своими профилями нагрузки. Конфигурация тестов подбирается так, чтобы результаты были как можно привлекательнее. В результате, к сожалению, они имеют мало отношения к реальной практике использования SWG.
Между тем нагрузочные тесты — главный инструмент для прогнозирования работы продукта с разным количеством конечных пользователей. Например, для компании с тремя филиалами и 100 сотрудниками в каждом требуется одна производительность, а для компании с миллионом сотрудников — совсем другая.
Нагрузочное тестирование также позволяет нам определить требуемые аппаратные ресурсы: количество процессоров, объем памяти и жестких дисков. Это позволяет клиентам заранее оценить, соответствуют ли их текущие мощности требованиям продукта.
Ищем нужный профиль
Для начала мы попытались определить, как должен выглядеть профиль нагрузки для SWG. С этой задачей мы потерпели фиаско — информации в свободном доступе оказалось маловато. Поэтому мы стали самостоятельно прорабатывать варианты: сопоставляли количество пользователей с числом запросов в секунду (requests per second, RPS), который Solar webProxy обрабатывает в соответствии с определенным временем отклика на запросы.
Мы изучили наиболее ресурсоемкий функционал, однако профили, которые получались на основе этих данных, оказались слишком тяжелыми и нереалистичными. В итоге после нескольких промахов мы составили портрет среднестатистического пользователя, который выходит в интернет через Solar webProxy. В дальнейшем аналитики подтвердили, что это наиболее частый сценарий использования нашего продукта.
Стоит отметить, что аналитики могут предоставить очень ценные входные сведения по нефункциональным требованиям. Подробнее об этом — в статье «Как задавать требования к качеству ПО в цифрах» — почитайте, чтобы разобраться, как описать требования к SWG.
Описываем среднего пользователя
Понять, как выглядит среднее потребление трафика в крупных сетях, нам помогла статья «Network: capacity planning, среднее потребление трафика в крупной сети». Кроме того, мы нашли интересный комментарий по количеству одновременных соединений на странице How Many Concurrent TCP Connections Does An Average Internet User Consume:
Типичный компьютер Windows с обычным набором стандартного ПО всегда будет иметь 10-15 подключений, используемых только для таких вещей, как базовая проверка обновлений, телеметрия и синхронизация данных. Число подключений может кратковременно достигать 50-100 после загрузки/входа в систему, поскольку все фоновые приложения при запуске выполняют свои проверки.
Веб-браузеры обычно держат открытыми 3-5 подключений для каждой вкладки/окна, даже если они не активны. Цифра может легко увеличиться до 15-20, если на вкладке запущено онлайн-приложение, например веб-приложения Microsoft Office, Google Docs, SharePoint и т.д.
При загрузке, перезагрузке или обновлении любой страницы браузер может кратковременно открыть 10-50 дополнительных подключений, чтобы загрузить различные части веб-страницы. Страницы с большим количеством рекламы могут действительно увеличить это значение, если пользователь не использует плагин-блокировщик. Также имейте в виду, что многие рекламные баннеры загружают код для автоматического обновления каждые X секунд, даже если пользователь сделал эту вкладку неактивной или свернул ее.
Очевидно, имеет большое значение количество вкладок браузера, которые ваши пользователи обычно держат открытыми непрерывно в течение дня и насколько интенсивно обновляются эти страницы.
Если все это сложить, получаются следующие выводы:
Неактивные пользователи: в среднем 30–50 подключений → пики до 120–250
Активные пользователи: в среднем 60–100 подключений → пики до 250–500
Хорошая новость в том, что пики есть пики. Не у всех они бывают в одно и то же время.
На основе данных аналитики и ожиданий архитекторов мы выбрали показатели в качестве отправных точек для описания среднестатистического пользователя:
Throughput=2 Мбит/c,
CPS=5,
CC=30.
Далее мы приступили к работе над сборкой профилей для каждого показателя отдельно. В результате, стало понятно:
CC не является узким местом.
CPS был без контента внутри, поэтому показатель выглядел нереалистично.
Профиль с Throughput оказался наиболее близок к тому, что нам было нужно.
Собираем статистику для составления В Solar webProxy все ориентировано на проверку контента, основной поток которого зачастую идет от браузеров. Следовательно, нам нужно было собрать статистику работы пользователей. На помощь пришел ресурс The HTTP Archive — мы использовали статистику загрузки страниц в интернете за один год.
Получается, что трафик формируется из 6 типов файлов (тип «другие» мы исключили из-за незначительного объема). В статистике указан общий размер каждого типа на странице и количество его запросов.
Путем нехитрых математических вычислений мы получили средние размеры необходимых файлов. Для более точного позиционирования профиля к основному функционалу продукта мы увеличили набор файлов: добавили один POST-запрос, DOC-файл для проверок фильтрации текстовой информации и тестовый вирус с EICAR для проверки работы встроенного в Solar webProxy антивируса.
В реальности при загрузке среднестатистического сайта открывается сразу несколько соединений, а запросы могут выполняться параллельно. Поэтому мы выделили по соединению на каждый тип файла и дополнительное соединение для DOC и EICAR.
Время отклика мы оценивали по выполнению всех запросов для полной загрузки синтетического сайта, за исключением добавленных DOC и EICAR, которые нужны для отдельных проверок.
Выбираем генератор нагрузки
В качестве генератора нагрузки используем JMeter с плагинами, а в качестве целевого сервера — Nginx. Много времени потратили, чтобы разобраться, как JMeter открывает соединения и выполняет запросы.
Интенсивность подаваемой нагрузки у нас регулируется количеством потоков thread.
Можно было бы использовать и другие генераторы нагрузки, предназначенные для тестирования сетевого оборудования. Однако всегда находились нюансы, которые не позволяли нам полноценно это делать.
К примеру, TRex не умеет создавать настоящий HTTPS-трафик. Отсутствие настроек прокси тоже не добавляет удобства. IXIA умеет генерировать HTTPS, позволяет добавлять файлы в запросы, имеет интересные настройки по рандомизации контента, обеспечивает высокую точность. Но в больших отчетах нам все равно не хватило нужной информации. Кроме того, нельзя настроить авторизацию пользователей с разными методами аутентификации. Не удалось настроить и явный прокси, хотя в документации эта возможность была указана. Для разработки этого профиля JMeter нам подходит больше всего.
Создаем нагрузочный стенд
Схема нагрузочного стенда проста, но в то же время идеально отражает суть использования Solar webProxy.
Универсальность нашего профиля позволяет сочетать его с политиками безопасности разной сложности, от чего серьезно зависит производительность всей системы. Для тестов мы зафиксировали несколько политик с градацией сложности от легких до сверхтяжелых.
Учитывая основные сценарии использования Solar webProxy, весь трафик в профиле — это HTTPS, и даже на легких политиках мы вскрываем трафик на 100%. Хотя в реальности обычно допускается часть трафика, на которую не распространяются правила вскрытия.
Формируем критерии успешности
В первую очередь мы оцениваем время отклика — загрузку всех файлов с имитированного сайта на 99 перцентиле. Так как из статистических данных мы взяли средний сайт, то критерий отклика подбирался субъективно, чтобы пользователь не замечал долгой загрузки страницы размером 3.1 МБ.
Мы решили, что 800 мс будет в самый раз, кроме случаев с политиками, где весь трафик передается на проверку антивирусу. В таких ситуациях получить время отклика меньшее или равное 800 мс не удается даже на низкой нагрузке.
Нагрузка у нас подается ступенями и регулируется количеством thread. Каждая ступень длится 20 минут, в дальнейшем отбираются ступени, на которых время отклика удовлетворяет и не удовлетворяет требованиям. Проводится тест для подтверждения найденных значений, после чего в данных мониторинга стенда мы берем среднее значение пропускной способности (throughput) в течение той ступени, где время отклика было максимально близко к порогу 800 мс, но не превышало его.
В заключение — важные детали
Помимо ресурсоемкого вскрытия HTTPS, в Solar webProxy есть много фич, которые вносят задержки в обработке. Например, поиск ключевых слов — очень трудозатратная операция, особенно, если таковой поиск делается через регулярные выражения.
Если ключевых слов для поиска будет много, объем файлов с текстом будет влиять на результат. Нельзя не упомянуть функцию проверки по типу файлов, ведь системе нужно не просто определить каждый файл по расширению, а посмотреть его структуру. Некоторые файлы могут требовать на это больше времени, чем другие. Чтобы правильно измерить производительность, в профиле должен быть контент, который будет проверяться функцией, включаемой в политику.
У каждой компании будет свой профиль нагрузки и свои наборы рабочих политик, которые практически невозможно рассчитать предварительно с точностью 100%. Планируемые расчеты вендора всегда будут приближенными к реальности, но не отражающими ее полностью. Поэтому, один из лучших подходов к внедрению Solar webProxy — пилотное внедрение и оценка нужных конфигураций в рабочем процессе.
Мы используем контент-профиль нагрузки и политики, чтобы учесть специфические потребности клиентов и точно рассчитать производительность, необходимую для удовлетворения их требований. Это гарантирует, что клиенты получат оптимальное решение, которое соответствует их бюджету и ожиданиям по производительности.
Владимир Орлов
Инженер 1 категории ГК "Солар"
Александр Калачев
Инженер 1 категории ГК "Солар"