This repository has been archived by the owner. It is now read-only.

Prove that Kafka is suitable as a centralized event log system #3

Closed
beevee opened this Issue Aug 8, 2017 · 12 comments

Comments

Projects
None yet
6 participants
@beevee
Contributor

beevee commented Aug 8, 2017

Current requirements:

  • 1 million events per second on regular server hardware (~10 servers)
  • 1 week storage time without loss of performance

Work plan:

  • Show reproducible results with a single Java gate/producer with clear bottlenecks
  • Write a Java consumer application
  • Show reproducible results with full cycle Java producer/kafka/consumer with clear bottlenecks
  • Show reproducible results with a single C# gate/producer with clear bottlenecks
  • Research time-based indices API
  • Add Kafka-specific metrics to dashboards
@beevee

This comment has been minimized.

Show comment
Hide comment
@beevee

beevee Aug 9, 2017

Contributor

Current hardware setup:

3×Kafka:
2×CPU E5-2620 0 @ 2.00GHz 6 Cores
128GB RAM
1TB RAID6 HDD
1Gb network

1×Airlock prototype (https://github.com/vostok-project/loadtest):
2×CPU E5-2609 v4 @ 1.70GHz 8 Cores
64GB RAM
1×480GB SSD + 3×4TB HDD
1Gb network

Contributor

beevee commented Aug 9, 2017

Current hardware setup:

3×Kafka:
2×CPU E5-2620 0 @ 2.00GHz 6 Cores
128GB RAM
1TB RAID6 HDD
1Gb network

1×Airlock prototype (https://github.com/vostok-project/loadtest):
2×CPU E5-2609 v4 @ 1.70GHz 8 Cores
64GB RAM
1×480GB SSD + 3×4TB HDD
1Gb network

@beevee

This comment has been minimized.

Show comment
Hide comment
@beevee

beevee Aug 10, 2017

Contributor

Текущие пределы производительности для Java-версии.

/kload100:
https://overload.yandex.net/25776 (5000 RPS, OK)
https://overload.yandex.net/25774 (6000 RPS, FAIL)

/kload10:
https://overload.yandex.net/26030 (8000 RPS, OK)
https://overload.yandex.net/26032 (9000 RPS, FAIL)

Contributor

beevee commented Aug 10, 2017

Текущие пределы производительности для Java-версии.

/kload100:
https://overload.yandex.net/25776 (5000 RPS, OK)
https://overload.yandex.net/25774 (6000 RPS, FAIL)

/kload10:
https://overload.yandex.net/26030 (8000 RPS, OK)
https://overload.yandex.net/26032 (9000 RPS, FAIL)

@beevee

This comment has been minimized.

Show comment
Hide comment
@beevee

beevee Aug 10, 2017

Contributor

Текущие пределы производительности для C#-версии:

/ping:
https://overload.yandex.net/26027 (500 RPS, FAIL, Owin)
https://overload.yandex.net/26265 (15000 RPS, FAIL, Kestrel)
https://overload.yandex.net/26813 (15000 RPS, OK, Kestrel w/threadpool settings)

Contributor

beevee commented Aug 10, 2017

Текущие пределы производительности для C#-версии:

/ping:
https://overload.yandex.net/26027 (500 RPS, FAIL, Owin)
https://overload.yandex.net/26265 (15000 RPS, FAIL, Kestrel)
https://overload.yandex.net/26813 (15000 RPS, OK, Kestrel w/threadpool settings)

@iloktionov

This comment has been minimized.

Show comment
Hide comment
@iloktionov

iloktionov Aug 10, 2017

Contributor

Я посмотрел по диагонали на код дотнетовского бенчмарк-сервера, и он совсем не выдерживает критики. Для начала надо сделать две вещи:

  1. Прочесть статью и применить на практике хотя бы первый пункт.
  2. Выкинуть owin и сделать на чистом kestrel'е.
Contributor

iloktionov commented Aug 10, 2017

Я посмотрел по диагонали на код дотнетовского бенчмарк-сервера, и он совсем не выдерживает критики. Для начала надо сделать две вещи:

  1. Прочесть статью и применить на практике хотя бы первый пункт.
  2. Выкинуть owin и сделать на чистом kestrel'е.
@AndrewKostousov

This comment has been minimized.

Show comment
Hide comment
@AndrewKostousov

AndrewKostousov Aug 24, 2017

Contributor

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

/kload10:
https://overload.yandex.net/35055 (8000 RPS, TT < 10ms, OK)

/kload100:
https://overload.yandex.net/35060 (5000 RPS, TT < 10ms, OK)

Contributor

AndrewKostousov commented Aug 24, 2017

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

/kload10:
https://overload.yandex.net/35055 (8000 RPS, TT < 10ms, OK)

/kload100:
https://overload.yandex.net/35060 (5000 RPS, TT < 10ms, OK)

@AndrewKostousov

This comment has been minimized.

Show comment
Hide comment
@AndrewKostousov

AndrewKostousov Aug 30, 2017

Contributor

Прогнал тесты с тремя продьюсерами и тремя консьюмерами, запущенными на одних и тех же машинах edi18, icat-test04, icat-test05. Танк стрелял по трем мишеням параллельно с одной скоростью. Каждый консьюмер вычитывал все ивенты в три потока (по одному потоку на партишен). Метрика MeanTravelTime (MTT) - это время между моментом генерации события на шлюзе и моментом, когда это событие становится доступно обработчику в консьюмере, усредненное за 3 секунды.

/kload100 (один запрос на шлюз генерирует 100 ивентов размером по 100 байт каждый):
https://overload.yandex.net/39532 (3x2000 RPS в течение 10 минут, MTT < 20 ms, OK)
https://overload.yandex.net/39467 (3x2500 RPS в течение 5 минут, FAIL) - здесь консьюмеры не успевали в режиме реального времени все ивенты вычитывать (см. метрику mean-travel-time)

/kload1000 (ивенты размером по 1KB):
https://overload.yandex.net/39552 (3x200 RPS в течение 5 минут, MTT < 20 ms, OK)
https://overload.yandex.net/39543 (3x1000 RPS в течение 2 минут, FAIL) - уперлись в сеть на стороне консьюмера

Contributor

AndrewKostousov commented Aug 30, 2017

Прогнал тесты с тремя продьюсерами и тремя консьюмерами, запущенными на одних и тех же машинах edi18, icat-test04, icat-test05. Танк стрелял по трем мишеням параллельно с одной скоростью. Каждый консьюмер вычитывал все ивенты в три потока (по одному потоку на партишен). Метрика MeanTravelTime (MTT) - это время между моментом генерации события на шлюзе и моментом, когда это событие становится доступно обработчику в консьюмере, усредненное за 3 секунды.

/kload100 (один запрос на шлюз генерирует 100 ивентов размером по 100 байт каждый):
https://overload.yandex.net/39532 (3x2000 RPS в течение 10 минут, MTT < 20 ms, OK)
https://overload.yandex.net/39467 (3x2500 RPS в течение 5 минут, FAIL) - здесь консьюмеры не успевали в режиме реального времени все ивенты вычитывать (см. метрику mean-travel-time)

/kload1000 (ивенты размером по 1KB):
https://overload.yandex.net/39552 (3x200 RPS в течение 5 минут, MTT < 20 ms, OK)
https://overload.yandex.net/39543 (3x1000 RPS в течение 2 минут, FAIL) - уперлись в сеть на стороне консьюмера

@trurl123

This comment has been minimized.

Show comment
Hide comment
@trurl123

trurl123 Aug 30, 2017

Contributor

Итоги тестирования клиента кафки на .net

  • Общее
    • На линуксе всё работает медленнее, чем на винде примерно в 2 раза, иногда и на порядок медленнее
    • Получение сообщений в общем случае медленнее, чем отправка.
    • Единственная нормальная библиотека на .Net - это обертка над библиотекой librdkafka.
    • Многопоточная работа не дает прироста производительности (несколько получателей или несколько потоков отправки)
    • В основном тестировал сообщения по 10 байт
    • Использовал многомерную оптимизацию по параметрам, что дало существенное ускорение работы
    • На линуксе еще не до конца протестировал многомерную оптимизацию
  • Отправка
    • Библиотека librdkafka на windows может отправлять около 1 млн сообщений в сек.
    • Обертка на .net над librdkafka отправляет около 1млн сообщений в сек, без оптимизации 800 тыс сообщений в сек
  • Получение
    • Напрямую librdkafka не стал использовать, поскольку необходимо писать слишком много кода
    • Обертка на .net над librdkafka получает около 1млн сообщений в сек, без оптимизации около 500 тыс сообщений в сек
Contributor

trurl123 commented Aug 30, 2017

Итоги тестирования клиента кафки на .net

  • Общее
    • На линуксе всё работает медленнее, чем на винде примерно в 2 раза, иногда и на порядок медленнее
    • Получение сообщений в общем случае медленнее, чем отправка.
    • Единственная нормальная библиотека на .Net - это обертка над библиотекой librdkafka.
    • Многопоточная работа не дает прироста производительности (несколько получателей или несколько потоков отправки)
    • В основном тестировал сообщения по 10 байт
    • Использовал многомерную оптимизацию по параметрам, что дало существенное ускорение работы
    • На линуксе еще не до конца протестировал многомерную оптимизацию
  • Отправка
    • Библиотека librdkafka на windows может отправлять около 1 млн сообщений в сек.
    • Обертка на .net над librdkafka отправляет около 1млн сообщений в сек, без оптимизации 800 тыс сообщений в сек
  • Получение
    • Напрямую librdkafka не стал использовать, поскольку необходимо писать слишком много кода
    • Обертка на .net над librdkafka получает около 1млн сообщений в сек, без оптимизации около 500 тыс сообщений в сек
@trurl123

This comment has been minimized.

Show comment
Hide comment
@trurl123

trurl123 Aug 30, 2017

Contributor

При тестировании веб-сервиса .net по аналогии с Java для отправки сообщений, наблюдается замедление отправки примерно на 30%

Contributor

trurl123 commented Aug 30, 2017

При тестировании веб-сервиса .net по аналогии с Java для отправки сообщений, наблюдается замедление отправки примерно на 30%

@trurl123

This comment has been minimized.

Show comment
Hide comment
@trurl123

trurl123 Sep 4, 2017

Contributor

Для .net по линуксу максильный RPS на отправку на edi18 удалось сделать 118358
на получение максимальный RPS 488671 на icat-test04

Contributor

trurl123 commented Sep 4, 2017

Для .net по линуксу максильный RPS на отправку на edi18 удалось сделать 118358
на получение максимальный RPS 488671 на icat-test04

@trurl123

This comment has been minimized.

Show comment
Hide comment
@trurl123

trurl123 Sep 5, 2017

Contributor

на icat-test04 средний RPS 200 тыс

Contributor

trurl123 commented Sep 5, 2017

на icat-test04 средний RPS 200 тыс

@trurl123

This comment has been minimized.

Show comment
Hide comment
@trurl123

trurl123 Sep 6, 2017

Contributor

Протестировали отправку по 10Kb на java, c# на windows и linux веб сервисом в кафку. На каждый http-запрос отправляли одно сообщение в кафку.
Java: https://overload.yandex.net/41379
C# linux: https://overload.yandex.net/41854
C# windows: https://overload.yandex.net/41859
На windows на закладке мониторинга не видно статистики на клиенте кафки, поскольку танк не смог установить своего агента туда по понятным причинам.
На таких тестах объем данных в секунду одного порядка: 100 Mb/sec.
На java побыстрее: 125 Mb/sec.
На c# Linux: 103 Mb/sec
На windows тоже около 100Mb/sec, но скорость сильно скачет

Если тестировать как раньше, на каждый http-запрос отправлять по 100 запросов в кафку, то c# существенно проигрывает java, примерно на порядок.

Contributor

trurl123 commented Sep 6, 2017

Протестировали отправку по 10Kb на java, c# на windows и linux веб сервисом в кафку. На каждый http-запрос отправляли одно сообщение в кафку.
Java: https://overload.yandex.net/41379
C# linux: https://overload.yandex.net/41854
C# windows: https://overload.yandex.net/41859
На windows на закладке мониторинга не видно статистики на клиенте кафки, поскольку танк не смог установить своего агента туда по понятным причинам.
На таких тестах объем данных в секунду одного порядка: 100 Mb/sec.
На java побыстрее: 125 Mb/sec.
На c# Linux: 103 Mb/sec
На windows тоже около 100Mb/sec, но скорость сильно скачет

Если тестировать как раньше, на каждый http-запрос отправлять по 100 запросов в кафку, то c# существенно проигрывает java, примерно на порядок.

@trurl123

This comment has been minimized.

Show comment
Hide comment
@trurl123

trurl123 Sep 20, 2017

Contributor

Прогнал через танк гейт, который принимает данные и пересылает их в кафку.
Объем данных вычислялся через объем http-реквеста, кол-во событий вычислялось через кол-во событий в кафке. Если событие 10 байт, то сами данные, отправляемые в кафку занимали примерно половину реквеста. На 100 и 1000 байт не такие сильные различия.
Результаты:
Событие 10 байт https://overload.yandex.net/45808
Событие 100 байт https://overload.yandex.net/45812
Событие 1000 байт https://overload.yandex.net/45814
Результаты получились лучше, чем в мегатесте Андрея Костоусова. Возможно из-за того, что не использовалась Avro-сериализация, ну и это был не мегатест, а тест одного продьюсера.

Contributor

trurl123 commented Sep 20, 2017

Прогнал через танк гейт, который принимает данные и пересылает их в кафку.
Объем данных вычислялся через объем http-реквеста, кол-во событий вычислялось через кол-во событий в кафке. Если событие 10 байт, то сами данные, отправляемые в кафку занимали примерно половину реквеста. На 100 и 1000 байт не такие сильные различия.
Результаты:
Событие 10 байт https://overload.yandex.net/45808
Событие 100 байт https://overload.yandex.net/45812
Событие 1000 байт https://overload.yandex.net/45814
Результаты получились лучше, чем в мегатесте Андрея Костоусова. Возможно из-за того, что не использовалась Avro-сериализация, ну и это был не мегатест, а тест одного продьюсера.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.