Hello,
We have been trying to squeeze every bit of performance improvement that we can get out of our WDK Applications.
Among the things that are known to improve performance is Caching, specifically Client Persistent Caching, as Described in:
Documentum_ContentServer_Administration_Guide.pdf, Pg 178: Enabling and disabling persistent client caching.
We have done everything described here, and in Documentum Admintrator User Guide, and in Content Server Fundamentals.pdf, pg 68 (see snippets below).
Basically, what we are finding is that the applications we use, Webtop, DA, DAM, TaskSpace, etc - are NOT creating this persistent cache on the client side, and are certainly not USING such a cache (or we should be seeing a slight performance improvement once the query is cached).
So, we dont see any new 'qrycache' or type-cache or object-cache being created on the client machines.
When we create a custom application, using DFC or DFS, or directly using DQL, we can see that these ARE being created - so the mechanism works: it is just the the WDK Apps dont seem to be leveraging this setting. Nor, in fact, do ProcessBuilder or FormsBuilder.
Is this client persistent caching even supposed to work for WDK apps? If so, does anyone know how to make this work consistently? How to generate the persistent caches, especially for Queries (i believe they are supposed to be stored on the client host as .dat files in a qrycache folder in a location specified in the configs)? Or is this a feature of ContentServer and DFC that is not actually leveraged by client apps? It is strange indeed that this would be the case -- WDK performance would benefit greatly from qrycache and type-cache in particular.
Can anyone shed some light and maybe point us to some config that we may have missed?
Our setup is Windows, Documentum 6.5 SP2 on one environment, and 6.6 on another environment. This doesnt work on either environment.
Repository session caches
Query cache
Query results are only cached when persistent caching is requested and persistent
caching is enabled. The results are cached in a file. They are not stored in memory. The
file is stored with a randomly generated extension on the client application host disk
Persistent caching
This section describes persistent caching, a feature supported by the DFC and Content
Server, that provides performance benefits during session start up and when users or
applications access cached objects and query results
What persistent caching is
Persistent caching is the ability to create, manage, and maintain persistent caches of
query results, objects, and the type and data dictionary information associated with
persistently cached objects. Persistent caches are maintained across client sessions for
each user and repository combination. Persistent caches are implemented through DFC
and supported by Content Server.
The ability to cache objects and query results is enabled by default for every repository
Repository session caches are caches that are created when a user or application opens a
repository session. These caches exist only for the life of the repository session.
