Helpful Guides

Caching Overview

Types of Caches

  • As part of the underlying OFBiz platform there is a sophisticated caching mechanism that manages all database retrievals and caches results
  • Database retrieval caches:
    • entity-list
      • essentially this caches non-primary key retrievals
      • typically the result set is multiple rows although it can be a single row
      • e.g. entitycache.entity-list.default.SomeTable
    • entity-primary-key
      • essentially this is a cache of retrievals that used the primary key (PK)
      • the result set will be a single row
      • e.g. entitycache.entity.default.SomeTable
  • Other caches:
    • Property files
    • FTL
    • Groovy
    • XML files
    • Minilang
    • Controller
    • Widget
    • Datafile

The OFBiz Cache Monitor

  • As part of Webtools, OFBiz provides a simple cache monitor
    • Webtools Cache and Debug Tools
  • Memory Summary
    • The memory summary provides JVM memory information in bytes
    • Memory TOTAL 422,653,952 FREE 188,064,192 USED 234,589,760 MAX 532,742,144
  • The cache list contains the following information:
Caption Description
Cache Name The Cache Name
Size The number of entries in the cache. One entry per unique SQL query
Hits The number of “hits” whereby a specific SQL query is matched to a prior execution of that query.
Misses / NF / EXP / SR The numbers of “misses” – incremented when a specific SQL query needs to make a trip to the database in order to retrieve data. A subsequent matching SQL call will be counted as a “Hit”
  • Misses: the total number of misses. The sum of “NF” + “EXP” + “SR” will match this number.
  • NF: Not Found, cache not available, trip to the database is required.
  • EXP: Expired, a cache was previously available but it expired causing a “miss”. Trip to the database to rebuild the cache will take place.
  • SR: Soft Reference, a cache was previously available but a soft-reference cache clear removed it, causing a “miss”. Trip to the database to rebuild the cache will take place.
  • TECH NOTE: The EXP and SR misses do not currently work on OFBiz due to a bug introduced a few years ago. All misses are logged as NF (Not Found).
Note: non-cached calls (FindBy) will NOT be included in these counts. Only requests that indicate cache usage are included.
removes: H/M The count of how many elements have been removed from cache.
  • H: when the remove was requested the item was in cache (hit)
  • M: when the remove was requested there was nothing to remove (miss)
Max in Memory The maximum number of entries that should be held in a specific cache store. Typically set to zero, which indicates an unlimited number. Expire Time The time, in milliseconds, after which the cache is available for cleanup.

If an entry has expired it is treated as if it does not exist, it will be retrieved, found to be expired and made available for cleanup.
Use Soft Ref? Use Soft Reference.

An indicator whether this Cache is available for cleanup.

A subsequent JVM garbage collection may unlink the object reference if memory is required.

Note: OFBiz defaults, for entity-list and entity-primary-key caches set this to “true”. If set to “false” then the specific cache will NEVER be released for garbage collection. If too many caches are set to “false” then there is a possibility for out-of-memory issues which will basically bring your application down.
Use File Store? True indicates that the cache can grow beyond the memory limit and will push additional elements to disk.

This has limited usefulness when caching database information since the processing required to integrate with the file system is roughly equivalent to retrieving from a database.

For OFBiz internal structures this can prove useful and caching to disk can reduce the time required to retrieve/parse many things that are not stored in the database.

We recommend that this is set to false unless there is specific knowledge or requirements to use a File Store.
Actions:  
Elements A link to view all the individual queries held in the cache. This will show a number of rows that matches the “Size” attribute above.
Edit A link to enable Edit of the cache properties. Can change Max-in-Memory, Expire-Time and Use-Soft-Ref settings.
Clear A link that will remove all cached entries.
  • Elements
    • The “Elements” list will display all the SQL queries that are held in a specific cache
