文档
Liferay提供丰富知识资源,协助我们的社区与我们的技术更好地结合、应用。
Distributed Caching
Liferay 4.3.1 and higher uses Ehcache, which has robust distributed caching support. This means that the cache can be distributed across multiple Liferay nodes running concurrently. Enabling this cache can increase performance dramatically. For example, say that two users are browsing the message boards. The first user clicks on a thread in order to read it. Liferay must look up that thread from the database and format it for display in the browser. With a distributed Ehcache running, this thread can be pulled from the database and stored in a cache for quick retrieval. Say then that the second user wants to read the same forum thread and clicks on it. This time, because the thread is in the local cache, no trip to the database is necessary, and so retrieving the data is much faster.
This could be done by simply having a cache running separately on each node, but the power of distributed caching allows for more functionality. The first user can post a message to the thread he or she was reading, and the cache will be updated across all of the nodes, making the new post available immediately from the local cache. Without that, the second user would need to wait until the cache was invalidated on the node he or she connected to before he or she could see the updated forum post.
Configuring distributed caching requires the modification of the portal-ext.properties file as well as one or more other files depending on what you want to cache. The first thing you will want to do is determine where on your server you will want to store your cache configuration files. This will have to be somewhere on Liferay's class path, so you will need to find where your application server has stored the deployed version of Liferay, and create a folder in Liferay's WEB-INF/classes folder to store the files. Because the original, default files are stored inside of a .jar file, you will need to extract them to this area and then tell Liferay (by use of the portal-ext.properties file) where they are.
For example, say you are running Liferay on Tomcat. Tomcat stores the deployed version of Liferay in <Tomcat Home>/webapps/ROOT. Inside of this folder is the folder structure WEB-INF/classes. You can create a new folder in here called myehcache to store the custom versions of the cache configuration files. Copy the files from the /ehcache folder—which is inside the portal-impl.jar file—into the myehcache folder you just created. You then need to modify the properties in portal-ext.properties that point to these files. Copy / paste the Hibernate section of portal.properties into your portal-ext.properties file and then modify the net.sf.ehcache.configurationResourceName property to point to the clustered version of the configuration file that is now in your custom folder:
net.sf.ehcache.configurationResourceName=/myehcache/hibernate-clustered.xml
Now that Liferay is pointing to your custom file, you can modify the settings in this file to change the cache configuration for Hibernate.
Next, copy / paste the Ehcache section from the portal.properties file into your portal-ext.properties file. Modify the properties so that they point to the files that are in your custom folder. For example:
ehcache.multi.vm.config.location=/myehcache/liferay-multi-vm.xml
If you are going to enable distributed clustering, uncomment the following line and point it to your custom version of the file:
ehcache.multi.vm.config.location=/myehcache/liferay-multi-vm-clustered.xml
You can now take a look at the settings in these files and tune them to fit your environment and application.
Alternatively, if your Liferay project is using the extension environment to make customizations to Liferay, you can place your cache configuration in the extension environment. The settings there will override the default settings that ship with Liferay. If you wish to do this, you can create new versions of the files in ext-impl/classes/ehcache. The files should be postfixed with -ext.xml. For example, the custom version of hibernate.xml should be called hibernate-ext.xml, and the custom version of liferay-multi-vm-clustered.xml should be called liferay-multi-vm-clustered-ext.xml. You can then modify the files and tune them to fit your environment / application, and they will be deployed along with the rest of your extension environment.
Hibernate Cache Settings
By default, Hibernate (Liferay's database persistence layer) is configured to use Ehcache as its cache provider. This is the recommended setting. The default configuration, however, points to a file that does not have clustering enabled. To enable clustering, copy the Hibernate section from portal.properties into your portal-ext.properties file. To enable a clustered cache, comment out the default file (hibernate.xml) and uncomment the clustered version of the file, making sure that you change the path so that it points to your custom version of the file:
net.sf.ehcache.configurationResourceName=/myehcache/hibernate-clustered.xml
Next, open this file in a text editor. You will notice that the configuration is already set up to perform distributed caching through a multi-cast connection. It is likely, however, that the configuration is not set up optimally for your particular application. You will notice that by default, the only object cached in the Hibernate cache is the User object (com.liferay.portal.model.impl.UserImpl). This means that when a user logs in, his or her User object will go in the cache so that any portal operation that requires access to it (such as permission checking) can retrieve that object very quickly from the cache.
You may wish to add other objects to the cache. For example, a large part of your application may be document management using the Document Library portlet. In this case, you may want to cache Document Library objects, such as DLFileEntryImpl in order to improve performance as users access documents. To do that, add another block to the configuration file with the class you want to cache:
<cache
name="com.liferay.portlet.documentlibrary.model.impl.DLFileEntryImpl"
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="600"
overflowToDisk="true"
>
<cacheEventListenerFactory
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
properties="replicatePuts=false,replicateUpdatesViaCopy=false"
propertySeparator=","
/>
<bootstrapCacheLoaderFactory class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory" />
</cache>
Your site may use the message boards portlet, and those message boards may get a lot of traffic. To cache the threads on the message boards, configure a block with the MBMessageImpl class:
<cache
name="com.liferay.portlet.messageboards.model.impl.MBMessageImpl"
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="600"
overflowToDisk="true"
>
<cacheEventListenerFactory
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
properties="replicatePuts=false,replicateUpdatesViaCopy=false"
propertySeparator=","
/>
<bootstrapCacheLoaderFactory class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory" />
</cache>
Note that if your developers have overridden any of these classes, you will have to specify the overridden versions rather than the stock ones that come with Liferay Portal.
As you can see, it is easy to add specific data to be cached. Be careful, however, as too much caching can actually reduce performance if the JVM runs out of memory and starts garbage collecting too frequently. You will likely need to experiment with the memory settings on your JVM as well as the cache settings above. You can find the specifics about these settings in the documentation for Ehcache.
Clustering Jackrabbit
If you are using the Document Library, by default you are using the JSR-170 document repository, which is the Apache product Jackrabbit. You have already configured basic data sharing among nodes by moving its configuration into a database. The next thing you need to do is configure clustering for Jackrabbit, so that each node knows about data being entered into the repository by other nodes.
You can find the Jackrabbit configuration file in <Liferay User Home>/liferay/jackrabbit. The file is called repository.xml. You have likely already edited this file when you modified the configuration to move the data into the database.
At the bottom of this file is a cluster configuration that is commented out. If you are using a MySQL database, you can uncomment this section and use it as-is. You will need to change the cluster ID for each node so that they don't conflict with one another.
If you are using another database, the only changes necessary are the connection, credentials, and schema settings. Modify them according to your database of choice and then save the file. This is all it takes to set up clustering for Jackrabbit.