83 Community-Gadgets: Monitoring Its Performance
This chapter provides an overview of caching in WebCenter Sites. It explains how content is fetched and displayed on a web site when cache is enabled or disabled. This chapter also explains different cache modes and how they affect the performance and data consistency of the Community-Gadgets web application. It describes how to configure cache and optimize the handling of user-generated content.
This chapter contains the following sections:
83.1 About Caching
When a system receives a request, it routes it to different sub-systems that perform the required functions to serve this request, as shown in Figure 83-1 and described later in this section. The results of the request are compiled and then served to the client that made the request. These results could be in the form of complete comments for a page, comments sorted in a certain way, reviews, and so on. To improve the application's performance, these results can be stored in a such way that when the system receives a similar request, it can immediately locate and reuse the stored information to serve the new request.
Tip:
The Community-Gadgets web application uses the WebCenter Sites data repository and communicates with it over REST. WebCenter Sites, in turn, translates the REST request into a database query.
When Community-Gadgets loads content from its database, it caches that content in the in-memory cache, which is built with the help of the inCache technology provided by WebCenter Sites. Cache is an intermediate storage (RAM) in which data for the most popular and frequent queries is stored. The access to cache is very fast as RAM is used as storage.
Caching helps save network communication and data serialization overheads. To improve system performance and throughput, requests should be served from cache.
Two types of events take place when cache technology is used to serve requests: cache hit and cache miss. A cache hit occurs when the requested data already exists in the cache, and therefore, it is immediately served from the cache to a client. A cache miss occurs when the requested data does not exist in the cache. In this case, first the data from the WebCenter Sites data repository is copied into the cache, and then subsequent requests are served. For example, if a user requests the page on which comments/reviews were posted for the first time (that is, this page was not requested before, or cache was flushed), Community-Gadgets saves it to the cache. When another user requests this page, Community-Gadgets retrieves it from the cache. As a result of interaction between users and Community-Gadgets, the application caches all the data loaded from WebCenter Sites. This cache is an in-memory cache.
The following section explains how a system behaves with caching.
83.2 Community-Gadgets With Cache
This section contains the following topics:
83.2.1 Understanding Community-Gadgets
When a visitor creates, updates, or deletes an item such as a comment or review on a web site page, Community-Gadgets:
-
modifies all the related data in WebCenter Sites
-
invalidates all the related cache entries
This way, Community-Gadgets indicates to the whole system that cached entries are stale or no longer valid, and therefore, they should be updated based on the user's action. For example, when you edit an existing comment, this particular item and the entire data collection associated with the discussion whose comment you edited needs to be invalidated in the cache. The update of invalidated values happens in the background for the future access.
WebCenter Sites supports remote server in which cached content is kept up-to-date by sending invalidation requests over the REST protocol. To enable this, register the Community-Gadgets web application as a remote server in the SystemSatellite table. For Community-Gadgets installation and configuration details, see the Oracle Fusion Middleware WebCenter Sites Installation Guide.
Once you have registered Community-Gadgets as a satellite server, it starts receiving notifications about the modified data and invalidates its cache accordingly. When the data is modified, a notification is sent to all satellites, including the Community-Gadgets production and management systems. Figure 83-2 shows the process flow.
Note:
Notifications are broadcasted in a synchronous manner, and therefore, a modification request is not completed unless all satellites acknowledge receiving this invalidation.
Figure 83-2 Communication Between WebCenter Sites and Community-Gadgets Satellite Servers
Description of "Figure 83-2 Communication Between WebCenter Sites and Community-Gadgets Satellite Servers"
As shown in the process flow, Community-Gadgets caches results for all requests locally in the memory and receives invalidations to keep its cache consistent. For example, if Community-Gadgets collects, stores, and sends results for a request, and then a similar request comes, the application responds with cached data. However, if a visitor makes any changes between the time frame of the first and second requests, and an invalidation request is made in the same time frame, then the second request is served from the WebCenter Sites repository and not from the cache. See also, Figure 83-3, Figure 83-4, and Figure 83-5.
The two caching modes of Community-Gadgets are: regular caching and stale caching. Both modes share the same approach to data reads. If the required data is in the cache, it is served immediately. When the data is not in the cache, it is loaded from the WebCenter Sites repository synchronously. Therefore, results in the user interface are displayed for the user only after the load operation is completed and the data is cached. However, data invalidations and cache consistency work differently in regular caching and stale caching.
83.2.2 Regular Caching
When Community-Gadgets receives an invalidation request for a particular piece of data, it invalidates the cached data immediately so that all subsequent requests for that data get cache misses and the fresh data is loaded from the WebCenter Sites repository.
Figure 83-3 shows the process flow for the cache hit and cache miss events in the regular caching mode.
Figure 83-3 Cache Hit and Cache Miss in Regular Caching
Description of "Figure 83-3 Cache Hit and Cache Miss in Regular Caching"
In the regular caching mode the data consistency level is high, and all the changes are immediately reflected in the interface. For example, when a user posts a new comment and refreshes the page, the new comment is shown on the page immediately. Similarly, content deleted from a page disappears immediately after the page is refreshed.
83.2.3 Stale Caching
When Community-Gadgets receives an invalidation request, it does not invalidate the data and purge it immediately. This is in contrast with regular caching in which the cached data is invalidated immediately. In the stale caching mode, Community-Gadgets just marks the data that is no longer valid with a special invalidation mark. However, the data still remains in the cache so it can still be served from cache memory. When a request for the invalidated data is received, a thread is launched to update the invalidated data. This process is called regeneration cycle.
Figure 83-4 shows how invalidated data is regenerated in the background and regenerated content is served from cache.
Figure 83-4 Regeneration Cycle in Stale Caching
Description of "Figure 83-4 Regeneration Cycle in Stale Caching"
In the stale caching mode, the performance level is high because data loads happen seamlessly in the background. However, due to background data loads, the data consistency level is lower than that in the regular caching mode, so visitors do not see the actual results immediately. For example, when a comment is posted, it takes a couple of page refreshes before the comment is displayed on the page. The following process explains what happens in the stale caching mode:
-
Visitor posts a comment: Community-Gadgets marks the comment list with a special invalidation mark.
-
Visitor refreshes the page for the first time: Community-Gadgets still serves old data without the new comment from the cache, but detects the special mark and starts the background update process.
-
Visitor refreshes the page for the second time: the background update process is completed, the cache is updated, the new comment list containing the newly posted entry is returned to the client.
The background update process starts with the first refresh. The second refresh displays the updated data because cache is updated by the end of the first refresh. However, it depends on network overheads and the volume of changes, so potentially it may take more than two refreshes.
By default, Community-Gadgets uses a regular caching schema. To boost performance, you can enable the stale caching in the wsdk_facilities.properties configuration file in the standalone folders (default locations are <cg_install_dir>/deploy/management/management_node1 and <cg_install_dir>/deploy/production/production_node1) by setting the app_cache.stale property to true, as shown in Example 83-1.
Example 83-1 Stale Cache Mode Enabled
## Application cache facility configuration # + stale parameter enables usage 'old' data on production side # app_cache.stale=false
When the app_cache.stale property is set to false, the regular caching schema is used. However, certain areas in the product always need a high level of consistency, and therefore, Community-Gadgets overrides the stale cache mode for the following areas:
-
The Community interface and the Gadgets interface. Data needs to be always consistent with production system for easy management.
-
Operations on visitors' profiles. Especially during registration when the application needs to determine if a user with such user name already exists.
You can manage cache through the Cache Management Console, which is accessible at http://<cg_host>:<cg_port>/<cg_context>/cache on each Community-Gadgets instance. For example, http://mycosprod.example.com:8180/cg/cache/. For more information about cache management and Community-Gadgets, see the Oracle Fusion Middleware WebCenter Sites User's Guide.
83.2.4 Caching Dependencies
The following types of dependencies are associated with caching:
-
Dependencies for content modification: This type of dependency is recorded in the Dependencies column of the cache entries table such as Commons Cache, and it contains the ID of the existing asset. The system invalidates this cache entry whenever the associated asset changes.
-
Dependencies for content creation: This type of dependency is system-specific. The
unknowndeps: <table name>type of the inCache dependency keyword is used in such cases. Whenever a new entry is posted in the table, the cache is invalidated. This type of caching is useful for search and count queries that are required to be invalidated if any new content is posted.
During cache management, user operations must be constantly mapped to Community-Gadgets logic and entries stored in the cache. For example, during comment loading, the data structures shown in Figure 83-5 are associated with the "Loading..." message (the Loading operation) which is displayed initially when the Comments widget starts loading.
Figure 83-5 Data Structure Associated with the Comments Operation
Description of "Figure 83-5 Data Structure Associated with the Comments Operation"
The following is a step-by-step explanation of Figure 83-5. These points describe how each operation for comments is performed and cached:
-
The CommentFeed object that aggregates the whole discussion is discovered.
-
The total number of comments is discovered. This number is used to calculate and render the pagination interface and other comment-related features.
-
The site settings configured in Community-Gadgets are loaded. These settings are applied to the CommentFeed object that is rendered on the page accessed by visitors. These settings determine where the Post Comment form will be shown (top or bottom) on a page, the level of commenting permissions, and so on. After the setting IDs are discovered, Community-Gadgets searches the cache and gets cache hits before contacting the database.
-
If site settings are not cached, they are fetched from the WebCenter Sites repository by their IDs. Lookup by ID is used whenever possible because of the effectiveness of the process.
-
Loading of actual comments to be displayed on the web site begins. The Comment Feed objects and CommentRecord objects have a one-to-many relationship. First, all the IDs of comments associated with a particular feed are discovered. After the IDs of the comments associated with a particular feed are discovered, the IDs are analyzed and validated against the local cache entries. The IDs that are missing in the cache are loaded with the next request.
-
CommentRecord objects are loaded from the WebCenter Sites repository by the IDs discovered on the previous step.
-
The comments are examined, and the author IDs are extracted from comments that were posted by authenticated users. Then, the visitor profile IDs for which there are cache hits are loaded from the WebCenter Sites repository.
83.3 Configuring Cache in Community-Gadgets
The cache configuration in Community-Gadgets is similar to the cache configuration in WebCenter Sites because both products use the same inCache infrastructure.
The cache configuration file, cos-cache.xml and cas-cache.xml, is located in the cos-standalone-config directory for each Community node directory.
For more information about configuration parameters in this file and configuring inCache for page caching, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.
83.4 Optimizing User-Generated Content (UGC) in the Community Application
There are certain peak hours when the visitor traffic and the amount of feedback are highest in a day. In other words, there is a time during a day when the maximum number of UGC entries are submitted to database. During these periods of peak loads, database cannot handle the content insertion rate at the speed at which visitors submit content entries. To address such situations, WebCenter Sites provides an option called delayed writes. This is a simple but effective tool that uses the producer-consumer pattern. Visitors submit content to the system in the form of comments, reviews, and so on. The content entries are then queued up for the database. A consumer thread picks up these entries from the queue and inserts them into the database one-by-one, so results of these incoming requests (UGC entries) display on the web site later. Since changes are buffered and applied in the background, there is data inconsistency, so users cannot see their changes immediately.
The delayed writes option is available only after the administrator has configured it in WebCenter Sites. For information about how to enable this option, see Chapter 77, "WEM Framework: Buffering."After the delayed writes option has been configured on the WebCenter Sites instance used by Community-Gadgets, you must also set this option in the application's setup_cs.properties configuration file located in the standalone_node folders (default locations are: <cg_install_dir>/deploy/management/management_node1 and <cg_install_dir>/deploy/production/production_node1). In this file, set the widgets.cs.production.attrs.delayed_writes property to true:
# # Enabling "delayed writes" mechanism. CS will persist the assets asynchronously. # Default is "false" # widgets.cs.production.attrs.delayed_writes=true
Once the delayed writes option in enabled in Community-Gadgets, restart the Community production and management application servers. You will notice that the behavior of the production system will change when visitors submit content in the form of reviews, comments, and so on. For example, when a visitor posts a comment, the "Thank you for your submission" message will be displayed and comment will not appear on the site unless it is processed on the server asynchronously.