Производительность распределенных потоков Infinispan

Question

Infinispan 8.2.x (последняя версия) вводит распределенные потоки (из java 8) и обесценивает реализацию MapReduce [1]. Это поднимает вопрос об улучшении производительности.

Проводятся ли тесты для проверки преимуществ производительности? По данным команды Infinispan, были внутренние тесты, показывающие преимущества производительности распределенных потоков Infinispan [2]. Тем не менее, я еще не смог найти результаты или указатели для подробных обсуждений.

Как распределенные потоки Infinispan достигают более высокой производительности, чем Infinispan MapReduce? Использует ли он преимущества операций SIMD (Single input multiple data)?

[1] https://docs.jboss.org/infinispan/8.2/apidocs/org/infinispan/distexec/mapreduce/MapReduceTask.html

[2] https://developer.jboss.org/thread/268188?start=0&tstart=0

Answer 1

Спасибо за напоминание, честно говоря, мы были немного слабым на ведение блога о повышении производительности для этого. Надеюсь, мы сможем разобраться в ближайшем будущем. Однако я могу показать вам изображение с графика, который был сгенерирован в тестовом тесте, который был запущен. Ось y - это MB/s, а ось x - это # ​​уникальных слов (во всех тестах она выполняла простое число слов). Блог должен показать больше деталей.

Эти тесты были все побежали с radargun [2] Кстати. Тест-драйвер для Map Reduce можно найти в [3] и распределенных потоках с помощью [4].

Но из графика Map/Reduce близок к производительности (на ~ 15-30% меньше, чем распределенные потоки), но как только промежуточные результаты росли в размерах, Map/Reduce упал и закончился из памяти. Спарк в этом случае также имел вдвое больше памяти, чем распределенные потоки (так что я немного боялся этих результатов). Но это должно быть подробно описано после того, как у нас будет сообщение в блоге.

Но в отношении того, почему распределенные потоки выполняются быстрее, самое главное, что мы используем потоки Java 8 Stream под капотом, которые обеспечивают хорошие хиты кэша процессора и низкие накладные расходы при переключении контекста с использованием пула соединений fork. Map/Reduce имеет много этих оптимизаций, но не хватает некоторых :)

Кроме того, не забывайте, что распределенные потоки полностью перефразируются, и вам не нужно беспокоиться о повторяющихся/потерянных записях, когда узел входит/уходит, как вы делаете с Map/Reduce. Вы также можете узнать больше о распределенных потоках в [5].

[2] https://github.com/radargun/radargun

[3] https://github.com/radargun/radargun/blob/master/extensions/mapreduce/src/main/java/org/radargun/stages/mapreduce/MapReduceStage.java

[4] https://github.com/radargun/radargun/blob/master/extensions/cache/src/main/java/org/radargun/stages/stream/StreamStage.java

[5] http://infinispan.org/docs/dev/user_guide/user_guide.html#streams