|keeping larger state tables in something more efficient than arrays [message #1822217]
||Sun, 01 March 2020 22:04
| Harald Welte
Registered: July 2017
Location: Berlin, Germany
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.
Powered by FUDForum
. Page generated in 0.01534 seconds