![]() |
|||||||||||||||||
|
|
|||||||||||||||||
|
Performance and optimization strategies For the most-part, the OPC Web Client is already "optimized". But what does "optimized" mean? This paper defines "optimized" as: Knowing your own system The key to optimization is to first understand, no, TRULY understand your system. Ultimately you would have a very good understanding of your system's needs before your
development project began, and if you do, then you are in the best position to optimize your system while you develop - which is ALWAYS better! Some important points about your system that you NEED to know, have some idea about, or should consider: The above list contains just some of the important considerations that you need to at least be aware of when designing, preparing or actually optimizing your system.
Optimization Goals You need, or should have some ideas on the overall performance goals of your system. You can choose to measure those goals in any way you see fit, but having goals is a good
place to start. Some example goals: Where to Optimize Optimization REALLY occurs at ALL levels of a system: The above list is not too comprehensive, but it does offer a good "general" baseline on where to start and what to think about and plan for. OPC Client Optimization This paper is specific to the OPC Web Client optimization, therefore we will not cover the optimization of your PLC(s), Transport medium, Computer or OPC Server. Because there are two components to the OPC Web Client you need to choose to the best tool for your job, the OPC Web Client ActiveX Controls/OPCData.NET Components and the
OPC Web Client Web Service. OPC Clients do "somewhat" control what the OPC Server is doing, therefore you should be considerate as to what your application is requesting and the impact it may/will have
on those items listed in the "Where to optimize" section. Let's try to break-down the "typical" areas where you can optimize your OPC Client application: Limiting the number of Tags being accessed With the available computing horse-power and with increased network bandwidth available today, it is all too easy to start requesting Tag values
(reads) for a large number of Tags at a high rate of speed. This is a topic where you need to ask yourself two primary questions Avoiding "over-requesting" tag values Sometimes an application is large-enough that you will need a high number of tags at a high-rate of speed, this is inevitable in some projects. However, you do need to
consider the effects of having other OPC Clients/Systems being used in your environment. One "greedy" OPC Client can have a major impact on other clients/systems. Avoiding trips to the OPC Server Each time your client application performs a Read or a Write, a trip is being made to the OPC Web Client back-end engine. Consider a web-based application that uses the OPC
Web Client Web Service where you are constantly updating 10 Tag values on a screen every quarter of a second for example... 10 Tags being individually read per second equates to 10 x 4 = 40 individual trips to the OPC Web Client Web
Service. You have two ways of avoiding this way of working: You can choose which method suits your needs the best. Summary The OPC Web Client can lend itself to a large number of uses, but your implementation (as with any tool/component) is key to the success of your system as a whole. This paper has outlined that optimization occurs at all levels of a system, from the PLC through to the Client and everything in-between. With careful consideration you can
indeed achieve maximum performance utilizing minimal resources at all levels of your system. While there is no "one solution fits all" configuration that can be recommended, you and your needs will ultimately decide (given the information above) which solution will
work best for you. |
|||||||||||||||||
|
Copyright Software Toolbox, Inc., 1996-2004, All Rights Reserved Worldwide. |
|||||||||||||||||