Professional OPC
Development Tools

logos

Performance with large number of variables

More
12 Jun 2018 15:26 #6435 by support
Thank you for letting us know. I am glad to hear that.

Best regards

Please Log in or Create an account to join the conversation.

More
12 Jun 2018 14:48 #6432 by mpp
Hi, I'm sorry for the late reply.

We solved it updating the OPC Server and Gateway to the last version and isolating one of the client in the code.

Please Log in or Create an account to join the conversation.

More
11 Apr 2018 14:28 #6229 by support
I will send you a download link to the email address you used to register with the forums.

Note that in order for the analysis to make sense, I need to correlate the events in the trace from OPC Analyzer with information from your application. Basically, I need you to also create a time-stamped log with each read/write you called on EasyDAClient, and the time it has taken. I will then compare the info from OPC Analyzer from the info from your app, and determine whether the problem is on the server or client side.

Best regards

Please Log in or Create an account to join the conversation.

More
11 Apr 2018 14:15 #6228 by mpp
Hi, yes in the non-test application I use the Read/Write MultipleItems where I can. Not in the test tho.

And yes I can try to use that tool, where can I get the OPC-Analyzer?

Thanks,

Please Log in or Create an account to join the conversation.

More
11 Apr 2018 06:09 #6227 by support
Hello, thank you for details.

Yes, there is a single connection shared by all the EasyDAClient objects, provided that you keep the Isolated property at its default (false), which you have confirmed.

I did not know that you are using ReadItemValue (as opposed to ReadItem). In such case, it is to be expected that the advise about turning off the automatic subscriptions would cause the slowness or timeouts you described. These two things (ReadItemValue, and automatic subscriptions) are intertwined. Sorry for having mislead you.

Using WriteItemValue is correct.

I have looked at your code and have some suggestions. I will list them here for record, but in fact, none of it is likely to be causing the problem you originally reported. Here they are:

1.. If the logic allows, use ReadItem (or ReadMultipleItems) instead of ReadItemValue, and check yourself for the quality. At the same time, turn off the the automatic subscriptions (as you have done now).
2. If the logic allows, read or write multiple items at once, using ReadMultipleItems and WriteMultipleItemValue, instead of looping through the items and performing the operation one by one.

But doing these changes right now would probably just be a distraction from the problem you have. In order to address that problem, I suggest:

- please revert the change with turning off the automatic subscriptions
- have a look at this article: kb.opclabs.com/How_to_use_OPC_Analyzer . Will you be able and willing to capture the communication traces using that procedure?

Best regards

Please Log in or Create an account to join the conversation.

More
10 Apr 2018 16:22 #6226 by mpp
I'm rerunning the tests with your suggestions.

The test is still running but the from what I can see the performance for the write function is about 10 times slower and it happened more than once to get a timeout exception (Topic not updated...)

Please Log in or Create an account to join the conversation.

More
10 Apr 2018 14:58 #6225 by mpp
Thank you for you help.
I'm preparing a new test following your instructions.

When you say:

the connection *should* stay open.

you mean that there is a single connection for all the clients right?


Here it is the code we use to read and write from a client:
 
        protected object DoGetValue(string key, bool readDevice)
        {
            try
            {
                object toReturn = null;
                var rp = new DAReadParameters() { DataSource = (readDevice ? DADataSource.Device : DADataSource.Cache) };
                var sd = new ServerDescriptor() { MachineName = connection_.MachineName, ServerClass = connection_.ServerName };
                var id = new DAItemDescriptor() { ItemId = connection_.PLC_ID + "." + key };
 
                // This method will wait for the quality to be Good
                toReturn = client_.ReadItemValue(sd, id, rp);
 
                return toReturn;
            }
            catch (OpcException opcEx)
            {
                throw new Exception("Error GetValue for " + key + ": " + opcEx.InnerException.Message, opcEx.InnerException);
            }
            catch (Exception ex)
            {
                throw new Exception("Error GetValue: " + ex.Message, ex);
            }
        }
 
        protected object DoSetValue(string key, object value, bool readDevice)
        {
            try
            {
                if (!connection_.IsDemo)
                {
                    client_.WriteItemValue(connection_.MachineName,
                                           connection_.ServerName,
                                           connection_.PLC_ID + "." + key,
                                           value);
                }
 
                return value;
            }
            catch (OpcException opcEx)
            {
                throw new Exception("Error SetValue for " + key + ": " + opcEx.InnerException.Message, opcEx.InnerException);
            }
            catch (Exception ex)
            {
                throw new Exception("Error SetValue for " + key + ": " + ex.Message, ex);
            }
        }

I am handling the exception in the test code and log it. We didn't report any during the tests.
Please tell me if we do it wrong, and if the two functions Read/Write ItemValue are the correct one to use.

Please Log in or Create an account to join the conversation.

More
10 Apr 2018 09:03 #6224 by support
Hello,
thank you for the answers.

First. I suggest that you make the settings described here: www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads , and retest. The first two are static parameters and need to be done just once, before you create any EasyDAClient. The last two need to be done on *each* new EasyDAClient instance.

Explanation: There is no direct indication that the automatic subscription mechanism is related to your issue, but disabling is is a precautionary measure. As its behaviur depends on actual timings, it behaves somewhat unpredictably, and I want to rule out that it contributes to the problem.

Second. The reason I have asked the question about Isolated, the subscriptions, the frequency of operations etc. is as follows: When there are two very different times to perform the same operation in QuickOPC, it is usually due to the fact that in one case, the connection to the server is already established (and the operation can be done quickly), while in the second case, the connection needs to be established first (and setting it up takes some time). We want to figure out whether something like this can be the cause. QuickOPC maintains the connection automatically, and (simplified) it keeps it open when there are any active subscription, OR some time after the last "single-shot" operation (such as read, write). When you repeatedly call reads or writes frequently, the connection should stay open; or, when you are subscribed. What you have described looks similar to possible re-opening of the connections (especially in the fact that it can be prevented by having a subscription around), but the default "hold periods" are around 5 seconds, so if you do anything within that time range (as you have said you were doing), the connection *should* stay open.

So, here is what I propose you/we should do:
1. Disable automatic subscriptions as described above, and retest.
2. Verify once again that your code is written in such a way that it invokes a read or write less than 5 seconds apart. If it is not doing that, either change the code (if it makes sense to do the operation faster), OR let me know and I will describe how to increase the "hold" period to any value if you wish.
3. If the above steps do not help, I suggest to use OPC Analyzer in order to figure out what OPC calls are taking place, and where the delay comes from. It is also possible that it is the *server* that takes so much time to perform the operation. Using the analyzer should tell us who is at fault.

Last but not least: Are you checking errors from the operations properly? And can you confirm you are getting no errors? Can you post the error handling piece here? It would not be surprising to see increase in times if there are some errors associated.

Best regards

Please Log in or Create an account to join the conversation.

More
09 Apr 2018 21:34 #6223 by mpp
I plot the result of the last test in the attached chart. As you can see with the subscription the write performance are good along the whole hour of test.

Why there is such a difference with the case of no subscription?

Thanks
Attachments:

Please Log in or Create an account to join the conversation.

More
09 Apr 2018 20:22 - 09 Apr 2018 20:26 #6222 by mpp
From the first test with no subscriptions I see that after ~30 minutes the performance of the write function gets really bad.

You can see it on the plot in the attached png. (ms in y axis, number of try in x axis) in the first 30 minutes the write takes some milliseconds, then the time increases up to 7-8 seconds
Attachments:
Last edit: 09 Apr 2018 20:26 by mpp.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.229 seconds

      

 Recommend this on Google