Производительность компонента вывода файлов Apache Camel низкая - Java

Question

Я использую Camel для записи ряда строк (100 000 с) в набор текстовых файлов.

Код ниже показывает мой верблюжий маршрут:

from("seda:fileOutputMatchedMsgClose?concurrentConsumers=44")
.to("file:MATCHED_CLOSE?fileExist=Append")
.end();

Итак, в основном, у меня есть компонент-производитель, который создает эти строки из объектов, обработанных в последующем. Я устанавливаю имя файла в заголовке как часть метода sendbody и заголовочного компонента. Итак, у меня есть 22 файла, в которые пишутся (все в папке MATCHED_CLOSE). Все сообщения для этих 22 файлов отправляются одной конечной точке SEDA (fileOutputMatchedMsgClose).

Проблема в том, что приложение отправляет около 440 строк в эту конечную точку SEDA в секунду. И, глядя на размер очереди fileOutputMatchedMsgClose в JConsole, он продолжает расти вместе с использованием памяти. Так что, похоже, здесь немного бутылочного горлышка.

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

Ура!

Answer 1

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

Answer 2

Вы, конечно, ограничены скоростью ввода-вывода дисков. Так что вам нужно уметь записывать 440 файлов / сек.

Теперь все эти 440 файлов имеют уникальные имена файлов? Я спрашиваю, потому что у вас есть? FileExist = Append.

Компонент файла Camel будет сериализовывать записи в одно и то же имя файла, поэтому, если все 440 записывают в одно и то же имя файла, они делают это последовательно. Причина этого заключается в том, что пользователи сообщества Camel сообщают о «потерянных записях», когда они выполняют параллельные записи в один и тот же файл.

Верблюд использует NIO API для записи в файлы, поэтому я сомневаюсь, что вы сможете сделать это значительно быстрее.

Answer 3

При записи содержимого в файлы верблюжьего маршрута вы можете использовать 3 опции:

• верблюжий файл
• верблюжий агрегатор
• верблюжий поток

Используя агрегатор, вы можете комбинировать обмены и записывать их в файл, т. Е. Количество записей в файл будет резко сокращено, и вы сможете увидеть некоторое увеличение пропускной способности.

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

Вы можете увидеть разницу между каждым из них в моем посте здесь:

https://onegoodexample.wordpress.com/2016/07/10/apache-camel-throughput-or-performance-improvement-while-writing-into-files/

Спасибо, Калян

Answer 4

Если можете, переключитесь на stream вместо использования file . Он делает меньше и работает лучше.

Компонент file использует GenericFileProducer , который имеет значительные накладные расходы при записи в файлы, включая прохождение блока синхронизации, поддержание LRUCache и открытие файла назначения каждый раз и позиционирование в конец файла для добавления и других действий.

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