Server-side testing refers to the process of testing the server components of an application. This includes testing the server's performance, security, load handling, and more. It's an essential part of ensuring that an application is robust, secure, and capable of handling real-world usage.

Some key terms and concepts related to server-side testing:

• User Identifier: This is a unique identifier that can be used to assign users to a test group in a deterministic manner, also known as 'traffic splitting'. This identifier should persist across pages and visits.

• Statsig SDK: This is a software development kit provided by Statsig. It needs to be initialized with a fresh 'config' to reflect up-to-date experiment rules configured in the Statsig Console.

• Test Group and Parameters: The Statsig SDK is used to get the assigned test group and its parameters. These parameters are then used to generate and serve the proper experience to the user.

• Edge: This is the server nearest to the viewer. Code can be run at the "Edge" to manipulate the incoming request prior to the Cache lookup.

• Cache: This is a server that stores static assets like content, web pages, media, etc. These servers are designed to deliver static assets with low latency.

• Colocated: This term refers to services located in the same network. Colocated services can call each other with minimal latency since requests don’t travel across the public internet.

• Origin: This is the server that the cache is working for. It's usually a web/application server that generates and serves content based on the path a visitor navigates to and other contextual information.

• Cache-hit ratio: This refers to the frequency with which the cache serves content.

For example, when running an experiment, you might use the user identifier to assign users to different test groups. You would then use the Statsig SDK to initialize the experiment and get the assigned test group and its parameters. The assigned group and parameters would then be used to generate and serve the appropriate experience to the user.

In terms of server-side testing, you might test how well the server handles traffic splitting, how effectively the cache serves content, and how well the server performs when running code at the "Edge".