- Thank you received: 0
Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
high CPU usage in PHP, using ReadMultipleItems, ToString
29 Sep 2010 11:26 #87
by support
Replied by support on topic Re: high CPU usage in PHP, using ReadMultipleItems, ToString
I will try to reproduce it here.
Some initial thoughts and answers:
1) In the loop you provided (foreach($results as $X) $result=$X->Vtq->ToString()
, there is actually a lot of switching between your application, and the QuickOPC-COM (i.e. eopcdal process, if "Local Server" is used). Retrieving the Vtq property needs one switch to QuickOPC, and calling ToString another switch. And the CPU load would be generated by both processes. That itself, however, should not be a problem, and unless we are talking some extreme data such as megabyte-sized strings, the CPU should remain relatively low.
2) I would not expect any direct relation to which target server is used. The fact that this does not occur with the test server is weird. What kind of data is the real server returning? Isn't it possible that some or all of the readings have failed? In such case, the ReadMultipleItems method itself would succeed, but the Vtq property would not be accessible, or more precisely, an attempt to access it would return a failed HRESULT, which in most hosts leads to a runtime exception - but maybe we need to check precisely what PHP does, especially in this kind of loop.
3) If you suspect that the ToString method is causing this, have you tried something a bit different? - such as extracting the Vtq->Value (or other sub-properties), and converting it to a string in your app code instead?
Some initial thoughts and answers:
1) In the loop you provided (foreach($results as $X) $result=$X->Vtq->ToString()
, there is actually a lot of switching between your application, and the QuickOPC-COM (i.e. eopcdal process, if "Local Server" is used). Retrieving the Vtq property needs one switch to QuickOPC, and calling ToString another switch. And the CPU load would be generated by both processes. That itself, however, should not be a problem, and unless we are talking some extreme data such as megabyte-sized strings, the CPU should remain relatively low.2) I would not expect any direct relation to which target server is used. The fact that this does not occur with the test server is weird. What kind of data is the real server returning? Isn't it possible that some or all of the readings have failed? In such case, the ReadMultipleItems method itself would succeed, but the Vtq property would not be accessible, or more precisely, an attempt to access it would return a failed HRESULT, which in most hosts leads to a runtime exception - but maybe we need to check precisely what PHP does, especially in this kind of loop.
3) If you suspect that the ToString method is causing this, have you tried something a bit different? - such as extracting the Vtq->Value (or other sub-properties), and converting it to a string in your app code instead?
Please Log in or Create an account to join the conversation.
Moderators: support
Time to create page: 0.084 seconds