Caption Description
Cache Element Key Essentially a representation of the SQL query
Expire Time The time when the cache element will expire and be available for garbage collection. Zero means it will not expire.
Bytes
  • The size, in bytes, of the Result Set.
  • For “entity-list” cache stores this could be very large and may indicate problems in the application.
  • For “entity-primary-key” cache stores this indicates the size of the SINGLE row stored.
Actions:  
Remove Clear the specific element cache

Hits and Misses

  • “Misses” in and of themselves are not an issue, unless the number of Misses become large, exceed hits, or exceed “Size”
  • For example:
    • Assume an entity table has 10 rows and during the course of time all entities are retrieved by primary key
    • One would expect:
      • Size: 10
      • Hits: > 10
      • Misses: 10
    • If Misses is greater than 10 this could indicate that cache is being unexpectedly cleared (a manual clear, scheduled job clear, soft reference or expiration release)
      • Memory allocation is too low, causing one of the above
      • The SQL statements are attempting to retrieve unexpected data

Cache Refresh

  • OFBiz automatically refreshes cached elements by attempting to match the updated row(s) to elements in entity based cache stores
  • See the following example for an explanation

Caching Example

Entity and Data

  • Let’s assume that a table entity is defined as follows, with data values:
Entity: SOME_TABLE
ST_ID ST_TYPE ST_DESCRIPTION
1 1 Blue Shirt
2 1 Red Shirt
3 2 Blue Pants
4 2 Red Pants
5 2 Yellow Pants
6 3 Red Socks
    • Where ST_ID is the primary key

Database Queries

  • Let’s further assume that over a period time, the eCommerce application executes the following retrievals at least once:
    • FindByPrimaryKey (SOME_TABLE, 1, true)
    • FindByPrimaryKey (SOME_TABLE, 2, true)
    • FindByPrimaryKey (SOME_TABLE, 3, true)
    • FindByPrimaryKey (SOME_TABLE, 4, true)
    • FindByPrimaryKey (SOME_TABLE, 5, true)
    • FindByPrimaryKey (SOME_TABLE, 6, true)
    • FindByCache (SOME_TABLE, type=1)
    • FindByCache (SOME_TABLE, type=2)
    • FindByCache (SOME_TABLE, type=3)

“Primary Key” Cache

  • The “entity-primary-key” cache would be setup as follows:
    • entitycache.entity.default.SomeTable
      • [GenericEntity:SomeTable][stId,1(java.lang.String)]
      • [GenericEntity:SomeTable][stId,2(java.lang.String)]
      • [GenericEntity:SomeTable][stId,3(java.lang.String)]
      • [GenericEntity:SomeTable][stId,4(java.lang.String)]
      • [GenericEntity:SomeTable][stId,5(java.lang.String)]
      • [GenericEntity:SomeTable][stId,6(java.lang.String)]

“List” Cache

  • The “entity-list” cache would be setup as follows:
    • entitycache.entity-list.default.SomeTable
      • (stType = 1)
      • (stType = 2)
      • (stType = 3)

Back-End Database “Update”

  • OFBiz has the sophistication to update both “entity-primary-key” and “entity-list” cache stores when rows are updated in the database
  • Let’s further assume that a back-end process is updating a specific row in SOME_TABLE entity:
Entity: SOME_TABLE
ST_ID ST_TYPE ST_DESCRIPTION
1 1 Blue Shirt
2 1 Red Shirt
3 2 Blue Pants
4 2 Red Pants
5 2 Yellow Black Pants
6 3 Red Socks
  • “entity-primary-key” cache refresh:
    • OFBiz will attempt to match based on the Primary Key value of the updated row (ST_ID = 6) and remove the entry
    • entitycache.entity.default.SomeTable
      • [GenericEntity:SomeTable][stId,1(java.lang.String)]
      • [GenericEntity:SomeTable][stId,2(java.lang.String)]
      • [GenericEntity:SomeTable][stId,3(java.lang.String)]
      • [GenericEntity:SomeTable][stId,4(java.lang.String)]
      • [GenericEntity:SomeTable][stId,5(java.lang.String)]
      • [GenericEntity:SomeTable][stId,6(java.lang.String)]
  • “entity list” cache refresh:
    • OFBiz will review all criteria in the “entity list” cache store and attempt to match ANY of the values to that of the updated row (ST_TYPE=2 will trigger a match)
      • (stType = 1)
      • (stType = 2)
      • (stType = 3)
  • At this point, the correct entries have been removed from cache and the eCommerce application will “miss” and reload cache the next time this data is required
    • Note that this process will also be counted as a “Remove: H/M”

