Как играть трафик против теневой сети?

Лично я бы назвал это «нагрузочным тестированием через воспроизведение сеанса». Я не знаю какого-либо простого универсального термина для такого рода техники тестирования.

Основная стратегия, которую я видел, применяемая для такого типа нагрузочного тестирования, - это получение файлов журнала из производственной системы и их повторное воспроизведение. тестовая система.

Вы можете использовать такие инструменты, как JMeter или Apache Bench для воспроизведения запросов из файлов журнала. Если вы хотите воспроизвести очень сложные взаимодействия клиент / сервер (с конкретными деталями времени, основанными на исходном потоке журнала) в надежде по-настоящему задействовать внутренности вашего приложения (поиск условий гонки, ошибок, связанных с синхронизацией, и т. Д.), Вы можете посмотрите на создание инструментов тестирования для конкретных приложений, которые имитируют клиентов в большом масштабе.

You ' re не сможет просто захватывать грузы сырого сетевого трафика и "воспроизводить" его с помощью любого протокола на базе TCP или IP. Порядковые номера TCP не будут соответствовать исходному перехваченному трафику, и это не сработает. Захват IP-уровня будет проблематичным, потому что ваши смоделированные клиенты должны будут отвечать за захваченный IP-адрес отправителя. Вам будет лучше захватывать трафик ближе к уровню 7 и использовать его для воспроизведения сеансов, потому что в противном случае вы также планируете написать симулятор TCP. (Я мог бы представить себе использование чего-то вроде tshark для извлечения данных и времени уровня 7 из TCP-потока и их воспроизведения, например.)

Простое воспроизведение сетевого трафика имитирует нагрузку, но не обязательно захватывает дефекты. Ваш смоделированный клиент должен будет получать ответы от тестового сервера и анализировать их на предмет корректности, если вы хотите провести нагрузочный любой тест на то, что приложение отвечает правильно. Поскольку ваше приложение будет генерировать данные динамического ответа, маловероятно, что ваш смоделированный клиент сможет просто сравнить ответ тестового сервера с записанным в журнал ответом рабочего сервера. Здесь вы собираетесь написать программу тестирования, специфичную для вашего приложения и его результатов.

s ответ на зарегистрированный ответ от производственного сервера. Здесь вы собираетесь написать программу тестирования, специфичную для вашего приложения и его результатов.

s ответ на зарегистрированный ответ от производственного сервера. Здесь вы собираетесь написать программу тестирования, специфичную для вашего приложения и его результатов.

Вы используете такую ​​службу, как BrowserMob , которая имитирует одновременный доступ большого количества людей к вашему веб-сайту. Эти службы не воспроизводят зарегистрированный трафик, потому что в этом случае вам будет не хватать клиентской стороны диалога. Например, ваши серверы будут пытаться отправлять пакеты на компьютеры в Интернете, которые не ожидают их получения. Но эти компании изучают журналы (обычно на уровне приложения, а не на уровне пакетов) и используют эту информацию, чтобы выяснить, на какие страницы люди нажимают, как часто и в какой последовательности. Эти данные используются для написания скриптов / макросов, которые затем повторяет BrowserMob.

ApacheBench, как упомянул другой пользователь, в наши дни практически не используется. Это было более полезно 10 лет назад, когда вам просто нужно было выяснить, как быстро статический HTML-документ или JPEG может быть обработан при большой нагрузке. Это не сильно отличается от группы людей, которые снова и снова нажимают «перезагрузить», «перезагрузить», «перезагрузить» в своем браузере. При тестировании веб-приложения с более сложным рабочим процессом вам понадобится что-то более умное.

Я не думаю, что вы могли бы сделать это на сетевом уровне, хотя вы могли бы получить специализированное ядро ​​для аппаратного балансировщика нагрузки для обработки второго сервера. Обычно веб-трафик (TCP) требует подтверждения каждого отправленного / полученного пакета. Поэтому, если пользователь отправляет пакет в вашу сеть, он будет дублироваться как в вашей производственной сети, так и в вашей теневой сети. Серверы в каждом сетевом ответе и пакет prod-сервера пересылаются обратно на вашу машину, которая возвращает подтверждение, и они весело продолжают свой разговор. Однако, если вы отбросите пакет теневого сервера, он не увидит подтверждения. Таким образом, он попытается отправить его повторно и в то же время снизит скорость передачи для всей сетевой активности (это называется оконным режимом). Он будет продолжать попытки отправить его до тех пор, пока не истечет время ожидания и сеанс не будет прерван. Честно говоря, вы даже не смогли бы выполнить рукопожатие, чтобы установить соединение.

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

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

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

Мне удалось спросить @adrianco об этом на встрече Netflix.

Ответ заключался в том, что они написали свой собственный инструмент, который по сути представляет собой ServletFilter (извините , Специфическая для Java терминология), который воссоздает текущий запрос и выполняет асинхронный вызов типа «запустил и забыл» на целевом сервере.

Преимущества:

• Шаблоны трафика «реального мира» по сравнению с вашим тестом («темный») инфраструктура
• Нет необходимости записывать, а затем воспроизводить

Недостаток:

• Нужно иметь резервные потоки / циклы ЦП на производственных блоках
• Задержка в тестовой инфраструктуре может создать резервную копию и повлиять на ваши рабочие блоки