Извините, если это новый вопрос ...
Я слышал истории о том, что Netflix и Twitter могут дублировать веб-трафик между двумя отдельными инфраструктурами: одна из них является авторитетной / надежной, которая возвращается пользователю; а другой - «теневая» или тестовая инфраструктура, которая думает, что возвращается пользователю, но не возвращается. Дело в том, чтобы протестировать вторичную инфраструктуру при реальной нагрузке и времени.
Я почти уверен, что есть слово, чтобы описать это, но «мост» мне не подходит, как и «повтор».
Может ли кто-нибудь помочь мне с тем, как называется этот метод и / или какие инструменты можно использовать для этого?
Думаю, я должен добавить, что слышал о методах, которые эффективно «воспроизводят журналы», но это действительно сложно получить на реальных скоростях / распределениях.
И мы не пытаемся проверить «правильность» вывода, а просто следим за тем, чтобы мы не видели ошибок / трассировок стека и т. Д. В новой инфраструктуре.
Лично я бы назвал это «нагрузочным тестированием через воспроизведение сеанса». Я не знаю простого универсального термина для такого рода техники тестирования.
Основная стратегия, которую я видел, применяемая для такого рода нагрузочного тестирования, - это получение файлов журнала из производственной системы и их воспроизведение в тестовой системе.
Вы можете использовать такие инструменты, как JMeter или Скамья Apache для воспроизведения запросов из файлов журнала. Если вы хотите воспроизвести очень сложные взаимодействия клиент / сервер (с конкретными деталями времени, основанными на исходном потоке журнала) в надежде по-настоящему задействовать внутренности вашего приложения (поиск условий гонки, ошибок, связанных со временем и т. Д.), Вы можете посмотрите на создание инструментов тестирования для конкретных приложений, которые имитируют клиентов в большом масштабе.
Вы не сможете просто захватить множество необработанного сетевого трафика и «воспроизвести» его с помощью любого протокола на основе TCP или IP. Порядковые номера TCP не будут соответствовать исходному перехваченному трафику, и это не сработает. Захват IP-уровня будет проблематичным, потому что ваши смоделированные клиенты должны будут отвечать за захваченный IP-адрес отправителя. Вам будет лучше захватывать трафик ближе к уровню 7 и использовать его для воспроизведения сеансов, потому что в противном случае вы также планируете написать симулятор TCP. (Я мог представить себе что-то вроде tshark для извлечения данных и времени уровня 7 из потока TCP и их воспроизведения, например.)
Простое воспроизведение сетевого трафика имитирует нагрузку, но не обязательно фиксирует дефекты. Ваш смоделированный клиент должен будет получать ответы от тестового сервера и анализировать их на правильность, если вы хотите провести нагрузочный тест. любой проверьте, что приложение правильно отвечает. Поскольку ваше приложение будет генерировать данные динамического ответа, маловероятно, что ваш смоделированный клиент сможет просто сравнить ответ тестового сервера с зарегистрированным ответом рабочего сервера. Здесь вы собираетесь написать программу тестирования, специфичную для вашего приложения и его вывода.
Вы пользуетесь такой услугой, как BrowserMob который имитирует одновременный доступ множества людей к вашему сайту. Эти службы не воспроизводят зарегистрированный трафик, потому что в этом случае вам будет не хватать клиентской стороны диалога. Например, ваши серверы будут пытаться отправлять пакеты на компьютеры в Интернете, которые не ожидают их получения. Но эти компании изучают журналы (обычно на уровне приложения, а не на уровне пакетов) и используют эту информацию, чтобы выяснить, на какие страницы люди нажимают, как часто и в какой последовательности. Эти данные используются для написания скриптов / макросов, которые затем повторяет BrowserMob.
ApacheBench, как упомянул другой пользователь, в наши дни практически не используется. Это было более полезно 10 лет назад, когда вам просто нужно было выяснить, как быстро статический HTML-документ или JPEG может быть обработан при большой нагрузке. Это не сильно отличается от группы людей, которые снова и снова нажимают «перезагрузить», «перезагрузить», «перезагрузить» в своем браузере. При тестировании веб-приложения с более сложным рабочим процессом вам понадобится что-то более умное.
Я не думаю, что вы могли бы сделать это на сетевом уровне, хотя вы могли бы получить специализированное ядро для аппаратного балансировщика нагрузки для обработки второго сервера. Обычно веб-трафик (TCP) требует подтверждения каждого отправленного / полученного пакета. Поэтому, если пользователь отправляет пакет в вашу сеть, он будет дублироваться как в вашей производственной сети, так и в вашей теневой сети. Серверы в каждом сетевом ответе и пакет prod-сервера пересылаются обратно на вашу машину, которая возвращает подтверждение, и они весело продолжают свой разговор. Однако, если вы отбросите пакет теневого сервера, он не увидит подтверждения. Таким образом, он попытается отправить его повторно и в то же время снизит скорость передачи для всей сетевой активности (это называется оконным режимом). Он будет продолжать попытки отправить его до тех пор, пока не истечет время ожидания и сеанс не будет прерван. Честно говоря, вы даже не смогли бы завершить рукопожатие, чтобы установить соединение.
Самое близкое к этому - пересылка исходного пакета синхронизации на ваш теневой сервер, а затем установка шлюза по умолчанию для этих ящиков в качестве несуществующего местоположения. Затем каждый раз, когда пользователь пытается установить соединение, он получает реальный сервер в вашей производственной сети, и, по крайней мере, вы отправляете пакет синхронизации в теневую сеть. Черт возьми, теперь ты меня удивляешь, как ты тоже можешь заставить эту работу работать :)
Я смог спросить @adrianco об этом на встрече Netflix.
Ответ заключался в том, что они написали свой собственный инструмент, который, по сути, представляет собой ServletFilter (извините, специфическая для Java терминология), который воссоздает текущий запрос и выполняет асинхронный запуск и запуск на целевом сервере.
Преимущества:
Недостаток: