Hi,
As per my understanding, TarMK is faster than MongoMK due to the fact that segments are immutable and because of this it is easy to cache frequently accessed segments(TarMK). MongoMK is recommended where scalability is important.
Now, TarMK is not suitable when we use clientcontext. And the reason is, if we use multiple TarMK enabled publisher then all the publisher does not sync because AEM 6 does not support clustering. Now lets say one request coming from Load balancer which updates clientcontext cookie on a particular AEM instance but subsequent request will not come to same AEM instance unless we use sticky session.So, in this case user will see different behavior if sticky session is not used. Again I was told that if we use sticky session then again it increases loads on particular AEM instance. Anybody has good/bad experience on this?
So I would like to know best practice while using clientcontext with TarMK. Is it recommended to use MongoMK with clientcontext even though TAR is faster? What are the other parameters I should consider?
Thanks for your help!
Solved! Go to Solution.
Views
Replies
Total Likes
Sam205505050 wrote...
Hi,
As per my understanding, TarMK is faster than MongoMK due to the fact that segments are immutable and because of this it is easy to cache frequently accessed segments(TarMK). MongoMK is recommended where scalability is important.
MongoMK is only recommended for the authoring tier [1]. High Availability is another reason to use MongoMK, if your SLA's require zero downtime, then this can only be achieved with MongoMK.
Now, TarMK is not suitable when we use clientcontext.
As Lokesh mention, your client context is run in the users browser[2], so the backend topology is not important, there are however considerations you need to take into account when using user profile data/client context with TarMK on the publish tier. I'll explain below.
And the reason is, if we use multiple TarMK enabled publisher then all the publisher does not sync because AEM 6 does not support clustering.
One use case for clustering in the past was when there was UGC(User Generated Content), which had to synched across all instances. The Communities team solved this by using a common store[3]. Hence, they recommend a publish farm and not MongoMK.
Another user case was when you have standalone publish instances is you need to synch new users across the publish instances. In AEM 5.x, If you were not using clustering, then the users needed to be replicated/reverse replicated, which had it's issues. The communities team solved this using Sling Content Distribution[4]. The reason I mention this is that the client context can be used to load profile data, hence you need to have the profile/account on every instance. Often however, once the user account is created, you will go to another source to get details about the user(i.e. CRM)
Now lets say one request coming from Load balancer which updates clientcontext cookie on a particular AEM instance but subsequent request will not come to same AEM instance unless we use sticky session.
The client context cookie would be stored in the browser, you would not normally write back to the server.
If your user accounts are synched across your publish TarMK instances(using Sling Content Distribution as mentioned above) you can use the Encapsulated Token Feature, which means sticky connections are no longer required.[5]
So, in this case user will see different behavior if sticky session is not used. Again I was told that if we use sticky session then again it increases loads on particular AEM instance. Anybody has good/bad experience on this?
The load is dependant on what your page does, ideally the load balancer should be distributing the requests to maintain an even load on the publish instances.
So I would like to know best practice while using clientcontext with TarMK. Is it recommended to use MongoMK with clientcontext even though TAR is faster? What are the other parameters I should consider?
Thanks for your help!
As explained above, using TarMK is not an issue with client context and I would urge you to review the material below, also taking note of the points to consider I mentioned above, and if needed, engage Adobe Consulting or a suitable partner for more detailed design/analysis for your use case.
Regards,
Opkar
[1] https://docs.adobe.com/docs/en/aem/6-1/deploy/recommended-deploys.html
[2] https://docs.adobe.com/docs/en/aem/6-1/administer/personalization/client-context.html
[3] https://docs.adobe.com/docs/en/aem/6-1/administer/communities/srp/asrp.html
[4] https://docs.adobe.com/docs/en/aem/6-1/administer/communities/sync.html
[5] https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html
Views
Replies
Total Likes
Why do you want to use cookie and not the browser storage to persist client context data ?
Views
Replies
Total Likes
Sam205505050 wrote...
Hi,
As per my understanding, TarMK is faster than MongoMK due to the fact that segments are immutable and because of this it is easy to cache frequently accessed segments(TarMK). MongoMK is recommended where scalability is important.
MongoMK is only recommended for the authoring tier [1]. High Availability is another reason to use MongoMK, if your SLA's require zero downtime, then this can only be achieved with MongoMK.
Now, TarMK is not suitable when we use clientcontext.
As Lokesh mention, your client context is run in the users browser[2], so the backend topology is not important, there are however considerations you need to take into account when using user profile data/client context with TarMK on the publish tier. I'll explain below.
And the reason is, if we use multiple TarMK enabled publisher then all the publisher does not sync because AEM 6 does not support clustering.
One use case for clustering in the past was when there was UGC(User Generated Content), which had to synched across all instances. The Communities team solved this by using a common store[3]. Hence, they recommend a publish farm and not MongoMK.
Another user case was when you have standalone publish instances is you need to synch new users across the publish instances. In AEM 5.x, If you were not using clustering, then the users needed to be replicated/reverse replicated, which had it's issues. The communities team solved this using Sling Content Distribution[4]. The reason I mention this is that the client context can be used to load profile data, hence you need to have the profile/account on every instance. Often however, once the user account is created, you will go to another source to get details about the user(i.e. CRM)
Now lets say one request coming from Load balancer which updates clientcontext cookie on a particular AEM instance but subsequent request will not come to same AEM instance unless we use sticky session.
The client context cookie would be stored in the browser, you would not normally write back to the server.
If your user accounts are synched across your publish TarMK instances(using Sling Content Distribution as mentioned above) you can use the Encapsulated Token Feature, which means sticky connections are no longer required.[5]
So, in this case user will see different behavior if sticky session is not used. Again I was told that if we use sticky session then again it increases loads on particular AEM instance. Anybody has good/bad experience on this?
The load is dependant on what your page does, ideally the load balancer should be distributing the requests to maintain an even load on the publish instances.
So I would like to know best practice while using clientcontext with TarMK. Is it recommended to use MongoMK with clientcontext even though TAR is faster? What are the other parameters I should consider?
Thanks for your help!
As explained above, using TarMK is not an issue with client context and I would urge you to review the material below, also taking note of the points to consider I mentioned above, and if needed, engage Adobe Consulting or a suitable partner for more detailed design/analysis for your use case.
Regards,
Opkar
[1] https://docs.adobe.com/docs/en/aem/6-1/deploy/recommended-deploys.html
[2] https://docs.adobe.com/docs/en/aem/6-1/administer/personalization/client-context.html
[3] https://docs.adobe.com/docs/en/aem/6-1/administer/communities/srp/asrp.html
[4] https://docs.adobe.com/docs/en/aem/6-1/administer/communities/sync.html
[5] https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html
Views
Replies
Total Likes
If you need the data across the session you need to create the persisted data in the client context. If its only for per request, then you can create non persisted data. Refer [1] for more details on different client context data
[1]https://docs.adobe.com/docs/en/cq/5-6-1/developing/client_context_detail.html#Example: Creating a Custom Context Store Component
Views
Replies
Total Likes
Will client context work if we deliver content through Akamai CDN ?
Views
Replies
Total Likes
you mean delivering pages from Akamai CDN ?? It will work as client context is built via JS if you have included in your templates.
Views
Replies
Total Likes