I leave this note to close the thread from my perspective. The approach of moving to event based processing has been wholly successful. With more than two hundred separate tags being monitored as events, there is no significant CPU usage, even when the change rate is quite high.My application using QuickOPC to interface into real world OPC servers is now operating in a production implementation, and I am about to roll it out over all the OPC interface machines in our portfolio.Thanks for your help.

Yes, The OPC connector is the server equivalent.I have implemented subscriptions in my real world environment and they seem to be working well. No sign of high CPU usage so far. I will monitor it in periods of high event rates to see if there is any trace of CPU usage rising.Whilst adapting the events handling code into my existing structures, I noticed something that doesnt seem quite right. In your example, you use "DEasyDAClientEvents" as a class name and use that name to define the $sinkinterface in com_event_sink(). If I change that class name to say "MyEvents" it stops working, until I change only the $sinkinterface parameter of com_event_sink() back to "DEasyDAClientEvents", when it starts to work again.Is this an anomaly, or am I misunderstanding the purpose of the $sinkinterface value?

Thank you very much for your event handling example. You are doing a lot of work on this for me (initially) and I do appreciate it.I will attempt to get your example running in my scenario and let you know if I am successful. My PHP implementation is non-traditional, and there is quite a lot of CLI activity that is not directly web request related. My "application" allows a permanently open web page with continuously changing content.In my scenario, using item change triggering to read values should result in a couple of orders of magnitude drop in the amout of $X->Vtq->Value method calls, so may reduce the abberant CPU usage to a level where it does not accumulate.Can you help me understand if it is possible for the real world OPC connector to impact PHP reported CPU usage through your QuickOPC-COM? I have checked and the OPC connector is not using much CPU or Ethernet bandwidth. Is it likely that calls to Vtq->Value are promulgating through QuickOPC-COM into code within the third party OPC connector?

That is disappointing. I was hoping that was whathttp://php.net/manual/en/function.com-event-sink.phpwas for.I am in the process of setting up another real world OPC server interface using a server from a different source. It will take some time. I will report back on whether the CPU usage problem occurs when connected to the new server.

I have tried the Vtq->Value method. The CPU usage increases at a slower rate (~30%) for the same number of tags and request frequency, but it still rises to the same order of usage.Perhaps I should try subscriptions. Can you give me some sample code to make this happen in PHP?