800xA cache handling.
I understand that the caching of displays and display elements is controlled by the Aspect Priority setting and the size of the LRU cache. However, I cannot find any detailed description of exactly how the workstation client cache works.
Setting the Aspect priority to 10 ( or any value above the pre fetch limit ) causes aspects to be prefetched to the client cache. But Graphic Displays are default priority 1 (lowest ). Changing this to 10 (Highest) seems to significantly reduce the tme taken to load the graphic part of a display and reduce the total loading time.
- why is the Graphic Display aspect priority set to 1 if 10 seems to work better ?
- What is the downside ( if any ) of setting Graphic Aspect priority to 10
- What is the difference between a setting of say 6 and 10 ?
There are notes in various manuals that say some errors can be resolved by setting the LRU cache size. I have seen mention in older release notes that the LRU cache size should be increased.
- What is the recommended method for determining the correct LRU cache size ?
- What is the effect of the LRU being too small ? Too big ?
is there any document giving a proper and cmplete description of how 800xA client caching works and how to optimize it ?
Voted best answer
As far as I know, the LRU graphic cache (hosted by the AfwFSD Service) is only used by Visual Basic 6 graphics (which required a rather bulky OCX to be downloaded and registered in the client before it could be used) not PG2.
When 800xA was introduced early this millennium, disk space weren't unlimited and it was decided that only visited/required graphics where to be put in cache.
Faceplate elements and display elements were given high priority (10) and were immediately pushed to all clients.
The remaining part (graphic displays) were downloaded on request.
The default FSD cache size was 250 MB in the beginning - it may have grown to 500 MB or so now. Some projects require this to be increased to 1-2 GB to prevent "juggling" of graphics the workplace required. There used to be a FSD system event generated when the cache became saturated in a client and the LRU theorem were put at work.
There is no harm increasing the cache size - it may just claim some more space on the client's hard drives (if files need to be stored there). Today hard disk space is not as restricted as it was 10-15 years ago.
With the New Graphics (PG2) the displays became much smaller - and it was decided that they do not need to be cached on disk in the clients no more. Only the OPC DA subscription cache is still disk based with PG2.
The FSD cache still exists in 5.1 and PG2 systems, but it is not used to cache PG2 graphics. Hence the FSD cache settings should not have any effect on PG2 callup times. FSD is nowdays mostly used by Fileviewer aspects, AC800 OPC Server, Operator Notes, FF OPC and some limited internal use by certain 800xA services to store bulky files not suitable to place in the Aspect Directory)