Memory

JVM Memory

  • The JVM is ultimately responsible for memory allocation, growing heap, and garbage collection
  • The concepts of “soft references” and “expire” attributes for the OFBiz caches are standard JVM concepts.
  • It is recommended that expertise is sought to understand the nuances of this topic, it is beyond the purpose of this document to fully describe how this works

Recommendations

  • Memory allocation is a critical aspect of any Java based application, including OFBiz
  • The key settings are
    • Xms: the minimum allocation of memory
    • Xmx: the maximum allocation of memory
  • Memory should be allocated based on the traffic, typical user actions, and server capacity.

The Xms and Xmx settings should be the same.

By setting the Xms value to something significantly lower than the Xmx simply means that the JVM will need to monitor, allocate, grow heap, and perform many other activities to generally manage memeory.

By setting the Xms to the Xmx value, the JVM will be far less active and intrusive and the application is guaranteed to have adequate memory.

Problem Example

  • Let’s assume that on a moderately high-volume eCommerce implementation the settings are as follows:
    • Xms: 512Mb
    • Xmx: 3GB
  • As the cache stores build and encroach on the initial 512Mb allocation, the following can occur:
    • The JVM detects that the memory allocation is running low
    • “expire” and “soft references” may be cleared
    • Memory usage is evaluated, heap grown etc.
  • At this point, all the beneficial caching that has built up may be wiped clean
  • From our experience, it is difficult to fully understand how the JVM allocates memory and constantly monitors memory usage, evaluates expired and soft reference objects
    • It is not guaranteed that the memory will eventually be allocated to the 3GB specified on the Xmx parameter (based on other processes and demands)
      • Remember that the JVM is constantly attempting to be efficient
      • If at some point the entire 3Gb is allocated, the JVM will be reducing this whenever possible in an effort to be efficient and protect memory resources
    • The JVM may choose to increase the allocation somewhat, but the process of managing memory (and removing “expire” and “soft references”) may occur many times—each occurrence may significantly impact the application
    • And, of course, this memory management activity will occur at peak times during the day, when it is imperative that a solid caching solution works effectively
    • So, if the application ultimately may need ~3Gb of memory to perform well the recommendation above will ensure that this memory is allocated and the application performs well

Caching Goals

Big Fish eCommerce

  • The BigFish eCommerce implementation will utilize caching as much as possible with an ultimate goal of using cache stores whenever possible
    • For example:
      • After a specific Product Listing Page (PLP) has been “hit” and caching built any subsequent “hit” to that page would use cache entirely, with no additional database queries

Big Fish Admin Module

  • Back-end processes, either via the BigFish Admin Module, or OOTB OFBiz, will NEVER use cache stores
    • For example:
      • Imagine a few back-end users hitting Admin Module pages constantly throughout a day
      • This may include Customer lookups (PARTY and associated entities), Order views (ORDER_HEADER and associated entities), Scheduled Jobs performing db updates, etc.
      • If these were also cached into memory then it could seriously compromise the associated eCommerce implementation in that additional memory is required (using valuable memory and invoking JVM “memory management” far more than is necessary)
      • Furthermore, if there are a number of updates via these processes then the OFBiz caching synchronizations are far more processing intensive and could actually remove cached elements that are used by the eCommerce implementation
      • By completing avoiding caching within back-end processes these issues are completely avoided
Back to Top

Built by Solveda