Hi all, just wanted to get everyone’s opinion on User Synchronization (using Sling Content Distribution (SCD)) in AEM 6.2.
Right now in AEM 5.6.1 we’re using some custom Forward Replication/Reverse Replication (FR/RR) for all UGC, including user profile preferences. From our experience thus far, this is probably the worst thing in the world, and we’ve only got about 15-20k active users.
I went ahead and setup User Synchronization in my local dev environment (1 author, 2 publishers) and it’s working out pretty well for any preference modifications made under the rep:User node. I’m concerned when we scale back up to the number of active users we have in PROD right now, if SCD will encounter any of the performance problems that FR/RR had. I can only hope that the answer is no but I don’t know for sure. My guess is that SCD doesn’t have all of the overhead that FR/RR has from the AEM interface using replication agents, workflow instances, leaving behind var/audit logs, etc.
I also wanted to mention that we’re planning to implement MSRP, a MongoDB server for the rest of our UGC needs (Comments, Blogs, Notifications, etc) and wanted to get your thoughts on possibly storing the profile preferences there. Would that work? What would it look like? Has anyone tried it or had experience with it? etc.
From my limited understanding of the StorageResourceProvider API (SRP API), reading and writing to MongoDB UGC structure is on a per-component basis, right? So:
...and each individual entry beneath that would have a properties that tie it to a specific user? I don’t imagine there’s a way to actually have it be a shadow node of the user (instead of the component) would there? e.g., Actual Profile Node: /home/users/t/test-user vs. Mongo Shadow Node: /content/usergenerated/asi/mongo/home/users/t/test-user
As general guidance, I would recommend using the profile tree in JCR only for attributes that change infrequently like passwords, address, possibly site preferences. These are things that are unlikely to change during a given login session and perhaps only change a few times per month or year. This will keep the load on SCD light and avoid an potential bottleneck problems. Other attributes that will change during a login session should be stored through the SRP APIs into the configured SRP storage. This strategy is demonstrated within the product by the approach we're taking with the gamification data (scores, badges), messages, activitystreams, subscriptions and notifications, etc.
I'm not sure if we have sufficient samples for this strategy, but if you continue to ask questions here we'll try to help out and continue to improve the samples. Some possibly useful links:
This is extremely helpful and satisfies my initial concerns/questions from the original post, thank you Don!
One thing that would be helpful is if the samples could be revisited when the Communities API is updated, not just the documentation. Or maybe even branch the sample projects on github for each major/minor version (not necessarily patch versions), so you don't lose the working samples for people who haven't upgraded yet.