View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004131 | .NET API | Performance Problem | public | 2018-01-22 02:04 | 2021-02-03 04:37 |
Reporter | Daniel Godwin | Assigned To | Martin Regen | ||
Priority | high | Severity | block | Reproducibility | always |
Status | assigned | Resolution | open | ||
Platform | PC | OS | Windows | OS Version | 8.1 |
Summary | 0004131: Using the OPC .NET API assemblies to browse an OPC server address space can take over 30 minutes. | ||||
Description | When browsing an OPCHDA server using OPC .NET API, with a flat list of 1000 items, it takes about 20 seconds to return. var children = lBrowser.Browse(null, 0, out position); If I browse the same server using the Matrikon OPCHDA explorer, which I assume uses the standard COM interface, it only takes a couple of seconds. When browsing a server with a flat list of 100,000 items, it takes over 30 minutes. Again, using the COM interface, it takes about 40 seconds. It is not feasible for a user to wait 30 minutes to see the list of items available on the server. Can this performance be improved? | ||||
Steps To Reproduce | Configure an OPCHDA server with 100,000 items (obviously don't need this many to see the difference between .NET and COM interface performance). | ||||
Additional Information | Looking at the .NET API code, I can see that for each item on the server, the name is retrieved, and then for each item, GetItemId() is called, and this appears to be where the slow down is occurring. At a minimum, could the API be improved to allow just the names to be returned, so users could then choose a subset of items for which they need the full itemId? Ultimately though, a user may still want the itemId of every item on the server (in order to retrieve data), and so a 30 minute wait time is not acceptable. | ||||
Tags | No tags attached. | ||||
|
Servers with flat lists of 100,000 items are asking for trouble. That number of items should be divided into folders. That said, if you have to deal with such poorly designed servers you may be better off working with the GetEnum interface directly instead of using the .NET API. The code base is no longer mainatined so design improvements/feature requests are not likely to added. You should have the source code you need. |
|
Hi Randy, Also, currently our application is installing the merge module that contains the OpcNetApi and OpcNetApi.Com assemblies, OPC .NET API 4.5 Merge Module. But now we'll need to overwrite the two dlls in the GAC with our modified versions. Would that be the best approach? |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-01-22 02:04 | Daniel Godwin | New Issue | |
2018-01-22 02:26 | Randy Armstrong | Note Added: 0008845 | |
2018-01-22 02:26 | Randy Armstrong | Assigned To | => Randy Armstrong |
2018-01-22 02:26 | Randy Armstrong | Status | new => feedback |
2018-01-30 08:16 | Daniel Godwin | Note Added: 0008851 | |
2018-01-30 08:16 | Daniel Godwin | Status | feedback => assigned |
2021-02-03 04:37 | Randy Armstrong | Assigned To | Randy Armstrong => Martin Regen |