Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Test Results Summary of Standalone SBR Carrier

 

This section provides performance summary results of tests to estimate the maximum SBR Carrier load in a given use case or collection of use cases on a given set of systems. You can break down the effects of the tests and use them as a baseline to make reasonable estimates of expected performance. The tests represented in this section are not exhaustive, but are intended to give an indication of scalability.

Note

In most cases, excessive load was used to determine the maximum capacity of SBR Carrier, so the test results are not representative of actual scenarios.

The results shown in this section are tested on the following hardware running on RHEL 7.2:

  • HP ProLiant DL380 Gen 9 front-end server with 32 CPUs with 8 cores per CPU, 2400 MHz, 128 GB RAM, running SBR Carrier Release 8.4.0.

Note

The results shown in this section are obtained in an environment where very few applications or services are left running during the tests.

Note

The maximum CPU utilization measured for a given process is equal to 100% times the number of virtual CPUs active on the system. In these cases, the maximum CPU utilization would be 3200%, since there are 32 CPUs. Therefore, the percentage of the total processing power of a physical machine can be calculated by dividing this measurement by the number of CPUs in the machine. Since all CPU utilization is less than 3200% and evenly distributed across multiple threads, only 81% of the total CPU on the system is utilized in these tests. In this case, SBR Carrier works well under the load.

Native User Authentication and Logging

Native User Authentication and Logging

Table 37 describes the results of tests run on the 64-bit version of standalone SBR Carrier (with 32 CPUs x 8 cores) for native user authentication using PAP and LogLevel=0 (the default).

Note

The native user subscriber database was used to eliminate network and back-end effects and is not typically used as a subscriber database in production.

Table 37: Native User Authentication and Logging

Case

Authentication Thread Count

CPU Utilization

Auth-Accepts/Sec

Disk I/O

LogAccept=0

100

996%

42,787

LogAccept=1

100

1121%

43,500

2.40 M/s

LDAP Authentication and Thread Configuration

LDAP Authentication and Thread Configuration

Table 38 and Table 39 describe the results of tests run on the 64-bit version of standalone SBR Carrier (with 32 CPUs x 8 cores) for LDAP authentication (OpenLDAP) using BindName.

Increasing the authentication thread count along with TPS results in increased performance as shown in Table 38. See Table 38 for the recommended authentication thread configuration based on the TPS.

Table 38: LDAP Authentication Only Without Latency

TPS

Authentication Thread Count

CPU Utilization

MaxConcurrent in ldapauth.aut File

Number of Server Sections (round-robin fashion)1

5000

100

121%

100

10

10,000

100

230%

100

10

15,000

200

498%

100

10

20,000

500

2490%

500

20

1See our Knowledge Base https://kb.juniper.net/InfoCenter/index?page=content&id=KB27024&actp=METADATA for more information on how the target host is determined when multiple server sections are configured in the LDAP and SQL authentication files.

With an increase in the backend latency for LDAP authentication-only load (see Table 39), the transaction rate is reduced even though more authentication threads are configured. This will impact the performance of SBR Carrier.

Table 39: LDAP Authentication Only With Backend Latency

Latency

TPS2

Authentication Thread Count3

CPU Utilization

MaxConcurrent in ldapauth.aut File

Number of Server Sections (round-robin fashion)

1 millisecond

6500

5,000

481%

100

20

3 milliseconds

2840

10,000

198%

100

20

5 milliseconds

1812

10,000

124%

100

20

2TPS = Total accepts / 600 seconds

3More threads are required with higher latency because each thread holds the transaction state until a response is received or the request times out.

SQL Authentication Only

SQL Authentication Only

Table 40 and Table 41 describe the results of tests run on the 64-bit version of standalone SBR Carrier (with 32 CPUs x 8 cores) for Oracle SQL authentication only.

Table 40: SQL Authentication Only Without Latency

TPS

Authentication Thread Count

CPU Utilization

Number of Server Sections (round-robin fashion)

5000

100

190%

10

10,000

100

391%

10

15,000

200

503%

10

Table 41: SQL Authentication Only With Backend Latency

Latency

TPS

Authentication Thread Count

CPU Utilization

Number of Server Sections (round-robin fashion)

1 millisecond

3830

10,000

142.3%

10

3 milliseconds

1492

10,000

69%

10

Native Accounting Start Only

Native Accounting Start Only

Table 42 describes the results of tests run on the 64-bit version of standalone SBR Carrier (with 32 CPUs x 8 cores) for native accounting start only.

When TPS is increased along with the accounting thread count, CPU utilization and Disk I/O will also be increased. See Table 42 for the recommended accounting thread configuration based on TPS.

Table 42: Native Accounting Start Only

TPS4

Accounting Thread Count

CPU Utilization

Disk I/O

5000

200

134%

3 M/s

10,000

200

232%

4 M/s

15,000

200

466%

6.8 M/s

20,000

500

537%

8 M/s

4TPS = (Total accounting requests - Dropped accounting packets) / 600 seconds (drops are usually caused by thread exhaustion).

Native User Authentication, Accounting Start, Accounting Stop

Native User Authentication, Accounting Start, Accounting Stop

Table 43 describes the results of tests run on the 64-bit version of standalone SBR Carrier (with 32 CPUs x 8 cores) for native user authentication, accounting start, and accounting stop.

With native user authentication, accounting start, and accounting stop load, the CPU utilization increases with an increase in the CPS rate as shown in Table 43.

Table 43: Standalone: Native User Authentication, Accounting Start, Accounting Stop

CPS5

CPU Utilization

Disk I/O

10,262

2092%

2.3 M/s

12,400

2220%

2.7 M/s

13,300

2283%

3 M/s

5CPS = [Total accepts + (Total accounting requests - Dropped accounting packets)] / 600 seconds

LDAP Authentication, Accounting Start, Accounting Stop

LDAP Authentication, Accounting Start, Accounting Stop

Table 44 describes the results of tests run on the 64-bit version of standalone SBR Carrier (with 32 CPUs x 8 cores) for LDAP authentication, accounting start, and accounting stop.

With LDAP user authentication, accounting start, and accounting stop load, a higher number of threads is required to handle increased transaction rates, resulting in higher CPU utilization as shown in Table 44.

Table 44: Standalone: LDAP Authentication, Accounting Start, Accounting Stop

CPS

Authentication Thread Count

Accounting Thread Count

CPU Utilization

Number of Server Sections

MaxConcurrent in ldapauth.aut

LDAP Server CPU Utilization6

5000

100

200

426%

10

100

75%

10,000

2,000

3,000

2598%

10

100

140%

6LDAP server hardware configuration—25 GB RAM, 8 CPUs with up to 4 cores per CPU.

SQL Authentication, Accounting Start, Accounting Stop

SQL Authentication, Accounting Start, Accounting Stop

Table 45 describes the results of tests run on the 64-bit version of standalone SBR Carrier (with 32 CPUs x 8 cores) for SQL authentication, accounting start, and accounting stop.

With SQL user authentication, accounting start, and accounting stop load, the CPU utilization increases with an increase in the authentication or accounting thread count and CPS rate as shown in Table 45.

Table 45: Standalone: SQL Authentication, Accounting Start, Accounting Stop

CPS

Authentication Thread Count

Accounting Thread Count

CPU Utilization

Number of Server Sections

MaxConcurrent in ldapauth.aut

SQL Server CPU Utilization

5,000

100

200

412%

10

100

60%

10,000

2,000

500

1235%

10

100

200%