While there are many critical factors to consider when selecting a signaling solution, signaling performance is one of the most important. Signaling performance is a general measure of the system's capacity to handle large volumes of messages.
Factors that greatly impact signaling performance are:
- Transactions Per Second (TPS)
- Response time
- Open transaction capacity
Or, more simply - how quickly, how long, and how many?
With proven performance and scalability, Ulticom's Signalware® signaling software can support a wide range of signaling requirements. From small VoIP gateways with low TPS requirements (less than 100 TPS) to large network provider SCPs with high TPS requirements (5000 to 10,000 TPS and beyond). Ulticom can provide this performance with response times that are the envy of the industry.
Transactions Per Second
Perhaps the most widely used and least consistent signaling performance metric is transactions per second (TPS). In fact, TPS became a standard industry measure due to its easy calculation. However, TPS is inconsistent because transactions can vary significantly, based on the protocol used and the function performed.
A transaction is defined as the smallest set of messages that can be used to complete a function (e.g., to translate an 800 number or to connect and disconnect a call). Because functions can vary and a transaction may include one or a dozen messages, you need to know when comparing systems that the TPS reported reflects transmission of a variety of typical transactions. Since the size of the message can vary with the application, you should know the size of the messages transmitted as well.
TCAP transaction typically includes two messages, a request and a response. ISUP transactions, however, are usually more complex and must be balanced for both initiating and completing calls. If a TPS measurement only includes transactions under a single protocol, you should question why the other protocol was excluded from the testing. In addition, external variables, such as the use of databases, affect transaction rates, and you should be aware of what variables were included or omitted when the rates were calculated.
Response Time
Response time measures the elapsed time between the end of the request for a service and the beginning of the response to that request. While response time is typically expressed as minimum, maximum or average, there is a fourth measurement that more realistically reflects system response times.
The minimum response time indicates the best a system can do, but this is only achieved under ideal conditions. Maximum response time indicates the worst, but in non-real time environments this number tends to be unrealistically high, and therefore, not very useful. The average response time more accurately indicates system performance, but is still not completely descriptive of how a system will perform when deployed.
The best measure of a system's response time during real use is a 95-percentile metric. The 95-percentile metric indicates that 95% of the transactions have a response time at or less than that number.
When assessing future requirements, consider that TPS and system response times are generally determined by system efficiencies, and can be improved through enhancements such as more efficient hardware interfaces, increased processor speed, and use of Symmetrical Multiprocessing (SMP).
Open Transaction Capacity
Open Transaction capacity indicates how many transactions the system can process at any one time. This measurement is especially critical for applications that commonly support transactions of an extended duration, such as messages supporting Internet access.
The most important factor to consider when evaluating a system's open transaction capacity is the anticipated load plus the expected duration of transactions. Keep in mind that once your system reaches the open transaction capacity, it cannot respond to any other transactions until one or more of the current transactions terminate.
Open transaction capacity is primarily limited by available system memory. However, the indexing abilities of the signaling stack and applications process, as well as the number of application processes that the system supports, also limit this capacity.
When planning for future growth, consider which factors limit the transaction capacity on your system. Is it the memory, which can be easily and cost-effectively increase, or is it the limits imposed by the system, signaling stack or hardware interface, which may or may not be easily overcome?