# SyteLine IDO REST Paging Throughput Calculator

> Source: https://netray.co/tools/syteline-ido-rest-paging-throughput-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate how many REST calls, how much payload and how long a bulk IDO read takes for a given recordcap, and find a page size that avoids timeouts.

## Category

developer

## Erp

Infor SyteLine

## Audience

- Integration developer
- SyteLine developer
- ERP administrator

## Tool

**Kind:** calculator

**Inputs:**

#### Rows to read

**Key:** total_rows

**Type:** number

**Default:** 50000

**Min:** 1

**Step:** 1000

**Unit:** rows

#### recordcap (rows per call)

**Key:** recordcap

**Type:** number

**Default:** 500

**Min:** 1

**Step:** 100

**Unit:** rows

**Help:** Do not use 0 (all rows) for large IDOs. -1 means the default of 200 rows.

#### Properties requested

**Key:** properties

**Type:** number

**Default:** 12

**Min:** 1

**Step:** 1

#### Average bytes per value in the response

**Key:** avg_bytes

**Type:** number

**Default:** 20

**Min:** 1

**Step:** 1

**Unit:** bytes

**Help:** Include JSON property names and quotes, which repeat on every row.

#### Fixed overhead per call

**Key:** rtt_ms

**Type:** number

**Default:** 250

**Min:** 0

**Step:** 10

**Unit:** ms

**Help:** Network round trip plus request handling. Measure with a recordcap of 1.

#### Server cost per row

**Key:** ms_per_row

**Type:** number

**Default:** 0.4

**Min:** 0

**Step:** 0.1

**Unit:** ms

**Help:** Measure: time a large page, subtract the fixed overhead, divide by rows.

#### Parallel streams

**Key:** streams

**Type:** number

**Default:** 1

**Min:** 1

**Max:** 8

**Step:** 1

**Help:** Only with independent, non-overlapping filters per stream.

**Outputs:**

#### Calls (pages)

**Key:** pages

**Expr:** ceil(total_rows / recordcap)

**Format:** integer

#### Seconds per call

**Key:** sec_per_page

**Expr:** (rtt_ms + recordcap * ms_per_row) / 1000

**Format:** decimal

#### Total read time

**Key:** total_minutes

**Expr:** pages * sec_per_page / streams / 60

**Format:** minutes

**Primary:** true

**Description:** Pages times seconds per page, divided across parallel streams.

#### Payload per call

**Key:** payload_kb

**Expr:** recordcap * properties * avg_bytes / 1024

**Format:** decimal

**Description:** KB per response. Large pages raise memory use and timeout risk on the IDO runtime.

#### Total payload

**Key:** total_mb

**Expr:** total_rows * properties * avg_bytes / 1048576

**Format:** decimal

**Description:** MB transferred for the whole read.

#### Effective rows per second

**Key:** rows_per_sec

**Expr:** recordcap / sec_per_page * streams

**Format:** integer

**Chart:**

#### Total minutes and KB per call vs recordcap

**Type:** line

**X:** recordcap

**From:** 100

**To:** 5000

**Steps:** 50

**Series:**

- total_minutes
- payload_kb

**Disclaimer:** A transparent planning model, not an Infor throughput figure. Measure the per-call overhead and per-row cost on your own system with test calls; IDO cost varies widely with custom load methods, calculated properties and filters.

## Content

**Intro:** This calculator plans bulk reads through the SyteLine and CSI Mongoose IDO REST v2 load endpoint, where you page with recordcap, loadtype NEXT and the bookmark from the previous response. Enter your row count and two measured timings to see how many calls you need, how large each response is, and how long the whole read will take.

**Sections:**

#### How the paging works

