Кто-нибудь знает о тестах производительности / измерениях для использования локального Unix-сокета для межпроцессного взаимодействия?
Я хочу проиллюстрировать выигрыш в производительности от наличия экземпляра локальной базы данных на том же сервере, что и программное обеспечение, запрашивающее данные из базы данных, и необходимости обмениваться данными по сетевому каналу, особенно такой, как гигабитный Ethernet, который, как я ожидаю, будет довольно медленным условно говоря.
При поиске в Интернете я обнаружил некоторые тесты, показывающие количество операций в секунду, но не пропускную способность в секунду (т.е. 12 ГБ / с).
Я понимаю, что производительность будет варьироваться из-за таких вещей, как, например, пропускная способность памяти в данной системе или другие аппаратные характеристики, но нужна лишь грубая идея.
Это не относится к локальной производительности TCP или сравнению с ней.
источник
Ответы:
Вы можете использовать socat для простого теста скорости сокета UNIX.
Ниже приведены результаты, которые я получаю на своем ноутбуке:
Память на диск (SSD) через разъем UNIX
Память в память через сокет UNIX
Память в / dev / null (сбросить) через сокет UNIX
От / dev / zero до / dev / null через сокет UNIX
Как вы можете видеть, даже тестовая пропускная способность «память на диск» составляет 545 МБ / с (т.е. ~ 4360 МБ / с), что намного опережает максимальную теоретическую пропускную способность для соединения Ethernet 1 ГБ (которое составляет ~ 1000/8 = 125 МБ / с, даже не учитывая какие-либо издержки протокола).
PS
Обратите внимание, что это всего лишь простой тест с использованием некоторых простых инструментов, а не настоящий, правильный тест.
источник
Я должен был помочь людям понять влияние многоуровневых стеков приложений.
Что касается связи по TCP, я использую различия в RTT (в оба конца).
Для одноуровневого уровня вы можете сравнить локальный IP-адрес (на сетевой карте) с lo0 (loopback).
Для многоуровневой системы вы сравниваете / вычисляете «более удаленные» адреса, например, многоуровневая система может быть либо двумя виртуальными машинами на одном хосте, либо разными хостами в одном центре данных, либо они могут находиться в разных центрах обработки данных. (может быть, расстояние всего 500 метров, но все равно другое).
К сведению: для многих приложений различия RTT незначительны, но для приложений, которые делают 10-100 тысяч небольших сообщений за время приложения RTT, может стать узким местом.
(Я встречал ситуации, когда «многоуровневая партия» занимала почти 6 часов дольше, когда RTT была на .25 миллисекун дольше по сравнению с одноуровневой)
Итак, простой тестовый стенд:
The
И моя программа мониторинга - tcpdump - с опцией -ttt
Итак, в двух разных окнах у меня работает tcpdump:
Для «локального» времени: tcpdump -i lo0 -n -ttt порт 80 И для «удаленного» tcpdump -I en1 -n -ttt порт 80
В приведенных ниже данных цель не состоит в том, чтобы провести какой-либо анализ, а показать, как вы можете определить «различия» во времени, необходимом для завершения транзакций. Когда пропускная способность приложения - последовательные транзакции - на пропускную способность в «сек | мин | час» влияет общее время, необходимое для «ответов». Я нашел, что это проще всего объяснить, используя концепцию RTT - туда-обратно.
Для реального анализа есть дополнительные вещи, которые нужно посмотреть. Итак, единственные строки, которые я покажу, это начальное рукопожатие TCP, а также первый исходящий пакет и возвращаемый ACK. Для сравнения сравните дельта-времена того, как долго «ответ» возвращается.
127.0.0.1
192.168.129.63
обратите внимание на 01.XXXXXX - на одну секунду сна на интерфейсе «lo0»
192.168.129.72
виртуальная машина на том же хосте - обратите внимание, что время начинается с 00.000000 - отображается первый пакет (и 01.XXXXXX для двух других адресов ниже)
192.168.129.254
Мой роутер - вне хоста, а не виртуальной машины.
192.168.129.71
то же соединение, что и 192.168.129.72, но оно «занято», а «72» бездействует. Я надеюсь, что начальные рукопожатия почти идентичны
несколько прыжков
это тот же хост, тот же результат Apache, но теперь через внешний интерфейс (6 IP-прыжков, а не прямой) - теперь вы можете получить эффект междугородного RTT. (PS, я немного изменил IP-адрес). Более важно - обратите внимание, что после первоначального рукопожатия есть два исходящих пакета до первого ACK после его возвращения.
Итак, вместо RTT 25 мс, подумайте, что RTT составляет 250 микросекунд, а не 25 микросекунд - и у вас есть 500 000 транзакций (что на 120–125 секунд больше по сравнению с локальной, и пропускная способность, imho, сравнима. Но с За 50 миллионов транзакций (как в реальной жизни) вы получаете дополнительные 12500 секунд - что добавляет примерно 3,5 дополнительных часа для «буквально» той же работы (и частью решения для этого случая было увеличение пакетов - средний размер изначально был 400-450 байт).
Еще одна вещь, которая мне «нравится» в использовании tcpdump - это общедоступная программа. Ничего лишнего не нужно устанавливать.
источник