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

why there is a need for storing a hash for each message #6

Closed
silviucpp opened this issue Oct 14, 2017 · 6 comments
Closed

why there is a need for storing a hash for each message #6

silviucpp opened this issue Oct 14, 2017 · 6 comments

Comments

@silviucpp
Copy link

Hello @fogfish,

Looking to the code I see you are storing a hash for each message when writing to the file and also you check if it's match when reading.

I understand that you are checking the data integrity but what are your concern here for this overhead ?

Silviu

@fogfish
Copy link
Owner

fogfish commented Oct 16, 2017

Hello,

Yes, this is integrity check if the file is corrupted outside of beam process (e.g. by file system). It simply protect a queue from incorrect message.

@silviucpp
Copy link
Author

Hello can we make this optional ? I mean for most of use cases this is a pretty big overhead

Silviu

@silviucpp silviucpp reopened this Dec 22, 2017
@fogfish
Copy link
Owner

fogfish commented Dec 29, 2017

Can you please elaborate this? Do you refers this as "theoretical" overhead or you are talking about real use-case?

I am using (and have been used) this queue with system(s) that handles large volume of messages (millions per hour). Indeed, you need to provide addition disk space but this has not been at overhead.

Please advise!

@fogfish
Copy link
Owner

fogfish commented Jan 24, 2018

@silviucpp Do you have any feedback on this matter?

@silviucpp
Copy link
Author

I was talking about "theoretical" overhead only

@fogfish
Copy link
Owner

fogfish commented May 10, 2018

I've benchmarked the queue implementation once again due to this issue. It is able to perform about 70K writes per second on laptop with SSD. I/O number is low on AWS EBS. It is around 20 - 30K writes per second but uid is not a bottleneck what-so-ever. As I've explained to you, it is required for in-flight queue feature and I do not like to fragment API.

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

2 participants