Performance & Optimization
Home Product
Details Free 
Demo Pricing &
Ordering Related
Products Support About Us

Back to all documents

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:

  • Causes the least overhead on the OPC Web Client
  • Causes the least overhead on the OPC Server(s)
  • Causes the least overhead on the Transport Medium (serial/ethernet line)
  • Causes the least overhead on the PLC/Device
  • Causes the least overhead on the Computer

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 nature of your system, is it a web-based application, an NT Service, a script?
  • The nature of your end-devices, your PLC's or Machines.
  • The transport medium, i.e. if you are using Serial communications or Ethernet etc.
  • The kind of data you need to access the frequency in which you will need it, for example:
    • the overall number of tags that will be in use at any given time.
    • the data-type of those tags, afterall a FLOAT requires more bandwidth than a BOOLEAN.
    • the amount of "shared" data that will be common among all clients/users.
  • The number of "end-users" or "client-applications" that will "eventually" be in use at any given time.
  • The overall horse-power thats available from your hardware (PC, transport and PLC/Devices).

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:

  • The ability/requirement to read 100 FLOATS per second.
  • The need to be able to scale-up the application from one-user, to N-users.
  • The requirement to keep CPU/PLC resources to a minimum.

Where to Optimize

Optimization REALLY occurs at ALL levels of a system:

  • PLC
    • Keeping all of your memory registers (Tags) in sequential locations. This enables OPC Servers to perform block-read transactions resulting in more data using less bandwidth and resources.
    • Utilizing the best possible communications transport at your disposal, such as 100BaseT Ethernet, or maximizing the Baud rate on a serial communication.
    • Increasing the CPU time-slicing on a PLC/Device (such as Allen-Bradley ControlLogix) so as to spend more time servicing Ethernet requests vs. ladder-logic.
  • Transport medium
    • Use a dedicated Ethernet/network where possible. This will equate to less traffic resulting in faster access/response times.
    • If you cannot use a dedicated Ethernet/network, be sure to use Routing to segment network traffic.
    • Avoid "noisy" devices that could interfere with the Ethernet/network.
  • Computer
    • Be sure to have the best/fastest CPU, RAM and Hard Drive configurations available to you.
    • Insert as much RAM into your computer as you can.
    • Use a true 32-bit Operating System (Windows 2000 or newer is preferred)
    • Remove unwanted and unnecessary software from the computer.
    • Avoid using software that could consume resources in the computer, or on the transport medium.
  • OPC Server
  • OPC Client Software
    • Use only those Tags that you actually need.
    • Perform as many "block" read/write transactions as possible.
    • Avoid "over-requesting" data "because you can", instead you should request data at rates that are realistic and not over-taxing on your 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.
RELATED PAPER: ActiveX Vs. 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

    • Do I need ALL of these Tags? or can I get away with less?
    • Do I need these Tags at this rate of speed? or can I go a little slower?

    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:

    • use the ".ReadMultipleItems" and ".WriteMultipleItemValues" to send/receive a number of Tags within a single transaction.
    • use the "poll" method to receive event notifications when a Tag's value changes.

    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.
148A East Charles Street, Matthews, North Carolina, USA 28105
Phone: 704-849-2773 or 1-888-665-3678 (US), Fax: 704-849-6388
sales@softwaretoolbox.com | support@softwaretoolbox.com