|
| Re: Performance Testing of OPC-UA [message #1796677 is a reply to message #1796638] |
Wed, 17 October 2018 12:27  |
 Antal Wu-Hen-Chang
Messages: 1
Registered: October 2018 |
Junior Member |
|
|
Hello Avdoot,
the OPC_UA adapter provides functions for encoding/decoding OPC-UA messages to/from its TTCN-3 language representation. It also has a test project, where the IPL4 test port is used for sending OPC-UA message over TCP.
Both the OPC-UA adapter and the IPL4 test port can be used to build a load tester.
Since I don't know how OPC-UA works, I am going to use generic terms below. When I write "transaction", I mean a protocol request-response pair. When I write "session", I mean a series of "transactions".
When it comes to designing a load tester, basically you have to options:
1. You can use one Parallel Test Component (PTC) for one OPC-UA "session".
This way the function that implements the test behavior is very similar (it can even be exactly the same) to an ordinary function test. Then you can use a coordinator component that spawns these PTCs and start the test function on each. The PTCs will ensure that parallel requests or "transactions" can be handled without any problems.
The load you can generate is naturally depends on your hardware. But I would say you can safely achieve a load with about 100 parallel "sessions" using 100 PTCs. But I wouldn't recommend using this approach if you need much larger load. Since TITAN maps each PTC to a heavy-weight Linux process. And as you increase their number dramatically you'll notice a lag, because the OS has to switch between them.
Just one more note: When you implement a function test, it is usually OK to reuse the same resource (like local TCP port, or session/user id) for each test case. When you do parallel execution of the "session", you'll need to take care that they won't use the same resources.
2. The second approach is using one PTC to drive several OPC-UA "sessions". The IPL4 test port supports parallel transport connections on a single PTC if it is needed. However, you'll need to design your test behavior in a different way than you normally do when you implement a simple function test case: Probably you'll need to implement the behavior using some kind of an event driven approach, where you keep track of the state of the parallel OPC-UA "sessions" and when a response is coming in, then you look up the corresponding state and handle it accordingly. With this approach you'll only need a handful of components to be able to generate a considerable load. (With our load test tools we were able to achieve several hundreds transaction/sec and several thousand parallel sessions with protocols like HTTP, or SIP)
I'd like to mention that the TITAN eclipse project has an open source library called the Core Load Library (CLL) that offers a framework and a huge number of functionality to implement a load tester (e.g. GUI, distibuted variables, statistics, logging, etc.) You can check it out from here: http://git.eclipse.org/c/titan/titan.Libraries.CLL.git/ It supports both approaches. For approach (1) it has a demo called "CentralScheduling" for approach (2) you can check out the RIoT application: http://git.eclipse.org/c/titan/titan.Applications.RIoT.git/
I also have to admit, that this library and the applications built on top of it are rather complex and huge (many thousand lines of code). So in case you need something simple and you want it soon, then probably it is easier to write that from scratch, than learning to use the framework...
I hope I helped!
|
|
|
Powered by
FUDForum. Page generated in 0.02744 seconds
] 
Search
Help
Register
Login
Home
