6 Replies Latest reply on Mar 15, 2019 9:41 PM by zburke

    PI Web API Ignoring "Cache-Control" Headers?

    zburke

      Hi Everyone!

       

      Does anybody know if there are circumstances in which PI Web API will ignore "Cache-Control" headers? I'm attempting to make calls to PI Web API from PowerShell in a way that doesn't keep hitting the cache. (The eventual goal is to be able to benchmark how long each of these requests would take.) The script below should reflect what I'm trying to do:

       

      $cred = Get-Credential
      
      $time = Measure-Command {
          $result = Invoke-WebRequest `
              -Uri "https://localhost/piwebapi/attributes/F1AbEmIJUSg0YH0OFiTwOoMmSBQvbDzVUqE6BGpRgANOl3A5AYegZKq0ulUK0udsrMWtEagQ0VOVFJBTFBJU0VSVkVSXENPTkZJR1VSQVRJT05cT1NJU09GVFxQSSBDT1JFU0lHSFR8Q09SRVNJR0hUIFVSTA" `
              -Headers @{
                  "cache-control"="no-cache";
              } `
              -Credential $cred
      
      }
      

       

      However, watching PI Web API's cache (from https://localhost/piwebapi/system/cacheinstances), every time I make this request I seem to have created / updated a cache instance. Indeed, starting from a point where I have no cache instances under my name, if I make this request multiple times the response returns blazingly fast every time after the first. So I'm pretty confident that this request is making full use of PI Web API's caching mechanism, even though that's exactly what I'm trying to avoid.

       

      Does anybody know of any reason why the "Cache-Control" header wouldn't enable a simple request like this to avoid PI Web API's cache? Maybe there's a configuration item somewhere I'm missing, or my approach is generally misguided? I'm using Kerberos delegation and have a self-signed SSL certificate. I'm running PI Web API 2018.

       

      Thanks!

        • Re: PI Web API Ignoring "Cache-Control" Headers?
          vpartusch

          Hi Zachary,

           

          There was a new configuration item added in PI Web API that prevents repeated cache refreshes called AFCacheRefreshHoldoffTime. By default, this is set to 60 seconds. So if you want to actually bypass the cache repeatedly, you could can add a new attribute to the PI Web API Configuration database (value type: Int32), and set its value to 0.

           

           

           

          1 of 1 people found this helpful
            • Re: PI Web API Ignoring "Cache-Control" Headers?
              zburke

              Thanks, Vincent! I never would have known AFCacheRefreshHoldoffTime was even an option! For anyone else stumbling along this post, doing a Google search for AFCacheRefreshHoldoffTime led me to the document below. It mentions several other configuration attributes like this one and covers alot of PI Web API performance considerations:

               

              https://cdn.osisoft.com/osi/presentations/2018-uc-emea-barcelona/UC18EU-D3D102-OSIsoft-Bazis-LiveCoding-Writing-Highly-P…

               

              I think that's a great start. Is there a way to get the same effect of avoiding the cache altogether only using information in the request, though? Something like in the PI Web API course video (OSIsoft: PI Web API I Online Course- Caching - YouTube)?  The ultimate aim is to use this to help monitor application performance in production environments, and it would be great to be able to do this without changing attributes in AF. (Realistically, I'll probably forget to change them back.) I believe users will be loading data from cache most of the time, but I'm worried about that initial load time.

                • Re: PI Web API Ignoring "Cache-Control" Headers?
                  vpartusch

                  I don't believe there is anything you can do within the request to override the AFCacheRefreshHoldoffTime. If you specify cache-control: no-cache, the Web API will override that and prevent bypassing the cache if the specified refresh holdoff time hasn't elapsed since the previous refresh. Setting the AFCacheRefreshHoldoffTime to 0 won't mean that all requests bypass the cache, it would just allow for it to happen when you have requests that specify no-cache (i.e. the way it worked before this version, like in the YouTube video you linked).

                  1 of 1 people found this helpful
                    • Re: PI Web API Ignoring "Cache-Control" Headers?
                      zburke

                      Makes sense! However, even after adding in that attribute, I'm still not able to avoid hitting that cache. I'm testing this by restarting the PI Web API service so that there are no cache instances. But every time I repeat the above request, cache instances still keep popping up. Anything else I can try or another reason this wouldn't be working as expected?

                        • Re: PI Web API Ignoring "Cache-Control" Headers?
                          vpartusch

                          I think you will always see a cache created, but you should see it get refreshed every time that you make a new no-cache request, meaning that you are retrieving the most up-to-date information from the server on each request.

                            • Re: PI Web API Ignoring "Cache-Control" Headers?
                              zburke

                              Hmmm... I see. I'm testing this by making the same request twice. Though the second request is much, much faster than the second one, the value that comes across is indeed different from the first. So I think it's very safe to say that it's not reading from the cache, just as instructed!

                               

                              I think the mistake I've been making has been in assuming that PI Web API on the backend was making some sort of call to AFSDK's "GetValue" function in one case but not the other (reading from cache, instead). But it seems I wasn't taking into account everything else PI Web API has to do beyond that call. It's entirely possible that the second call is moving faster because its using pre-existing connections, not pre-existing values. So the flaw seems to have existed with my testing strategy! I'd almost go as far to guess that the second call to PI Web API (with the no-cache header) would actually be the more accurate measure of how long a data reference actually takes to resolve. The first request is doing alot of other stuff on the backend that makes it not necessarily the best indicator for how long it takes for my data references to resolve.

                               

                              Thank you very much for your help, Vincent! Your suggestion for the extra configuration attribute seems to have worked! (I can have PI Web API create it and remove it as needed.) You're a champ!