☰

Тестирование успешности алгоритма перегрузки

tag-icon • tag-icon networking linux-kernel performance
Тестирование успешности алгоритма перегрузки

Как вы проверяете, работает ли у вас конкретный алгоритм перегрузки? Я спрашиваю, потому что я не могу легко воссоздать репрезентативную рабочую нагрузку для большинства алгоритмов.

В настоящее время я рассматриваю две вещи, но открыт для дополнительных предложений:

  • «Ретранслированные сегменты» из выходных данныхnetstat -s

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

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

  • Существует ли метрика для измерения среднего возраста TCP-подключений?

Я считаю, что TCP-соединения, которые завершаются раньше (без всплеска ошибок и потери пакетов), могут указывать на то, что данные передаются с меньшей задержкой.

решение1

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

segments retransmittedin netstat -sвключает все повторные передачи TCP ядра по любой причине, включая те, что перечислены в вашем вопросе. Эти причины также могут включать:

  • Ошибки ссылок
  • Перегрузка коммутатора Ethernet
  • Локальный хост отключается из-за QoS или истощения ресурсов
  • Отключение удаленного хоста (возможно, из-за какой-либо формы истощения QoS/ресурсов на удаленном хосте)

Инженеры по тестированию производительности регулярно имеют дело со всеми этими переменными и гарантируют, что они могут измерить их надлежащим образом. Один из первых тестов, который вы должны сделать, — убедиться, что кабельная система/сеть работает чисто при размерах пакетов и скоростях трафика, о которых идет речь. Обычно это делается с помощью специального тестового устройства, например, от Ixia или Spirent.

Как только вы определите базовую производительность сети, вы сможете запустить тест, о котором спрашиваете. Даже если сеть прошла тест чисто, вам все равно следует отслеживать ошибки/сбросы интерфейса коммутатора во время теста TCP хоста, чтобы убедиться, что они не искажают ваши результаты.

Что касается ваших мыслей о создании условий перегрузки, вам может быть полезно намеренно генерировать фоновый трафик iperf UDP чуть ниже порога очереди класса qos, прежде чем вы запустите свой трафик TCP. Если вы обнаружите, что не можете насытить имеющееся соединение, вам также может быть полезно договориться о снижении NIC до 1GE или 100M.

Все это может показаться сложным, и в некотором смысле, возможно, так оно и есть; однако тестирование QoS вполне выполнимо при должной концентрации внимания и прозрачности всех компонентов системы.

решение2

Краткая версия:

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

В этом случае он бы внес изменения и заметил бы, httpdуменьшилась ли общая задержка.

Более длинная версия с конкретными примерами:

Чтобы пояснить, я изложу это в контексте. Давайте рассмотрим Apache httpd. Вы можете регистрировать время выполнения запроса в микросекундах и размер каждого запроса с помощью директив LogFormatи CustomLog. Например:

LogFormat "%h %m %D %b" perflog
CustomLog /var/log/httpd/performance.log perflog

Что дает вывод, подобный этому:

xxx.xxx.28.20 GET 41140 86
xxx.xxx.28.20 GET 34468 28
xxx.xxx.28.20 GET 47612 1434
xxx.xxx.28.20 GET 54860 868
xxx.xxx.28.20 POST 97055 6283
xxx.xxx.28.20 GET 33754 53
xxx.xxx.28.20 GET 68964 8416
xxx.xxx.28.20 GET 1143827 11528
xxx.xxx.28.20 GET 38055 61
xxx.xxx.64.208 HEAD 6255 -
xxx.xxx.28.20 GET 36922 142
xxx.xxx.28.20 GET 51871 5581

Я собираюсь заняться только GETзапросами на это:

root@xxxxxxvlp14 /tmp $ grep GET /var/log/httpd/performance.log > work.log
root@xxxxxxvlp14 /tmp $ sed -i 's/-$/0/g' work.log
root@xxxxxvlp14 /tmp $

(по какой-либо причине httpdвместо целого числа 0 укажите дефис).

Затем мы можем программно разобрать его:

#!/bin/bash

totalRequests=$(cat /tmp/work.log | wc -l )

totalTime=$(awk 'BEGIN{ count=0 } {count = count + $3} END { print count }' /tmp/work.log)
averageTime=$( printf "%.2f" $(bc -l <<< "$totalTime / $totalRequests "))
minTime=$(sort -nk 3 work.log | head -1 | awk '{print $3}')
maxTime=$(sort -rnk 3 work.log | head -1 | awk '{print $3}')

totalBytes=$(awk 'BEGIN{ count=0 } {count = count + $4} END { print count }' /tmp/work.log)
minBytes=$(sort -nk 4 work.log | head -1 | awk '{print $4}')
maxBytes=$(sort -rnk 4 work.log | head -1 | awk '{print $4}')

echo "Total Requests In Sample: $totalRequests"

echo

echo "Total Time Taken: $totalTime ms (average: $averageTime ms)"
echo "Longest Request: $maxTime ms"
echo "Shortest Request: $minTime ms"

echo

echo "Total Data Moved: $totalBytes bytes"
echo "Largest Request: $maxBytes bytes"
echo "Smallest Request: $minBytes bytes"

Пожалуйста, не комментируйте скрипт, он написан для ясности, а не эффективности. Вышеуказанное дает следующее:

Total Requests In Sample: 207

Total Time Taken: 15138613 ms (average: 73133.40 ms)
Longest Request: 1143827 ms
Shortest Request: 1788 ms

Total Data Moved: 409825 bytes
Largest Request: 20476 bytes
Smallest Request: 0 bytes

Очевидно, вышеизложенное иллюстрирует, почему важно получить длинный образец. Цифры верны (запрос длиной в полторы минуты был получен кем-то, кто генерировал отчет в формате Word, который включал изображения/графики, для любопытных).

Таким образом, вы уговариваете Apache предоставить вам длительную выборку (вероятно, в течение целого дня) нормальной активности, вносите изменения, меняете журналы, а затем снова начинаете собирать журналы (например, ждете еще 24 часа).

Каждая служба (NFS, другие HTTP-серверы, Samba, FTP-серверы и т. д.) будет иметь свой собственный способ сбора информации, но в целом будутнекоторыйсредства регистрации времени и пропускной способности.

Связанный контент