Manual Pagination Loop vs CSV‑Driven Page Tokens: Which Minimizes Memory Footprint?

We need to load a large dataset from an API that exposes pagination via ?page=1&size=50. The test must iterate over all pages until a nextPage token disappears.

Two documented approaches exist in k6: (1) a manual loop that updates the page token or number on each iteration, and (2) a data‑driven method that reads a CSV or JSON file of page tokens and uses open() to drive the test. Neither approach offers built‑in pagination helpers, and both can lead to high memory usage if the payloads are large. Additionally, http.batch() can issue multiple paginated requests in parallel, but it buffers all responses in memory, potentially triggering GC spikes.

Which approach best balances memory consumption and code maintainability, and how does enabling HTTP/2 affect the trade‑off? Specifically:

1. Does using http.batch() for pagination increase memory usage compared to a sequential loop?
2. Is there a recommended pattern for terminating the loop when the nextPage token is missing?
3. What is the impact of HTTP/2 on latency measurements for large paginated responses?