Introduction

This page explains which batch sizes the mapping-extension uses. As the main module the extension separates the documents into batches. You can find more information about that in the documentation of the main module.

Configuration

{
  "extensions": {
    "Synqup\\Modules\\Shopware6MappingExtensionBundle\\Subscriber\\Shopware6MappingExtensionBundleSubscriber": {
      "...": "...",
      "batchSizes": {
        "validate": 200,
        "upsert": 75,
        "delete": 100,
        "referenceExtract": 200,
        "referenceCache": 50
      }
    }
  }
}
  • validate determines the number of documents that are validated per message.
  • upsert determines the number of documents that are created or updated in a Sync API request
  • delete determines the number of entities that will be deleted per request.
  • relationsExtract determines the number of documents that are analyzed for referenced Shopware values per message
  • relationsCache determines the number of entities that are queried and cached in a single API request

Recommendations

You can find more information about recommended batch sizes and some batch size theory in the documentation of the main module.

In the following section you will find some advice regarding batch sizes in the mapping-extension.

As in the main module there is no definitive answer to the question "What batch sizes should I use?". In short: Use the default batch sizes from the configuration above as a starting point. In many cases these values will probably work for you. However, if you have the feeling the mapping-extension is too slow in huge data sets, feel free to experiment with (much) larger batch sizes.

In general, the mapping-extension handles documents that are usually way less complex compared to the main module. This leads to api requests that are less complex as well. That's why way bigger batch sizes are supported without negative side effects. This can help to greatly reduce the overhead mentioned in the documentation of the main module.

Good batch sizes heavily depend on the size of your data. If you use very big batch sizes in small data sets you do not benefit from handling documents in parallel. On the other hand, if you use small batch sizes in big data sets, the overhead for handling messages and api requests gets too big.

The most important thing to consider while increasing the batch size of the upsert subsection is the complexity of the generated entities. The more references an entity contains the more careful you should be with increasing the batch size to very big numbers.

So bottom the line, please feel free to experiment with batch sizes. Especially in the mapping-extension, even switching to extreme batch sizes (5000+) in subsections that do not generate requests, already helped to improve the performance in some special cases.