Notifications: Performance issues at scale? | Community
Skip to main content
Gdubz-57m2mu
New Participant
January 30, 2017
Solved

Notifications: Performance issues at scale?

  • January 30, 2017
  • 2 replies
  • 1964 views

Did some local testing and noticed that if, for example, 3 people are following a blog post and someone leaves a comment, there are 5 Mongo documents created:

  • 1x Comment
  • 1x Activity, for the user who commented
  • 3x Notifications, for each user following this blog post

What happens if we had, again just for example, 15,000 users following a blog post...!

  1. Would that generate 15,002 Mongo documents each time a comment was posted?
  2. Would this slow down the time it takes to post each comment?
  3. Couldn't this quickly get out of hand, if you had a large number of blog posts that users were actively following and commenting on?

Version: AEM 6.2 with Communities FP1 & FP2
SRP Config: Mongo DB SRP (MSRP)

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by mcdan

This is true. But what it comes down to is, do you bias a system for read performance or data size? We have biased the system for read performance ( feel free to read up on fan out on write vs. fan out on read ). Also, the notifications system creates node async to the blog creation process so that "throughput" is not slowed by the fan out on write. 

2 replies

Gdubz-57m2mu
New Participant
January 31, 2017

Thank you so much for the reply, Dan. Makes a bit more sense after reading a couple articles on it.

For anyone else that may come across this post in the future, this is the article I found, and the links that it contains:

mcdanAccepted solution
Employee
January 30, 2017

This is true. But what it comes down to is, do you bias a system for read performance or data size? We have biased the system for read performance ( feel free to read up on fan out on write vs. fan out on read ). Also, the notifications system creates node async to the blog creation process so that "throughput" is not slowed by the fan out on write.