Fast producer slow consumer problem

[Rishav Shandilya]

Hi Hazelcast Team,

We are using ReliableTopic and we are facing this slow consumer problem with our app.

I was going through Hz docs, and found setting dedicated threadpool for a topic so that it won't be shared with other topics. That's somewhat helpful.

But, i would like to know if there's any other way (i.e config changes etc.) at Hazelcast level for making our consumer fast. I couldn't find anything else in docs that's why posting this question here.

Any help will be appreciated.

Thanks

[Rishav Shandilya]

Just an info: We can't slow down our producers

[Neil Stevenson]

 Giving the consumer more machine resources will help but might not be enough

 Can you describe approximately what the consumer does in terms of business logic ?

 In particular, what would be the ordering requirements around consumption. This might allow for different solutions

 Would it be possible for multiple consumers to handle messages ? They would still be consumed in sequence but their processing would overlap -- or must a message be processed completely before the next one can be handled.

[Nick Pratt]

Unless there's been work in this area that I've missed, the performance of HZ queues/topics is not that great (lists cannot be as easily/efficiently sharded/distributed as a Map which is where HZ excels).  For low volume applications it's a great solution to some problems, but for fast moving / significant data volumes there are significantly more performant options available which you might want to consider.

N

Confidentiality: This electronic mail and any files transmitted with it may contain information proprietary to Baazi Games Pvt Ltd, or one of its subsidiaries or affiliates, and is intended solely for the use of the individual or entities to which this is addressed. This email and contents shall be maintained in confidence and not disclosed to third parties without the written consent of the sender. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail by error and that any use, dissemination, forwarding, printing, or copying of this electronic mail or contents is strictly prohibited. If you have received this electronic mail by error, please immediately notify the sender by return mail.

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/dda05861-f927-42ee-975a-eb17678cc0b1n%40googlegroups.com.

[Rishav Shandilya]

We have a single consumer consuming data. 

Now, I would like to know if there's any Hz config through which we can enable parallel processing of subscribed data ?

If not, one soln we can think of is we can just dump data and then process it async in multiple threads. But, then we will have to handle those at our end. So, before doing that i was wondering if this similar thing can be handled by Hazelcast itself through some configs or not.

[Nick Pratt]

If you're using a Topic, then all consumers will get the same data - there's no benefit to parallel processing here (unless you're implementing a first-past-the-post parallelization strategy and discarding "late" results in an attempt to reduce latency).

If you have a single consumer, then you could potentially receive the message and hand it off to a thread pool for parallel processing (assuming that the order of message processing doesnt matter in your situation). This MIGHT speed things up IF the bottleneck is your client application.  If it's Hazelcast and/or the network, then making the consumer multi threaded won't make a difference.  Thats a fairly easy test though.

If you use a Queue, then you could have multiple separate consumer processes running that would share the load but I don't think you're going to see much performance difference vs a single consumer on a topic.

N

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/2ba4e17d-0142-43ec-a8df-7479fd728116n%40googlegroups.com.