7 Replies Latest reply on Feb 23, 2015 7:47 AM by Roger Palmen

    AFSDK.Config caching settings?

    Roger Palmen

      Stumbling over the AFSDK.Config file (in ProgramData\OSIsoft\AF), i'm wondering of the functionality of this section:

       

      <Cache maxObjects="10000" time="120" />
      

       

      If this controls the AFSDK caching, how should this be manipulated?

      My idea is that for a heavily loaded server (DataLink server), i consider to increase this value to make better use of the available memory. The model and data processed by this server is fairly static.

        • Re: AFSDK.Config caching settings?
          bshang

          Hi Roger,

           

          These settings are the properties for the AFCache static class. The class only has two public properties (MaxObjects and CacheTime). Note that only transactable AF SDK objects are held in this cache. These objects typically have the "Load" or "Find" static methods. Some collections are also cached (ie. Element Templates, Elements, etc.). These settings for AFCache are different from AFDataCache, which is used for caching events. You can find more details in the AF SDK programmer's guide.

           

          Back to Datalink Server, these settings may not make a difference if this isn't where the bottleneck is. I don't imagine increasing the AFCache would generally improve Datalink server performance, but might be worth to try. If we could run more diagnostics on where the DLS is having issues, then it would help determine what config settings to change. It is possible to load balance DLS via a Sharepoint farm but of course it would require more configuration than what may be possible. What sort of AF data are the excel sheets loading? How many users? What kinds of data references? What is the latency between DLS, PI and AF servers? If there are a lot of tags being requested, typically DLS does not bulk them up so that could be a bottleneck as well.

           

          EDIT: removing the part about weak references. Will double-check with AF SDK team regarding behavior.

            • Re: AFSDK.Config caching settings?
              Roger Palmen

              Barry,

              Thanks for the clarification. I already understood that there is not so much caching in the AFSDK cache, but that caching is mianly provided by the application using the AFSDK through .NET. So in this case, that won't help.

               

              I'm not yet having problems with my DL server, but i have some huge reports at a client that are a point of concern. But in the long term, a BI solution is the way to go for that. I was thinking of an easy way to keep all data in memory (no limitations there) after the first few calls, so that with some server heating scripts i could get the cache nicely filled.

                • Re: AFSDK.Config caching settings?
                  dng

                  After seeing this thread, I discussed a few things with the AF SDK team. Let me share some of our discussions here:

                  • Settings in the config file applies to all AF SDK application on the machine. You can, however, override the settings in the application.config file, or programmatically change theses settings in the AF SDK application.
                  • The AF Cache is there so that we can avoid making server round-trips to get the same AF objects over and over again if they are frequently used. However, it is a tradeoff between memory footprint and server access.
                  • The "optimal" cache setting varies greatly depending on the size of the AF system, the number of AF Objects the application will use, memory of the client machine, etc.
                  • It will help if we have some statistics on client side cache hit/miss and AF server RPC statistics for object access. Performance counters on memory usage of the application will also be useful. The cache should not be too large that we use most of the physical memory and have to page.

                   

                  Apart from that, I have not investigated the effect of varying the cache size. Perhaps other community members can provide additional insights.

                    • Re: AFSDK.Config caching settings?
                      Roger Palmen

                      Hi Daphne,

                       

                      Thanks for your feedback. Really helpful, as this is not documented. When the AFSDK is used in a middle-tier (e.g. WebParts Data Services, Web API, DataLink server, there is typically no control except for this config file.

                      Understand that any caching is really dependant on the actual load, memory available, etc.

                       

                      I do have some questions on the setting itself. The default is set to 10K.So how are objects counted? Is each Element an Object, or does this include each attribute too? So if i load 100 objects with 100 attributes, i already have 10K objects. Not counting templates, UOM's etc. And how are AFtables counted in this? Each table is one object, or each row?

                       

                      And going into detail on Library items: i always had the understanding library items are loaded on the initial connection to the AFserver. So UOM's, templates, AFtables, etc. are all pre-loaded into the AFSDK cache. I agree you won't quickly break the bank of 10K objects with just the library, but on a larger size model, this can add up to a significant portion of the # of cached objects.

                        • Re: AFSDK.Config caching settings?
                          dng

                          Hi Roger,

                           

                          For the majority of applications, we don't expect a need for any cache tuning. I believe the AF SDK only places top-level collections in the cache, but I will need to consult the AF SDK developer for implementation details. Let us get back to you on this.

                          • Re: AFSDK.Config caching settings?
                            dng

                            Hi Roger,


                            As Barry as mentioned earlier, only transactable AF SDK objects are held in the cache. Further elaborating on this, transactable AF objects means ones that implement the IAFTransactable interface. (For the list of objects, refer to the AF SDK reference guide). Generally, it means that objects that can be checked out/checked in to the AF server implement the IAFTransactable interface.

                             

                             

                            To answer your questions about how objects are counted, the answer depends on how the objects are loaded. For example, the collection returned from a Find or Load method will be one object held in the cache, which in turn provide a strong reference to all objects in the collection. In the case of the AFElement.Elements collection, the collection is actually paged to support large collections. When a page of Elements is loaded, it is added to the AFCache and counted as one object. An individual transactable object could also be added to the cache if not loaded as part of a collection (e.g. calling FindEventFrame).

                             

                            Attributes, AFTable rows, etc. do not support IAFTransactable and will not be added individually to the cache. They do not need to be because the owning object has a strong reference to them and will remain in memory as long as there is a reference to the owning object.

                             

                            Objects are only added to the cache when loaded from the server, rather than on initial connection to the server.