Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with read performance #10

Open
eoglethorpe opened this issue Jan 26, 2015 · 5 comments
Open

Issues with read performance #10

eoglethorpe opened this issue Jan 26, 2015 · 5 comments

Comments

@eoglethorpe
Copy link

I'm not sure if I'm missing something but I'm only able to pull somewhere between 10-50 messages/second from my RMQ source but I'm able to get in the range of several thousand per second by pulling directly from RMQ or using other RMQ plugins. Any thoughts? Thanks.

@samlane
Copy link

samlane commented Jan 27, 2015

I'm finding the same issue. Is there any effort underway to consider batchSize parameter?

@agentgt
Copy link

agentgt commented Feb 4, 2015

@eoglethorpe and @samlane

The issue is that the source is synchronous, polling and does not take advantage of prefetching. Right when I looked at the code I knew it was going to be a problem and it was.

I fixed it in my own fork. The reason I haven't pushed a pull request @jcustenborder is that the code is rather sloppy albeit we are using it in production.

https://github.com/agentgt/flume-ng-rabbitmq

Particularly you want to look at / copy:

https://github.com/agentgt/flume-ng-rabbitmq/blob/master/src/main/java/org/apache/flume/source/rabbitmq/RabbitMQConsumerSource.java

With my consumer we get about 150 msg/sec with spikes of it easily handling 1500 msg/sec. I don't know if it can go faster because we don't have the load yet and sadly haven't had the time to set up some cloud images to test its max.

We use the file channel. You do not want to use the memory channel and or the spillover channel. I know its shocking but the file channel on a modern SSD is faster than the memory channel when dealing with bursts.

@eoglethorpe
Copy link
Author

Awesome, thanks for posting - I ended up switching to another RMQ plugin which had much better read performance 'out of the box': https://github.com/stampy88/flume-ng-amqp-plugin

@agentgt
Copy link

agentgt commented Feb 17, 2015

Yeah that plugin should be even faster than mine because it does batching.
I didn't implement batching but was going to (this is so that you only have to send one ACK for the entire prefetch).

However it looks like I don't now and I can just use that plugin :)

@kaybinwong
Copy link

@eoglethorpe when i use the plugin(https://github.com/stampy88/flume-ng-amqp-plugin) as a test, i found it only can pass the string under 2byte,then i had read the source but got nothing.
do you have any idea?
thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants