The CGIN benchmarks test CAPv3 within a VPN (Virtual Private Network) IN application.
About the test scenario
We run two benchmarks.
-
The single-node benchmark runs the VPN application using a single instance of CGIN at 5,000 calls per second.
-
The two-node benchmark runs the VPN application using two instances of CGIN clustered over two servers, at 10,000 calls per second. Each node handles 5,000 calls.
The two-node configuration benchmarks scalability within a cluster. Differences in latency from single-node tests may be due to chatter and shared resources between nodes, which happens with a clustered install even when using high availability.
For each test, we:
-
used a call duration of 60s
-
generated load for two hours, with a ten minute ramp up period at the start
-
observed the CPU utilisation of the VPN application, the call setup latency, and the heap usage.
The VPN Application
The VPN application provides number-translation and call-barring services for groups of subscribers. It supports CAPv3 for call-control and MAPv3 for location information.
If the A party… | then VPN responds with: |
---|---|
…has called a B party in their own VPN using short code or public number |
|
…and B party are not in the same VPN |
|
…dials a short code that doesn’t exist |
|
Call flow
The VPN application applies incoming call-screening and outgoing call-screening rules, some of which require location information and involve a MAP query of the HLR.
![vpn callflow](images/vpn-callflow.png)