Performance Issues of fluentd-java-logger

[Sanket Gupta]

Hi

We are trying to send some data to fluentd from  a high throughput multithreaded app written in java.

While profiling the application we found that the org.fluentd.logger.sender.rawsocketSender.send were acting as a bottleneck and hence slowing down our system.

Commenting out the call to fluentd.append increased the performance of our app 4 times.

On digging deeper in the code, we found the following

1. the send function is ina synchronized block

2. The appender is connecting to fluentd only through a tcp socket

3. There is only one connection and no conection pooling

This will surely slow down any multithreaded app.

I need to know how the following can be achieved

1. Write to Unix Domain socket instead of TCP Socket - Unix sockets are faster thab TCP

2. Use a pool of connections instead of a single connection to fluentd-This will allow my threads to offload the data quickly and pass on the load to

Does somebody have more ideas/suggestions on removing fluentd as the bottleneck in the java code?

Regards

Sanket Gupta

[Taro L. Saito]

Hi, 

GitHub is a good place to discuss the performance issue of fluent-java-logger:

https://github.com/fluent/fluent-logger-java/issues

Here is a quick reply to your questions:

The current implementation of fluent-logger-java is not designed for multi-thread applications. 

- Unix Domain socket is not supported

- It flushes each log request to fluentd to ensure that the log is actually sent to fluentd. 

fluent-logger is a simple application that writes json (or message-packed) data to fluentd.

Your use case would be helpful to improve the fluent-logger-java. 

As you mentioned, having a connection pool would be good to improve the multi-threaded application performance.

Another idea is, if some delay of logging is allowed in your app, you can use some concurrent queue with a consumer that continues to pull 

the log requests from the queue and sends them to fluent-logger, and a producer (your application) that puts the logs to the queue.

Regards, 

Taro L. Saito