> For the complete documentation index, see [llms.txt](https://docs.fulfillmenttools.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fulfillmenttools.com/documentation/getting-started/preparation-for-go-live/performance-on-test-versus-production.md).

# Performance on test versus production

As a customer of fulfillmenttools, you'll automatically have access to two environments:

1. Pre-production: The `projectId` would be `example-pre`
2. Production: The `projectId` would be `example-prd`

{% hint style="info" %}
Note that a `projectId` and a `{YOUR_TENANT_NAME}` are different. `{YOUR_TENANT_NAME}` includes ocff- whereas a `projectId` doesn't. For example, `{YOUR_TENANT_NAME}-example-pre` and `ocff-projectId-example-pre` are the same.
{% endhint %}

## Pre-production (PRE)

Pre-production (PRE) environments are suitable for functional testing of integration use cases. fulfillmenttools doesn't allow load testing in pre-production environments. For more information, refer to the [load testing guidelines](/documentation/getting-started/preparation-for-go-live/load-testing.md).

{% hint style="info" %}
In specific cases, fulfillmenttools can temporarily create a production-like environment on pre-production with similar scaling properties and database connection configurations. To request this, contact us through the [service portal](https://ocfulfillment.atlassian.net/servicedesk/customer/portals).
{% endhint %}

### Cold starts

To conserve resources, pre-production environments scale to zero when no API traffic is present for a period of time. This applies to both the REST and GraphQL APIs. When fulfillmenttools is in this idle state, it's considered "cold."

The first API request to a cold system, such as creating an order, triggers a cold start. During a cold start, fulfillmenttools initiates the necessary services to serve the API. This initial request is blocked until the API gateway instances are ready, which can take up to 30 seconds. Once the services are running, fulfillmenttools becomes "warm," and subsequent API requests respond quickly.

Because fulfillmenttools is a distributed system that uses asynchronous events for internal communication, this event distribution is also affected by cold starts. If a tenant experiences constant traffic, cold starts typically occur only when resources are scaled up.

### Scaling

Once in a warm state, pre-production scales similarly to production environments based on parallel concurrent requests and resource usage, such as CPU and memory. Details on this behavior are available in the [Limits and scaling article](/documentation/about-fulfillmenttools/limits-and-scaling.md). However, the maximum scaling configuration in pre-production differs from that in production.

## Production (PRD)

Production environments (PRD) are configured for high availability and performance. On production, the REST API and GraphQL API gateways are always "warm," meaning no cold starts occur on the first request. This configuration minimizes API latency and ensures that events are delivered promptly.

Typical activities in a production system, such as incoming orders or pick job processing, keep the asynchronous event processing services warm. The production environment configuration ensures the elasticity and scalability of both the backend compute resources and the database systems.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.fulfillmenttools.com/documentation/getting-started/preparation-for-go-live/performance-on-test-versus-production.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.