Every Integration App starts with at least one default connection to each endpoint, which you configure during installation. It’s important to keep that original connection online and available so that your flows and any background processes are able to reach the source and destination apps.
The connection is the primary integrator.io resource through which all requests and incoming data are regulated. Optimizing the flow of data through multiple connections is your most powerful strategy for speeding up high-traffic flow steps and taking advantage of maximum concurrency (the limit of simultaneous requests that an API imposes) for the most important data.
Contents
- Troubleshoot slow flows
- Examples for optimizing connections
- Appendix: Governance policies for common apps
Troubleshoot slow flows
Before adding connections, walk through the following checklist to try to narrow down the causes of any flows running below peak performance.
The information-gathering steps (1-4) and the solutions provided proceed from simplest to the most complex.
1. Identify the bottleneck
- Is it happening with NetSuite, another endpoint, or both?
- Try to isolate where the highest volume of data and most processing occurs.
- Review the performance explanations and tips at Fine-tune integrator.io for optimal data throughput.
- Are you retrieving additional fields, searches, files (or blobs) – or whole catalogs – unnecessarily?
- Are the timestamps on your flow run dashboards indicating longer than expected flow steps?
- Typically, exports run much faster than imports. A single request to retrieve a database table can quickly return 10 or 1,000 records. However, importing 1,000 updated records requires at least 1,000 separate requests, and sometimes many more.
- Lookup steps are designed to send requests one at a time, not in parallel, and could run slowly, depending on the payload size.
- Does the flow seem to be slowing down over time?
- Once you’ve identified a likely culprit, compare that flow or flow step with historical jobs for the same Integration App.
2. Verify the existing configuration
- Are the connections’ concurrency levels set to a lower value than what the external system can support?
- If so, increase the levels and run the flows before continuing.
- Are the Export types set correctly?
- Selecting Delta, as opposed to All, for example, has performance implications.
- Is a flow consistently slow, or might there be some temporary or cyclical factor at fault?
- Monitor the integration’s performance for a day or two and then decide the next steps.
3. Try adding one new connection and adjusting the concurrency levels for each connection to that endpoint
- Identify the priority of the respective flows within your business rules.
- The slowest flows might not be the ones most in need of attention. Start by ordering your Integration App in relative importance for your company’s integration needs. The following list represents a typical hierarchy, from highest to lowest priority:
- Orders
- Inventory
- Fulfillments
- Billings
- Product
- Settlement
- The slowest flows might not be the ones most in need of attention. Start by ordering your Integration App in relative importance for your company’s integration needs. The following list represents a typical hierarchy, from highest to lowest priority:
- Create a second connection to that endpoint.
- This secondary connection is dedicated to forming smaller queues of requests, as the result of sharing a lesser portion of the total concurrency available for the endpoint.
- Replace the original connection for lower priority flows with this new connection.
- Start small to isolate the variables, and then test the effects.
- Allocate higher concurrency levels within the connection that serves high-priority flows.
- See the example, below, Single Integration App, giving priority to order-related flows.
- Repeat this step, as needed, with a third connection – or more.
- Keep in mind that adding too many connections to the same account with low concurrency levels might have adverse effects on performance.
4. Borrow concurrency from the “main” connection
Note: This step is recommended when you have more than one Integration App installed in your integrator.io account or you have built custom flows within the App. Borrowing concurrency is an advanced option, requiring deliberate application and repeated testing.
- If you are running multiple Integration Apps, repeat troubleshooting Step 3 to add a new connection to each Integration App.
- Choose one Integration App’s connection as the “main” connection.
- Then, point all other Integration Apps’ connections for that endpoint to borrow concurrency from the main connection.
- See the example, below, Multiple Integration Apps borrowing concurrency from a connection in the Integration App with the highest priority data.
Examples for optimizing connections
The general guidelines, demonstrated below, can be summarized as follows:
- Create a secondary connection – called, for example: “NetSuite (Low Traffic).”
- Parcel out the total available NetSuite concurrency:
- Dedicate a generous share to your default NetSuite connection.
- Give the remaining concurrency to the new secondary connection.
- Replace the connection on all low-priority flows (all except Order flows) with NetSuite (low traffic).
- Borrow concurrency, if you have more than one Integration App.
Refer back to the data you gathered during the troubleshooting discovery to see how a solution might be tailored for your company’s apps, data, and flows.
- Example A: Single Integration App, giving priority to order-related flows
- Example B: Multiple Integration Apps borrowing concurrency from a connection in the Integration App with the highest priority data
Example A: Single Integration App, giving priority to order-related flows
First, let’s examine a Shopify – NetSuite Integration App, with the default flows and connections:
Flows | Shopify | NetSuite Connection |
All | Connection S1 Concurrency level: 4 |
Connection N1 Concurrency level: 10 |
The connections are already set to the maximum concurrency allowed in this customer’s accounts.
Suppose that the holiday season is expected to bring 50,000 new orders and 100,000 item updates per day. With 20,000 items listed in Shopify, the increased traffic will invariably slow down the inventory, pricing, and item flows.
One solution is to add connections, as follows, favoring traffic in the order-related flows and especially the heavy payloads in the Shopify imports:
Flows | Shopify | NetSuite Connection |
Order-related:
|
Connection S1 Concurrency level: 4 |
Connection N1 Concurrency level: 8 |
Item-related:
|
Connection S2, to custom app (Dedicated to Inventory import) |
Connection N2 Concurrency level: 2 |
Connection S3, to custom app (Dedicated to other item-related imports) |
Example B: Multiple Integration Apps borrowing concurrency from a connection in the Integration App with the highest priority data
In the next scenario, the integrator.io customer has a total of four Integration Apps running daily, all querying NetSuite frequently:
- Shopify – NetSuite
- Amazon Seller Central – NetSuite
- eBay – NetSuite
- 3PL Central – NetSuite
The NetSuite account allows up to 15 concurrent requests, which are apportioned among the four connections, as follows:
Integration | NetSuite Connection |
Shopify – NetSuite | Connection N1 Concurrency level: 5 |
Amazon Seller Central – NetSuite | Connection N2 Concurrency level: 5 |
eBay – NetSuite | Connection N3 Concurrency level: 3 |
3PL Central – NetSuite | Connection N4 Concurrency level: 2 |
The inefficiency in this configuration may not be apparent at first glance, but it has the effect of limiting the maximum concurrency for any one of the Integration Apps. Let’s assume that Shopify is most active, and the other flows don’t run as often. At no point can the Shopify flows access the full available concurrency; they can have only 5 concurrent requests at a time. The concurrency in the other connections is effectively wasted when not in use.
The simplest solution is to give all the concurrency to one connection and distribute the rest by letting the connections in the remaining Integration Apps borrow from the “main” connection:
Integration | NetSuite Connection |
Shopify – NetSuite | Connection N1 Borrow concurrency from: – Concurrency level: 15 |
Amazon Seller Central – NetSuite | Connection N2 Borrow concurrency from Connection N1 Concurrency level: –* |
eBay – NetSuite | Connection N3 Borrow concurrency from Connection N1 Concurrency level: – |
3PL Central – NetSuite | Connection N4 Borrow concurrency from Connection N1 Concurrency level: – |
* A connection that borrows concurrency from another cannot have its own concurrency level. That setting is disabled.
Then, to give priority to certain flows and distribute concurrency where needed, the customer can add secondary connections for low-priority or low-volume flows or steps. Then, apportion the different levels from the two “pools” by borrowing from the two “main” connections.
Integration | NetSuite Connection | Secondary NetSuite Connections |
Shopify – NetSuite | Connection N1 Borrow concurrency from: – Concurrency level: 10 |
Connection NB1 Borrow concurrency from: – Concurrency level: 5 |
Amazon Seller Central – NetSuite | Connection N2 Borrow concurrency from Connection N1 Concurrency level: – |
Connection NB2 Borrow concurrency from Connection NB1 Concurrency level: – |
eBay – NetSuite | Connection N3 Borrow concurrency from Connection N1 Concurrency level: – |
Connection NB3 Borrow concurrency from Connection NB1 Concurrency level: – |
3PL Central – NetSuite | Connection N4 Borrow concurrency from Connection N1 Concurrency level: – |
Connection NB4 Borrow concurrency from Connection NB1 Concurrency level: – |
Appendix: Governance policies for common apps
Adding new connections can provide higher concurrency – and therefore better throughout when distributed among your flows – only if the endpoint permits it. As seen in the following table, these policies vary according to the vendor, as well as the API account type that you subscribe to. For example,
- Adding more NetSuite, Amazon, or Salesforce connections will not increase the total concurrent requests available to you, because these apps enforce global concurrency limits per account
- Some apps like Shopify allow you to configure custom apps that can increase concurrency per connection, thereby improving throughput
- Other apps limit you to a daily maximum and will return errors only when that limit is exceeded
App | Concurrency type | API architecture | Adding connections increases concurrency? |
NetSuite | Account-level Concurrency limit | NetSuite has total API concurrency limits per account, meaning that regardless of how many connections you create, NetSuite has a strong limit on the number of parallel calls that can be made based upon their Tier and SuiteCloud licenses. | No |
NetSuite notes:
|
|||
Salesforce | Account-level Concurrency limit with per day limits, as well |
Salesforce balances transaction loads by imposing two types of limits:
|
Yes (with minor restrictions) |
Salesforce notes:
|
|||
Shopify | Limits per app, however, users are allowed to create their own custom apps to increase the limits |
REST APIs, with leaky bucket algorithm design (allows a burst call, and then limited API calls per sec). Having more custom apps allows more buckets to be created.
Shopify Plus: The bucket size and leak rate are doubled for Shopify Plus stores:
|
Yes (only for a custom app) |
Shopify notes:
|
|||
Amazon |
Limits per account per API type. Different APIs have different limits. API limits are shared for a region, as well (for ex., all EU accounts for a single seller share the same API limits). |
Leaky bucket. To use Amazon Marketplace Web Service (Amazon MWS) successfully, you should understand throttling: the process of limiting the number of requests you (or your authorized developer) can submit to a given operation in a given amount of time. A request can be added, for ex., when you submit an inventory feed or when you make an order report request. Example: Feed Submit/Amazon import (for Inventory, Pricing, IF, Item, and so on) -> 15 requests | One request every two minutes | 30 requests per hour – Order Export from Amazon – the ListOrders and ListOrdersByNextToken operations together share a maximum request quota of six and a restore rate of one request every minute. |
No |
Amazon notes:
|
|||
BigCommerce |
API calls are metered on a per-store, per-endpoint basis. The total available calls per hour will vary with the business plan. All BigCommerce Integration App API resource endpoints have a rate limit of 3 concurrent requests at a time. |
REST APIs, with leaky bucket algorithm design (allows a burst call, and then limited API calls per sec). Having more connections won’t yield any performance advantage. |
No |
BigCommerce notes:
|
|||
eBay |
Per day API limits are set on the eBay application through which the request is being sent to eBay. Celigo has different eBay apps for different eBay environment (eBay sandbox and eBay production) and different Integration Apps (legacy connectors, staging, production), and each eBay app has its own API limits. Example: The eBay app that we use for the eBay production environment on integrator.io production has a daily quota of 8 million calls per day. Any further calls through this app will be blocked until midnight Pacific time the same day. |
To connect to eBay, you should authorize an eBay application to be able to make API calls on its behalf. Each such application in eBay has its own daily limit. eBay has divided their APIs into different categories based on the functionality that they provide and have also started releasing RESTful APIs in beta and public release for some of the categories. integrator.io uses Trading APIs, which are SOAP-based. OAuth mechanism is used for authentication. |
No, limits at eBay app level and not on a specific account |
eBay notes:
|
|||
Magento 2 |
API rate limits depend on your server configurations, since Magento is open source. |
REST APIs. There are some native Magento features that will allow you to add limits and such, but it's up to the server configuration on how much it can handle. Adding more connections won’t produce higher concurrency. |
No |
Walmart | The API throttling level has been set for each Partner per API. If you try to exceed the limits, your API calls will be returned with an error: 429, “Too Many Requests.” | If you need to send multiple updates to Walmart within a single day, keep the following rules in mind to ensure that all of your updates go through: Only 10 feeds can be sent per hour. Whether you update a single product or 100 products. Each time you click “Export to Walmart” one feed is generated. We highly recommend sending products in batches rather than one by one to avoid reaching the feed limit. Each feed has a limit on how large it can be, depending on the kind of data being sent. We recommend sending updates in batches of around 300, but the official limits as documented cannot be exceeded. See Walmart: Introduction to Marketplace APIs. | No |
Zendesk |
Account-specific number of requests per minute per Zendesk Support account |
Rate limits are in relation to the number of calls you can make against the Zendesk API for our account. This means that if you have 3 users/admins that are making calls across various endpoints, those all count towards the 700 calls per minute rate limit. The Zendesk rate limit will vary based on the endpoint and plan. You can go beyond 2,500 calls per minute based on the plan you take. See Best practices and Zendesk: Endpoint rate limits. | No |
Comments
0 comments
Please sign in to leave a comment.