Socket performance testing guidelines

Before you can test the performance of TCP/IP socket-based applications, set up your test environment and incorporate these guidelines to produce reliable performance tests.

Limitations

You can use this extension to test applications that run in a client-server model, where the test simulates multiple clients that connect to one or several servers. Other models, such as peer-to-peer networks, are not supported.

Test Performance does not support socket recording in the 64 bit versions of Microsoft Windows 2003 and Windows XP. Also, you cannot record 64 bit applications on 64 bit Windows 10 and Windows 2016 systems.

Performance

When you deploy performance tests, use a relevant number of virtual users on a given computer is important. For example, if you deploy too many virtual users on a single computer, the results will reflect more the load of the test computer than the load of the server.

For best results with performance tests on an average test computer with a 1 GHz processor and 1 GB of RAM, do not exceed 1000 concurrent virtual users.

If you exceed the number of virtual users that a single test computer can run, the measured performance of the server will be affected by the performance of the test computer, which will invalidate the final results.

When editing a schedule for long performance tests, use these guidelines:
  • In the schedule editor, reduce the Test log level to None.
  • In the schedule editor, set the Statistics sample interval to approximately 1/60 of the run time, for example 12 minutes for an estimated 12-hour session.
  • When possible, use loops inside test suites rather than loops in the schedule. Using loops inside test suites avoids connection problems that might occur over long duration tests and emphasizes measurement of the send and receive activity rather than connection and close activity.

SSL/TLS Authentication

Socket tests support simple or strong Secure Sockets Layer (SSL) or Transport Layer Security (TLS) authentication mechanisms, also called server authentication and client authentication.

For server authentication, the client must determine whether the server can be trusted. When you are recording or running a socket test with a proxy recorder, the proxy recorder sits between the server and the client. Therefore, you must "trick" the client application into behaving as though the proxy recorder is the certified server by performing either one of the following actions:
  • Configure the SSL or TLS settings of the recorder proxy to authenticate itself as the actual server to the client and as the client to the service. This means that you must supply the recording proxy with the adequate certificates.
  • Configure a managed client (an external client application) to accept the proxy recorder as though it were the certified server. The recording wizard provides a link to download and import an Test Performancecertificate into the client application.

For client authentication, the server must authenticate the test client according to its root authority. Therefore, you must provide the client certificate that is expected by the server to authenticate the proxy recorder or the test agent as a certified client.

See Digital certificates overview for more information about managing digital certificates.