Large performance drop with many equipment parameters

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 Brandon,

    The symptoms you describe suggest the functions are being executed in foreground. Being a blocking function, that will result in serious performance problems impacting interaction.

    I would recommend that these are moved to a background task, which you can read/cache/refresh at per client, or page open, or whatever the sweet spot is for the data and performance.

    Once moved to a background task, the pages will be snappy again to display, however, you will still need to account for the gap between page display and parameter retrieval/processing. The purpose/design of those runtime parameters will govern what your options will be here.
Reply
  • Hi Brandon,

    The symptoms you describe suggest the functions are being executed in foreground. Being a blocking function, that will result in serious performance problems impacting interaction.

    I would recommend that these are moved to a background task, which you can read/cache/refresh at per client, or page open, or whatever the sweet spot is for the data and performance.

    Once moved to a background task, the pages will be snappy again to display, however, you will still need to account for the gap between page display and parameter retrieval/processing. The purpose/design of those runtime parameters will govern what your options will be here.
Children
No Data