2 Replies Latest reply on Apr 29, 2014 12:57 PM by Marcos Vainer Loeff

    PI SDK affecting other users logged when one requests a TREND

    snepes

      Hello Friends!

      I'm having performance issues with the PI SDK affecting other users logged when one requests a TREND!

      Our web application was created to provide information for monitoring "Turbo machines" of Oil Rigs.

      It makes access to the PI Server through PI SDK C #.

      The current version of the system entered production in 2012 and until the beginning of 2014 had no reported problem. Ie, the application was very stable.

      But now every time a customer requested a Graphic (Trend) with a period of 1 year (720 points),
      while the "PI Server" did not answer this request (which is really heavy) the system starts
      to get very slow for everyone other users logged into machines and different locations.


      The application only to get back quickly after the Graph (TREND) is created on the screen and feature releases.


      In this scenario we have made several attempts to solve the problem between them try to change the architecture of connection with the "PI SERVER".

      As the documentation OSISoft, our application, generated only ONE INSTANCE (SINGLETON) for all application.
      So try switching to a ONE INSTANCE per user. But this strategy left the system even slower.


      So this week we discovered important information.

      In the same period where the problems started was installed a "New Version" in the "PI Server" (PI 2012).
      And a professional who has worked in OSISoft said that this new version there is a "Processing Limit" by Application.



      And to confirm this thesis we could clearly see this new "processing limit" also in PI EXCEL.


      We managed to reproduce the problem with 2 calls made while using the IP EXCEL.

      To reproduce the same symptom of the web application, we did the following:

      - The first call was made through a Trend 1 year 8 TAGS
      - The second call was made shortly after the first via a Trend 30 days with 8 TAGS

      The result was that the second call was extremely slow while being processed first.
      To confirm our argument, we isolated only the second call and it responded instantly.

      QUESTIONS:

      1) There is even this "Limit Processing" by application "?

      2) It can be changed only for this application?

      3) What are the parameters need to be changed? And what is the impact to other applications using the same server?


      NOTE: This problem does not happen when using the old and discontinued DLL (PIApi).

        • Re: PI SDK affecting other users logged when one requests a TREND
          Marcos Vainer Loeff

          Hello Ludmila,

           

          These kind of performance issues are really difficult to troubleshoot through a forum as the bottleneck could be in many different products within the dataflow. Nevertheless, I will provide you some useful information in order to help you detect where the root cause of your poor performance.

           

          First of all, you said that the performance was good until the system started to get very slow. Was there any major change on your PI System including new installs or considerable raise of users accessing this web application?

           

          To begin with, I would check if some PI Server services, including PI Archive Subsystem, are overloaded. You can use Windows Tools as Task Manager and Performance Monitor as well as PI Server tools including piartool. TechSupport would be right channel to help you verify if your PI Server is overloaded.

           

          One of the advances of the PI Server 2012 compared to its previous versions is the ability to store and retrieve large amounts of data in seconds, which means better performance. But if there is a tuning parameter not well configured, this could be the reason of why it is slow. I have never heard of a "Processing Limit” that you have described but I will check the PI Server product specialist team and give you a feedback.

           

          The fact the performance of PI API is good seems to indicate that bottleneck is not on the PI Server but further analysis should be done before drawing conclusions IMHO.

           

          Concerning the client-side, your web application could be root cause of the poor performance. I would turn on the PI SDK debugging to check which calls are taking too much to complete.

           

          Here in vCampus we have some articles related to improving your PI SDK application. One of them is a white paper called “Optimizing your PI SDK Applications” located on the vCampus library under “White Papers and Tutorials” session.

           

          Nevertheless, a more effective solution would to migrate your PI SDK application to PI AF SDK 2014 which has Rich Data Access capable of connecting directly to the PI Server.  It also allows you to make similar PI SDK calls to your PI Data Archive. The main advantages of this library when compared with PI SDK are:

           

          • Reach your data with only one SDK to connect to your PI System objects (PI and AF).

           

          • Eliminate Single Threaded Apartment (STA) issues on MTA environment.

           

          • Avoid COM interop costs when coding in .NET.

           

          I would recommend you to watch this webinar and also take a look at the Hands On Lab called “Migrating your applications from PI SDK to PI AF SDK” from vCampus Live! 2013, which could be downloaded under Extras category of vCampus Download Center.

           

          Anyway, I will check if there is a “Processing Limit” on PI Server 2012 and give you a feedback.

            • Re: PI SDK affecting other users logged when one requests a TREND
              Marcos Vainer Loeff

              Hello Ludmila,

               

              According to the PI Server product specialist team, there is no processing limit per client enforced by default in PI Server 2012. The only thing close to what the customer is describing is the tuning parameter PIarchss_MaxThreadsPerClientQuery which is not new. By default this value is not set, but if they have set this then it may limit the number of RPC threads that can be used by a single client at the same time.

               

              Regarding their performance issue, there is not enough information here to make any diagnosis. I will request a Technical Support Engineer contacting you.