• Replies 6 replies
  • Subscribers 585 subscribers
  • Views 226 views
  • Users 0 members are here
Options
Related

Large performance drop with many equipment parameters

Brandon

Hello,

One of the projects (Using Citect Studio 2018 R2) I am working on uses a very universal supergenie, where all configuration is done through Equipment Parameters. This makes things streamlined, and easy to automate, but we've found that there are serious performance issues.
I have attempted to raise my concerns at the size of the page dynamic objects dbf, however other members of the team who have been testing these pages are adamant that there is a distinct and significant drop in performance when there are around 1000 or more Equipment Parameters active amongst all pages / popups.
My current best guess is that it is hitting a limit in a buffer somewhere, and has to create an additional buffer / disk request that doubles the delay in response.

I have attempted to search for any knowledge on limits on Equipment Parameters, or Associations, but have not had any luck.

Besides reviewing our philosophy and redesigning these popups (something others are reluctant to do considering our time constraints), is there anything we can do
Something going on in the background? Anything we can change in the ini file to make this work better for us?
Anyone seen this behaviour before?

Hoping to get this sorted soon,

Brandon Yeats

Parents
  • Hi Patrick,

    I am talking about runtime, my apologies.
    I mentioned pgdynobj.dbf because I have read here and there that during runtime, the size of pgdynobj.dbf directly relates to some sort of 'list of available triggers' that is scanned through, depending on what is being displayed at the time (available triggers for each object). Having an excessively large pgdynobj.dbf often therefore causes runtime to feel quite sluggish.
    It makes sense to just simplify it and say if there's a lot going on on the page, even if it isn't changing, it'll slow things down. That almost goes without saying.

    What happens, is that my fellow engineers created a series of popups, with varying amounts of objects that contain several Equipment Runtime Parameters each in them. There was a distinct point where larger pages went from 'expectedly slower' to 'suddenly, updating took ages, inputs were not being recognised, mouse down events had to be held for seconds to have a chance of being caught etc.'
    This occurs for all runtime windows. Closing windows to reduce the number of references to Equipment Runtime Parameters causes it to go back go 'expectedly slow'.

    Despite me insisting they should redesign the popups to only look at these on page open and set page variables for ones not expected to ever change, because 'expectedly slow' is not good enough - they want to go to give the clients higher end PCs instead, as long as this sharp drop in performance (the one being discussed here) is resolved.
Reply
  • Hi Patrick,

    I am talking about runtime, my apologies.
    I mentioned pgdynobj.dbf because I have read here and there that during runtime, the size of pgdynobj.dbf directly relates to some sort of 'list of available triggers' that is scanned through, depending on what is being displayed at the time (available triggers for each object). Having an excessively large pgdynobj.dbf often therefore causes runtime to feel quite sluggish.
    It makes sense to just simplify it and say if there's a lot going on on the page, even if it isn't changing, it'll slow things down. That almost goes without saying.

    What happens, is that my fellow engineers created a series of popups, with varying amounts of objects that contain several Equipment Runtime Parameters each in them. There was a distinct point where larger pages went from 'expectedly slower' to 'suddenly, updating took ages, inputs were not being recognised, mouse down events had to be held for seconds to have a chance of being caught etc.'
    This occurs for all runtime windows. Closing windows to reduce the number of references to Equipment Runtime Parameters causes it to go back go 'expectedly slow'.

    Despite me insisting they should redesign the popups to only look at these on page open and set page variables for ones not expected to ever change, because 'expectedly slow' is not good enough - they want to go to give the clients higher end PCs instead, as long as this sharp drop in performance (the one being discussed here) is resolved.
Children
No Data
© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.