# Load test

> Load testing is an important phase of every project and must be conducted with care and in coordination with Talon.One.

> For the complete documentation index, see [llms.txt](https://docs.talon.one/llms.txt).

:::important
- If you are using a prospect deployment, do not perform load testing.
- After you start using Talon.One in production, we suggest that you no longer perform
  load testing in the same deployment because it uses the same database and infrastructure.
  For alternatives, contact our [support team](mailto:support@talon.one) or your
  Technical Account Manager.
:::

## Configure your deployment for load testing

Before launch, you may have reduced resources in Talon.One than what you will have once in
production. Ask Talon.One to configure your deployment with production-ready
resources and include the following information:

- Planned date / time and duration of test
- Type of test (Capacity, stress, soak, etc.)
- Max requests per second
- The endpoints you plan to send requests to, and in what proportions
- Your availability for a call before testing starts

## Load testing best practices

After Talon.One has configured your deployment, you can start planning your
load test, respecting the following best practices:

1. Use _only_ sandbox Applications to avoid populating your live Applications with test data.
   See [Application environments][env].
1. Use dry requests when appropriate. See [Dry requests](/docs/dev/integration-api/best-practices.md#dry-requests).
1. Use a realistic number of requests reflecting your
   peak traffic, or a reasonable multiplier over expected traffic.
1. Send [Update customer session](/integration-api#tag/Customer-sessions/operation/updateCustomerSessionV2)
   requests to Talon.One only when needed, for example when a customer adds an
   item/coupon to a cart.
1. Randomize `profileIds` and `sessionIds` to avoid concurrent session updates on a given
   session.

   :::note Managing parallel requests
   For data integrity purposes, Talon.One allows three parallel Integration API requests _per_
customer **profile** or **session** integration ID.
Parallel requests are queued and processed sequentially.
The queue is **limited to two requests**. Extra requests will receive a 409
_Too many requests are updating this profile/session at the same time_ response.

**We recommend only sending sequential requests.**

This applies to the following endpoints:
- [Update customer profile][cp]
- [Update customer session][cs]
- [Track event](/integration-api#tag/Events/operation/trackEventV2)

For example, consider the following parallel requests:

- One `Update customer profile` request on a given `customerId`. This request is
  being processed.
- Two `Update customer session` requests involving the same `customerId` as the
  request above. These two requests are queued.
- Extra requests, for example, a request to `Track event`, related to the same `customerId`
  will receive a 409 response.

[cp]: /integration-api#tag/Customer-profiles/operation/updateCustomerProfileV2
[cs]: /integration-api#tag/Customer-sessions/operation/updateCustomerSessionV2
   :::

## Performance tips

**Do more with one call:** The
[Update customer session](/integration-api#tag/Customer-sessions/operation/updateCustomerSessionV2)
and [Update customer profile](/integration-api#tag/Customer-profiles/operation/updateCustomerProfileV2)
endpoints offer a `responseContent` property that you can use to save API calls.
For example, you can use this property to retrieve the customer
profile information without having to use another endpoint.

**Reduce response time:** When you query the `Update customer session` or
`Update customer profile` endpoint but
do not want the request to modify your Application, set the `runRuleEngine` and `dry`
parameters to `true` to send a [dry request](/docs/dev/integration-api/best-practices#dry-requests) and
get faster response times.
You will still see the returned effects but there will be no change to your Application.

**Use a single event for a single customer action:**
When implementing customer actions, consider that each [event](/docs/dev/concepts/entities/events)
represents a single occurrence of a customer action related to a customer session
or customer profile. To avoid receiving too many 409 responses, ensure that
the customer action does not trigger multiple events in parallel.

[env]: /docs/product/applications/overview.md#application-environments