Optimizing Memory Utilization

In general, the memory requirement for dsTest depends upon two items: dsTest infrastructure and your test configuration. The amount of memory required to load dsTest itself is dependent upon the platform, and will be consistent on all platforms with the same underlying technology. dsTest runs all tests memory-resident so there must be sufficient memory to retain all of the node, interface application, and subscriber information. Most of the memory consumption will occur when the test configuration is loaded, with some growth occurring as nodes and subscriber sessions become active. In this topic we'll focus on how you can optimize the memory required for your test configurations.

The subscriber database consumes the most memory in all but the simplest test configuration. The number of subscribers is an obvious driver in memory consumption, and you should only configure the number of subscribers necessary for your test, but there are less obvious ways that you can improve your configuration to save memory.

Subscriber Identities: You can configure multiple identities for each subscriber and some of those identities are only required on certain interfaces. Since an identity is unique to a subscriber every configured identity results in a memory allocation for every subscriber. For example, an IMS private or public identity consumes 64 bytes and you can configure up to five IMS identities for a subscriber. In a database with five million subscribers, simply storing one public and one private identity would consume 610MB of what would be wasted memory if that particular test did not involve IMS.

Dynamic Information: Like Subscriber Identities, the data configured in the Dynamic Information section of a subscriber group is retained on a per-subscriber basis. If you decide to copy a database that was used in an S6 test to jump start your Gx test configuration, for example, you won't need the MME Identity that was configured for S6.

Subscriber Profiles: Profiles are shared among the subscribers that are linked to them, and compared to the previous two areas do not present the same potential for large memory waste. If your configuration is straining the limits of your platform, however, getting rid of any profile instances that you're not using or instances of profile contents such as multiple APNs in a Subscription Profile or CDR configurations in a PCC Profile may reduce enough of the memory requirement.

Session ID: Memory utilization can also be significantly impacted by the session ID that is generated by other devices. Session IDs that have multiple fields changed from one subscriber to the next can cause the lookup tree structure to grow geometrically rather than linearly. dsTest provides the <session_lookup_optimization> configuration element set to "memory" to help control this memory growth.

See Defining Subscribers to learn more about how the Subscriber Database is organized.

The number of node emulators and the number of interfaces configured on each node will affect the memory consumed during the test. Unless the intent of your test is to stress test the server-side of an interface application with the maximum supported connections you should use the minimum number of nodes and interfaces needed to produce the desired traffic volume.

Transaction count can be defined for every interface application, and it specifies the maximum number of concurrent active transactions that application should support. A transaction only exists from the time a request is sent until the response is received in a stateless application such as S6. With a stateful application such as Gx, however, a transaction is active for the lifetime of a session - from initiation to termination. When you load a test configuration dsTest allocates memory for the number of transactions defined for each application configured, and it will allocate memory for 100 concurrent transactions by default for any application that lacks a defined transaction count. The default value will allocate more transactions than are needed for a functional test and will likely be insufficient for a performance test using a stateful application.

On the client side, determining the correct transaction count value for a stateful application can be as simple as multiplying the action rate by the session duration and adding a cushion of 10% to handle latency or processing delays in the DUT. If you're initializing 100 sessions per second and terminating each session after 45 seconds then you would need to allow for 4950 active transactions (100 x 45 x 1.1) no matter how many subscribers are in your database. Calculating active transactions on the server side is a bit more challenging. If you're running both sides and testing a device in the middle, your server side application will need to support the active transactions from all of your clients. If you're not sure what type of load to expect you can use the measurements described below to help you determine the appropriate level during test development.

Every interface application provides measurements that enable you to assess the level of transactions allocated:

Transactions Available reports the number of unused transactions in the current report interval.

No Transactions Available reports the number of times, over the duration of the test, that a transaction could not be created because all allocated transactions were in use.

Transactions Active (stateful applications only) reports the number of transactions consumed in the current report interval.

Finally, you can obtain an estimate of the resources that are required for a specific test case with the Calculate Resources button in your dsClient Desktop workspace or with the dsClient Terminal resource command as shown below. dsTest will analyze the configuration for resource requirements - capacity and performance - and indicate whether the current platform can accommodate those requirements.

dsTest> resource /usr/local/devsol/dsTest/examples/example_app_gx_rx_MultiNode_SmartEvents_pcef_cscf.xml

In order for dsTest to assess the Transactions-per-Second (TPS) required for your test, you must configure the expected TPS for each interface application. See Estimating TPS for more information.