| keeping larger state tables in something more efficient than arrays [message #1822217] |
Sun, 01 March 2020 22:04  |
|
In many use cases in the Osmocom (http://git.osmocom.org/osmo-ttcn3-hacks/) test suites we are creating state tables of a given protocol layer in order to run multiple parallel test components on top.
This is a re-appearing pattern you can find in many telecom protocols. In the end you have N tunnels, N channels, N subscribers, ... and you want to have one component that receives messges from the underlying transport and which then dispatches to the per-subscriber/channel/tunnel component on top. In osmo-ttcn3-hacks, we call those the FOO_Emulation component.
In those components, you typically create some kind of state table based on some higher-level identifier, e.g. the IMSI of the subscriber. This IMSI is what de-multiplexes the received messages to individual per-subscriber TTCN-3 components.
So far, we've used statically-sized TTCN-3 arrays and linear list iteration for the related data structures. That's fine if you want to run a handful of parallel test components, like 16 or 32.
But what if you want to scale higher? For e.g. 1000 records I wouldn't want to use linear iteration over the array at every lookup. It seems neither TTCN-3 nor TITAN provide any built-in support for more efficient data structures like trees, hash tables, dictionaries, etc.
Does anyone have good ideas on how to address this? I would assume that anyone doing load/performance testing of stateful systems would run into the same kind of problem. Yes, I understand TTCN-3 is primarily used for functional and conformance testing, but given the performance of the actual TITAN-generated code, and the fact there is a "load testing runtime"... why not?
Yes, it might be possible to use a C++ implementation of a related data structure, import that as native functions into TITAN and then use such functions to look-up entries. However, I suspect the devil is in the details - like having to write lots of boilerplate code for each and every to-be-suppored data type / table.
|
|
|
|
| Re: keeping larger state tables in something more efficient than arrays [message #1822240 is a reply to message #1822229] |
Mon, 02 March 2020 10:19  |
|
Hi Harald,
a lot can be accomplished by using "record of " structures instead of arrays.
These are a lot more flexible, can be grown or shrunk at will, "lengthof" will return the position of the last pointer etc.
If not properly managed though, they can consume the whole memory if extended uncontrollably, or lead to memory leaks if not properly freed and so on;
but symptoms will manifest only for applications running for a longer period of time intensively, such as load generators for stability test etc.
Titan is being used to a great extent in load generating applications, and speed of execution was a permanent concern for design.
Best regards
Elemer
|
|
|
Powered by
FUDForum. Page generated in 0.04075 seconds
] 
Search
Help
Register
Login
Home
