fulfillmenttools
API documentationIncident ManagementFeedback
Developer Docs
Developer Docs
  • Developer docs
  • Getting Started
    • Quickstart
    • Integration tutorial
      • Adding facilities
      • Adding listings to facilities
      • Configuring stocks
      • Carrier configuration
      • Placing orders
      • Checkout options
      • Distributed Order Management System (Routing)
      • Local fulfillment configuration
    • Free trial
  • Technical Basics
    • Access to fulfillmenttools
    • Feature status
    • Available regions
    • Backup policies
  • Connecting to fulfillmenttools
    • Client SDKs
    • commercetools connect
    • OpenID connect
      • Configure Microsoft Entra ID / Azure Active Directory
      • Configure Keycloak
  • API
    • Core concepts
      • Authentication & authorization
      • API Versioning & lifecycle
      • Assign user to jobs
      • Localization
      • Resource timestamps
      • Custom attributes
      • Article attributes
      • Recordable attributes
      • Data update guarantees
      • Rate limits & scaling
      • Retries
      • Performance on test vs. production systems
      • Load testing
    • API calls
      • Postman
      • cURL
      • GraphQL Explorer
    • GraphQL API
    • RESTful API
      • Pagination interface
      • RapiDoc
      • OpenAPI 3.0 Spec
    • Eventing
      • Structure of an event
      • Available events
        • Event flows
      • Eventing example
      • Event export
  • Integration Guides
    • Basics
      • Article categories
      • Audits
      • Facilities
      • Facility groups
      • GDPR configuration
      • Listings
      • Remote configuration
      • Receipts
      • Search
      • Subscribe to events
      • Sticker
      • Stocks
      • Storage locations
      • Tags
      • Users
    • Channel inventory
    • Inbound process
    • Outbound stocks
    • Purchase order
    • Receipt
    • Routing strategy (context-based multi-config DOMS)
    • Show sticker to clients
    • Stow jobs
  • More Integration Guides
    • Carrier management
      • Introduction to carrier configuration
      • Required data when operating carriers
      • Adding & connecting carriers to facilities
      • Custom carrier
    • Configurations for order fulfillment
      • Picking configuration
      • Packing configuration
      • Handover configuration
      • Printing and document configuration
      • Packing container types
      • Parcel tag configuration
      • Headless order fulfillment
      • Short-pick reasons
      • External documents in order fulfillment
      • Service jobs
      • Load units
      • Running sequence
    • DOMS - distributed order management system (routing)
    • External actions
    • Interfacility transfer
    • Notifications
    • Orders
      • Place your first order
      • Ship-from-store orders
      • Click-and-collect orders
      • Locked orders
      • Order with custom services
      • Bundled items in an order
      • Order process status
    • Availability & promising
    • Returns
Powered by GitBook
On this page
  • Load test types
  • Define load test scenario
  • How to conduct the load test
  • Target Environment
  • Fair Use Policy and Rules for Load Tests
Edit on GitHub
  1. API
  2. Core concepts

Load testing

Last updated 2 months ago

A load test should evaluate the integration with the fulfillmenttools platform under regular expected traffic and peak loads. fulfillmenttools suggests performing a load test before going live with the integration.

Load test types

Two types of load tests exist: regular traffic and high traffic scenarios.

Regular traffic scenarios: The simulation models typical daily traffic, excluding promotions, and represents the steady state.

High-traffic scenarios: A high-traffic scenario includes simulating sudden traffic peaks, such as the launch of a TV campaign that is expected to increase traffic by 30%.

Define load test scenario

First, define the load test use case. Write down the traffic goals, use cases, and endpoints under test. Next, the load test scripts (e.g., using k6 load testing or siege) are created to simulate real traffic. It is essential to be as realistic as possible. Mimik, actual users visiting PDP pages, creating orders, fulfilling orders via headless order fulfillment, etc.

How to conduct the load test

Prepare the system: All required data, e.g., facilities, listings, stocks, etc., should be available on the system before starting the load test. The base for the load test.

Use these scripts to conduct the load tests. To reduce network overhead, the load test should be executed from a machine near your fulfillmenttools instance deployment (see ). For optimal results, execute load tests from a cloud provider machine instead of a local machine.

Each load test must always be executed in two phases:

Phase 1 - ramp up

In this phase, slowly ramp up the traffic over 20 minutes to make the fulfillmenttools platform scale up and be ready for the load test.

Phase 2 - load test

Record the results and conduct the load test with the previously defined traffic for 30 minutes.

Afterward, clean the system and delete all data created during the load test.

Do not start the first load test with the final traffic goal. First, start with a small traffic goal and slowly increase the load in later executed load tests.

Target Environment

Fair Use Policy and Rules for Load Tests

Typically, a customer has a test (functional pre) and a production system (see ). fulfillmenttools does not support load tests on these functional pre-environments. Nevertheless, a load test pre-environment can be ordered via the . Furthermore, production environments can be load-tested with real customer traffic before going live. Clean up the data after the load test to ensure a clean system for the go-live.

Do not attempt to crash the fulfillmenttools platform with a load test. Load tests should always target expected traffic. It is forbidden to conduct load tests with sudden request spikes (e.g., from 0 req/sec to directly 1000 req/sec). It is essential to conduct a Ramp-up phase before the load test. Generally, fulfillmenttools allow one high-traffic scenario and one regular steady performance test per working day. Additional load tests may be performed before the launch. Contact fulfillmenttools via the to discuss this process.

available regions
performance on test vs. production systems
contact form
contact form