Foren

Caching in liferay

thumbnail
Amit Doshi, geändert vor 9 Jahren.

Caching in liferay

Liferay Master Beiträge: 550 Beitrittsdatum: 29.12.10 Neueste Beiträge
Hi All,

I am working on one project, in which we have a required to store all the user's information in some Caching mechanism. There are near about 1.5 lac users in the system.

User's information is not stored in liferay DB. It is stored in separate DB. So when each & every user logging in, it goes to find it's information in the DB and then it is giving desired output. Instead of doing this, we are planning to create some caching mechanism to store the information, rather than doing interaction with DB every time for each and every user.

In our case we need to store 1.5 lac users information in EHCache but found that it has capacity to store only 10,000 Objects and also in the EHCache replication it would be performance overhead.

After doing some R&D, I found terracotta Caching is the best approach. It will store data in separate Terracotta Cache Server(Big Memory Max) and there will not be any performance overhead of replication in application server.

If anybody has any idea using terracotta Caching or any other solution for this kind of scenario then please suggest.

Thanks & Regards,
Amit Doshi
thumbnail
David H Nebinger, geändert vor 9 Jahren.

RE: Caching in liferay

Liferay Legend Beiträge: 14919 Beitrittsdatum: 02.09.06 Neueste Beiträge
You're going to find that you actually need users to be in liferay. It is the only way foreign keys to users can be supported.

Trying to cache so many objects in memory on any kind of system can be a hugely wasteful use of resources. Unless all of those users are logging in on a regular basis, you'll going to have a dedicated pile of crap (yes, it will smell like crap if you get close to it) most of which is rarely needed or used.

Lots of orgs want to use their own user table, not copy/load into Liferay, but that quickly breaks down because the external system doesn't have the fields that Liferay wants to populate and Liferay won't work without being able to satisfy the foreign keys. Your Expando tables won't work for the users, you won't be able to determine who owns what, the Liferay permissions (all based on the Liferay users) won't work, group/site/team membership won't work, you get the picture?

Your best bet instead is to ask how to store so many users in the Liferay environment and still make it work. The answer here is to use whatever sharding mechanism your database has to effectively handle so many records, and replace lucene with Solr so you can handle all of that data.