**Body:** The load call is GET /ido/load/{ido} on the IDO Request Service, with properties, filter, orderby and recordcap in the query string. recordcap sets how many rows one call returns: -1 gives the default of 200, 0 returns every row, any other number returns that many. The response contains Items, a Bookmark, and MoreRowsExist. To read the next page, send the same request with loadtype=NEXT and the bookmark you received; keep going until MoreRowsExist is false. loadtype also accepts FIRST, PREV and LAST. Because the bookmark carries the position in the ordered key, keep the orderby stable between calls, and use the IDO's key properties.

**Bullets:**

- Never use recordcap=0 against a large IDO such as material transactions
- Keep filter, orderby and properties identical across pages
- Request only the properties you need; every one adds payload on every row

#### The model behind the numbers

**Body:** Each call costs a fixed overhead (network round trip, authentication check, IDO session handling) plus a per-row cost on the server. Seconds per page = (overhead ms + recordcap x per-row ms) / 1000. Pages = ceil(rows / recordcap). Total minutes = pages x seconds per page / streams / 60. Payload per page = recordcap x properties x bytes per value / 1024. The rule of thumb that falls out: tiny pages are dominated by the fixed overhead, so time drops quickly as recordcap rises; past a few hundred to a few thousand rows the curve flattens while payload and memory keep growing, and very large pages start to hit IDO runtime or proxy timeouts. Pick the knee of the curve, not the maximum.

**Bullets:**

#### Worked example

**Body:** With the defaults, 50,000 rows at recordcap 500 need 100 calls. Each call takes 0.25 + 500 x 0.0004 = 0.45 seconds, so the read takes about 0.75 minutes on one stream, with about 117 KB per response and 11.4 MB in total. At recordcap 100 the same read needs 500 calls of 0.29 seconds, about 2.4 minutes, because overhead dominates. At recordcap 5,000 it needs 10 calls of 2.25 seconds, about 0.38 minutes, but each response is over 1 MB, which is where timeouts and memory pressure begin on a busy utility server.

**Bullets:**

#### Measuring your inputs and avoiding timeouts

**Body:** Time a call with recordcap=1 a few times and take the median as the fixed overhead. Then time a call with recordcap=1000 and compute (time minus overhead) / 1000 for the per-row cost. IDOs with custom load methods, calculated properties or post-query methods (pqc) can be ten times slower per row than a plain table-backed IDO. A message such as timed out waiting for response from Mongoose usually means a single call is too heavy: reduce recordcap, drop properties, add a selective filter, or split the read into parallel streams by a key range. For a full historical load, a database extract is often the better tool than REST.

**Bullets:**

**Cta:** If you are wiring SyteLine IDOs into an AI assistant or integration on your own servers, we can help design the read pattern and keep it within your system's limits.

**Faq:**

#### What does recordcap do in the Mongoose REST API?

**Answer:** It sets the maximum rows returned by one load call. A value of -1 returns the default 200 rows, 0 returns all rows, and any other value returns up to that many. Combine it with loadtype=NEXT and the returned bookmark to page through larger result sets.

#### How do I get the next page from a SyteLine IDO load?

**Answer:** Read Bookmark and MoreRowsExist from the response. If MoreRowsExist is true, repeat the request with loadtype=NEXT and bookmark set to the returned value, keeping properties, filter and orderby unchanged. Stop when MoreRowsExist is false.

#### Why do I get timed out waiting for response from Mongoose?

**Answer:** The call took longer than the configured timeout, typically because recordcap is too large, the filter is not selective, or the IDO runs expensive custom logic per row. Reduce the page size and properties, filter on indexed key properties, and check the IDO runtime log for the slow method.

#### Should I use parallel calls to speed up a bulk read?

**Answer:** Only with non-overlapping filters, for example by site or key range, and only a few streams. Parallel calls compete for the same IDO runtime and database, so watch server load. Doubling streams roughly halves the elapsed time only while the server has spare capacity.

## Search terms

infor mongoose rest api, syteline ido, infor mongoose api, timed out waiting for response from mongoose, syteline ido rest recordcap, mongoose load collection paging, syteline rest api bookmark

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json