Expand my Community achievements bar.

SOLVED

TarMK Vs MongoMk

Avatar

Level 6

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!

1 Accepted Solution

Avatar

Correct answer by
Employee

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

View solution in original post

5 Replies

Avatar

Employee Advisor

Why do you want to use cookie and not the browser storage to persist client context data ? 

Avatar

Correct answer by
Employee

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

Avatar

Level 10

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

Avatar

Level 4

Will client context work if we deliver content through Akamai CDN ?

Avatar

Level 10

you mean delivering pages from Akamai CDN ?? It will work as client context is built via JS if you have included in your templates.