-
Notifications
You must be signed in to change notification settings - Fork 34
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
Attention to decrease performance #60
Comments
Hi @MasiumDev, |
I think performance is O(n) from number of unique items in the queue. Seems like there is linked list for holding cache entities:
List.keyfind: |
Mnesia read always returns a list entries as a result. Therefore, we need to find the entry within the list. As the list is either containing no entries (cache miss) or one entry (cache hit), the big-O cost is O(1)(Mnesia table lookup) + O(1)(one-size list lookup). The reason this issue is still open is to give an example to the community on how not to write a ticket on an open source project. Commenting someone's work as "your code is slow, do you even test it at scale?" is not contributing in any way to improving things. The OP is not providing any meaningful information such as:
A minimum knowledge in the domain would suggest that implementing a caching layer over a distributed service will indeed incur in computing costs. As multiple publishers might be pushing the same message at the same time onto different RabbitMQ nodes, we need to guarantee a replicated and transactional storage for the deduplication headers. This obviously does not come for free. Hence, a performance impact is to be expected. The real question is whether the impact caused by this plugins is significantly higher than alternative solutions implemented in similar ways. If there would be a benchmark showing that, for example, a set of consumers relying on a Redis cluster for deduplication would show significantly higher consumption throughput then, and only then, there would be a valid concern to be raised. |
@noxdafox Thank you for such detailed reply. Indeed I was wrong about O(n), missed a part about Mnesia.read. My bad, I do not know erlang. |
@VSilantyev don't worry I was not addressing you in the answer but rather highlighting the issue with the overall ticket. I am not sure these architectural details are much of help for the reader of a README. In there, usually a reader expects to find:
The "how this thing works" and "when you should not use this thing" are usually more on the technical documentation/wiki side. |
I enable this plugin and it decreases the performance of other queues.
Do you test it on high publish about 20,000/sec?
The text was updated successfully, but these errors were encountered: