Update to Postman

{
  "description": "Use when load-testing or benchmarking an API with concurrent virtual users and latency or error thresholds, or when importing or migrating a JMeter `.jmx` plan or a Gatling simulation (Java/Kotlin/Scala/JS/TS) into a Postman collection plus a `postman performance run` configuration. Reuses a collection to probe a chosen failure mode and distinguishes target limits from load-generator limits. Use for requests such as \"load test this API\", \"import my JMeter plan\", or \"convert my Gatling project to Postman\".",
  "included_files": [
    {
      "relative_path": "references/gatling-import/README.md",
      "size_in_bytes": 12510
    },
    {
      "relative_path": "references/gatling-import/feeders.md",
      "size_in_bytes": 3498
    },
    {
      "relative_path": "references/gatling-import/injection.md",
      "size_in_bytes": 10523
    },
    {
      "relative_path": "references/gatling-import/mapping.md",
      "size_in_bytes": 11150
    },
    {
      "relative_path": "references/gatling-import/unsupported.md",
      "size_in_bytes": 3222
    },
    {
      "relative_path": "references/jmeter-import/README.md",
      "size_in_bytes": 7579
    },
    {
      "relative_path": "references/jmeter-import/import-report.md",
      "size_in_bytes": 1859
    },
    {
      "relative_path": "references/jmeter-import/mapping-table.md",
      "size_in_bytes": 5921
    },
    {
      "relative_path": "references/jmeter-import/postman-perf-capabilities.md",
      "size_in_bytes": 3739
    },
    {
      "relative_path": "references/jmeter-import/script-translation.md",
      "size_in_bytes": 5709
    }
  ],
  "name": "performance-testing",
  "skill_md_contents": "---\nname: performance-testing\ndescription: Use when load-testing or benchmarking an API with concurrent virtual users and latency or error thresholds, or when importing or migrating a JMeter `.jmx` plan or a Gatling simulation (Java/Kotlin/Scala/JS/TS) into a Postman collection plus a `postman performance run` configuration. Reuses a collection to probe a chosen failure mode and distinguishes target limits from load-generator limits. Use for requests such as \"load test this API\", \"import my JMeter plan\", or \"convert my Gatling project to Postman\".\n---\n\n# Performance Testing\n\nA collection supplies realistic request sequences; `postman performance run`\nadds concurrency and a load profile. This makes performance claims repeatable,\nbut only for the workload, data, and network path actually exercised.\nCollections run directly: converting with `postman-to-k6` is not required.\n\n1. Choose the failure mode before the profile: `fixed` tests sustained\n   concurrency, `ramp-up` explores degradation as load grows, `spike` tests\n   sudden surges, and `peak` tests staying near maximum load. Reuse the\n   collection's auth and assertions, and check that its operations and data\n   represent the workload rather than repeating one unusually cheap request.\n2. Establish the target, VU count, duration, and effects of write requests\n   before sending load. Existing user authorization for that scope is enough;\n   resolve missing limits before stressing a shared or production service.\n   Thresholds are evaluated after the run, so a failing gate will not stop\n   traffic early. A small initial run can expose wiring failures before a\n   larger authorized test.\n3. Choose the runner by reachability and capacity. `local` uses this machine\n   or CI runner; its CPU or network can become the bottleneck. `postman-cloud`\n   moves generation to Postman's infrastructure, while\n   `postman-cloud-static-ip` supports targets with IP allowlists. Verify\n   reachability before interpreting connection failures as service capacity.\n4. Set thresholds that represent the user's objective, such as\n   `--pass-if \"less_than(p95, 500)\"`. Supported metrics include `avg`, `p90`,\n   `p95`, `p99`, `error_rate`, and `rps`; latency alone can look good when\n   requests fail quickly. Use `postman performance run -h` for current syntax,\n   units, and runner-specific options.\n5. Isolate test data where concurrent writes would collide. **datasets**\n   supports controlled row distribution across VUs; setup/teardown collections\n   on hosted runners execute once around the test, not once per iteration.\n   `--use-mock` can baseline collection/script overhead, but its numbers\n   cannot establish the real backend's capacity.\n\n## Importing from JMeter\n\nHave a JMeter `.jmx` instead of a collection? Import it by following\n`references/jmeter-import/README.md`, then treat the result as the collection\nabove. Its mapping table carries the JMeter semantics that are easy to get\nwrong, and the import report marks what mapped exactly, what was approximated,\nand which JMeter features have no equivalent here — think-time timers,\nconcurrent thread groups, and non-HTTP (JDBC/FTP/LDAP/Java) samplers are\nreported, never faked.\n\n## Importing from Gatling\n\nHave a Gatling project (a Java/Kotlin/Scala/JS/TS `Simulation`) instead of a\ncollection? Convert it by following `references/gatling-import/README.md`, then\ntreat the result as the collection above. There is no importer to run — you read\nthe source and build the collection, environment, `run.sh` and gap report, using\nthe files next to that README as the algorithm (`mapping.md`, `injection.md`,\n`feeders.md`, `unsupported.md`). The gap report marks what mapped exactly, what\nwas approximated, and what has no equivalent — WebSocket/SSE and other non-HTTP\nsteps, arrival-rate (open-model) injection, think-time pauses, throttling and\nretries are reported, never faked. Open-model injection is converted to VUs via\nLittle's law with the arithmetic shown, not guessed.\n\n## Verification\n\nReport the workload, runner, achieved traffic, latency and error metrics,\nand threshold verdict. Identify generator limits or target errors that prevent\nattributing the result to API capacity. See **api-testing** for functional\nassertions and **ci-integration** when the measured threshold becomes a gate.\n"
}