Skip to content

Record the PyAthena 4.2.0 benchmark runs #1310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
laughingman7743 merged 5 commits into from
Oct 19, 2026
Merged

Record the PyAthena 4.2.0 benchmark runs #1310

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
ce8212d
Record the PyAthena 4.2.0 benchmark runs (GH-1288)
laughingman7743 Oct 19, 2026
32a00e2
Say that 4.2.0 is tagged on baee716c, not on the measured commit (GH-…
laughingman7743 Oct 19, 2026
5185fd6
Qualify the read, temporal UNLOAD, and xxlarge Athena time statements…
laughingman7743 Oct 19, 2026
0817517
Scope the 8-worker non-regression heading to 256 MiB and larger (GH-1…
laughingman7743 Oct 19, 2026
dd35736
State the 256 MiB and larger filesystem results against sync, with th…
laughingman7743 Oct 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions benchmarks/RESULTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,18 +18,21 @@ Compare entries only when they used the same instance type, architecture, and sc
| 2026-10-11 | `8a69ce03` | 4.0.0 | `r7g.2xlarge` (arm64), fleet of 12 | Spot | medium, large, xlarge | [2026-10-11-8a69ce03](history/2026-10-11-8a69ce03.md) |
| 2026-10-13 | `437276e1` | 4.1.0 release commit | `r7g.2xlarge` (arm64), fleet of 8 | Spot | medium, large, xlarge | [2026-10-13-437276e1](history/2026-10-13-437276e1.md) |
| 2026-10-13 | `437276e1` | 4.1.0 release commit, filesystem suite | `c8gn.2xlarge` (arm64), one host | Spot | small, medium, large, xlarge (objects) | [2026-10-13-437276e1-filesystem](history/2026-10-13-437276e1-filesystem.md) |
| 2026-10-19 | `9e99caa8` | 4.2.0 (tagged on `baee716c`, which differs only in one test file) | `r7g.2xlarge` (arm64), fleet of 10 | Spot | medium, large, xlarge, xxlarge | [2026-10-19-9e99caa8](history/2026-10-19-9e99caa8.md) |
| 2026-10-19 | `9e99caa8` | 4.2.0 (tagged on `baee716c`, which differs only in one test file), filesystem suite | `c8gn.2xlarge` (arm64), one host | Spot | small, medium, large, xlarge (objects) | [2026-10-19-9e99caa8-filesystem](history/2026-10-19-9e99caa8-filesystem.md) |

## Recommendations

These recommendations come from the runs of `437276e1` on `r7g.2xlarge` and `c8gn.2xlarge` hosts and the 4.0.0 run; the entries give the measured cases and their limits.
These recommendations come from the runs of `9e99caa8` on `r7g.2xlarge` and `c8gn.2xlarge` hosts, and, where a row says so, from the 4.0.0 run; the entries give the measured cases and their limits.

| Need | Use | Measured |
| --- | --- | --- |
| A DataFrame or Table of a large result | `unload=True` with ArrowCursor, PolarsCursor, or PandasCursor | 10 million flat rows in 18.6 to 19.2 seconds through UNLOAD, against 36.0 to 74.4 seconds through CSV; nested rows in 36.4 to 37.9 seconds with ArrowCursor, PolarsCursor, or PandasCursor with pyarrow dtypes, against 229.5 to 306.0 seconds through CSV |
| A pandas DataFrame with nested columns | PandasCursor with `unload=True` and `dtype_backend="pyarrow"` | 10 million nested rows in 37.7 seconds and 5,897 MiB, against 86.8 seconds and 19,664 MiB with the default dtypes |
| Bounded memory | `chunksize` with PandasCursor or PolarsCursor, with CSV or UNLOAD results | 10 million rows at 363 to 904 MiB with 10,000-row chunks, against 3,687 to 19,664 MiB without chunks; larger chunks use more memory |
| Python rows of a large result | ArrowCursor with `unload=True`, or S3FSCursor for constant memory | GetQueryResults paging through Cursor or DictCursor took 226 to 230 seconds for 1 million rows; ArrowCursor with `unload=True` returned 10 million flat rows in 27 seconds in the 4.0.0 run, and S3FSCursor in 329 seconds at 321 MiB |
| `pandas.read_sql_query()` | `awsathena+arrow` with `unload=true`; for bounded memory, `awsathena+polars` or `awsathena+pandas` with `connect_args={"cursor_kwargs": {"unload": True, "chunksize": 100000}}`, which replaces the cursor options of the URL, and `chunksize=100000` in `read_sql_query()` | 1 million flat rows in 7.0 seconds through `awsathena+arrow`, against 230 seconds through the default `awsathena+rest` |
| A Wrangler-like pandas read | PandasCursor | 10 million flat rows in 19.0 seconds through UNLOAD and 74.4 seconds through CSV, against 21.4 and 95.3 seconds for Wrangler |
| A DataFrame or Table of a large result | `unload=True` with ArrowCursor, PolarsCursor, or PandasCursor | 10 million flat rows in 18.2 to 19.8 seconds through UNLOAD, against 55.2 to 84.2 seconds through CSV; nested rows in 33.8 to 36.4 seconds with ArrowCursor, PolarsCursor, or PandasCursor with pyarrow dtypes, against 211.3 to 280.3 seconds through CSV |
| A pandas DataFrame with nested columns | PandasCursor with `unload=True` and `dtype_backend="pyarrow"` | 10 million nested rows in 34.2 seconds and 5,820 MiB, against 88.0 seconds and 19,498 MiB with the default dtypes |
| Bounded memory, including results larger than memory | `chunksize` with PandasCursor or PolarsCursor, with CSV or UNLOAD results | 100 million flat rows, about 29 GB of CSV, at 462 to 1,051 MiB with 100,000-row chunks; 10 million rows at 362 to 917 MiB with 10,000-row chunks, against 3,765 to 19,498 MiB without chunks; larger chunks use more memory |

@laughingman7743 laughingman7743 Oct 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Self-review round 2 (claims, readers, operations). Base 9e99caa84857f8d29abe63435461fc412e040c43, head 32a00e2129f39b8956e91606952dac3d9975ec0e. Result: CLEAN after round one's repair. The PR body's first sentence was corrected in the same way (it said "tagged v4.2.0").

Claims checked against evidence:

Limits: the generated tables were not re-derived row by row. The fork's renderer cross-checked its 4.1.0 reader against all 214 published 4.1.0 case rows, and I spot-checked the sections listed in round one.

| A whole CSV result in PolarsCursor | Polars 2.0, or `chunksize`; with Polars 1.x, the read holds a copy of the result file (#1307) | 10 million flat rows peaked at 7,547 MiB with Polars 2.0.0 and 9,641 MiB with Polars 1.44.2 |
| Python rows of a large result | ArrowCursor with `unload=True`, or S3FSCursor for constant memory | GetQueryResults paging through Cursor or DictCursor took 217 to 225 seconds for 1 million rows; ArrowCursor with `unload=True` returned 10 million flat rows in 27 seconds in the 4.0.0 run, and S3FSCursor in 349 seconds at 323 MiB, and 100 million rows in 3,387 seconds at 327 MiB |
| `pandas.read_sql_query()` | `awsathena+arrow`, `awsathena+polars`, or `awsathena+pandas` with `unload=true`; for bounded memory, `awsathena+polars` or `awsathena+pandas` with `connect_args={"cursor_kwargs": {"unload": True, "chunksize": 100000}}`, which replaces the cursor options of the URL, and `chunksize=100000` in `read_sql_query()` | 1 million flat rows in 6.7 to 7.0 seconds, against 227 seconds through the default `awsathena+rest`; 10 million flat rows in 48.7 to 50.9 seconds, and at 1,032 to 1,054 MiB with chunks through UNLOAD with the pandas and Polars drivers |
| A Wrangler-like pandas read | PandasCursor | 10 million flat rows in 19.8 seconds through UNLOAD and 84.2 seconds through CSV, against 23.4 and 108.9 seconds for Wrangler |
| Asynchronous code | The native asyncio cursors, or the synchronous and ThreadPool APIs offloaded with `asyncio.to_thread()` or an executor; synchronous calls block the event loop while they poll | Single-query timings of the three APIs differed by a median of 1.7% in the 4.0.0 run |
| Parallel S3 writes or copies of large objects with more workers than an event loop's default executor has threads, `min(32, os.cpu_count() + 4)` | `S3FileSystem` | With 40 workers on 8 vCPUs, `AioS3FileSystem` wrote 1 GiB and 6 GiB objects at 0.75 to 0.83 times and copied 6 GiB at 0.30 to 0.35 times its throughput, and read 256 MiB and 1 GiB objects at 0.92 to 1.06 times; 64 MiB and 256 MiB writes ran at 0.90 to 1.12 times (#1159) |
| S3 transfers in asyncio applications | `AioS3FileSystem`; PyAthena keeps `S3FileSystem` registered for fsspec's `s3` and `s3a` protocols, and making `AioS3FileSystem` the default is to be revisited when boto3 supports asyncio natively, because it still runs the blocking boto3 calls in threads | With 40 workers on 8 vCPUs, `AioS3FileSystem` wrote 1 GiB and 6 GiB objects at 0.97 to 1.00 times and copied 6 GiB at 1.01 to 1.05 times the throughput of `S3FileSystem`, and read 1 GiB at 1.00 times; with 8 workers, it copied 6 GiB at 1.36 to 1.49 times (#1159) |
149 changes: 149 additions & 0 deletions benchmarks/history/2026-10-19-9e99caa8-filesystem.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,149 @@
<!--
Copyright 2026 The PyAthena authors

Licensed under the MIT License.
See LICENSE or https://opensource.org/licenses/MIT.

SPDX-License-Identifier: MIT
-->

# S3 filesystem benchmark of PyAthena 4.2.0 on 2026-10-19

This entry records the [filesystem suite](../README.md#filesystem-suite) at commit [`9e99caa8`](https://github.com/pyathena-dev/PyAthena/tree/9e99caa84857f8d29abe63435461fc412e040c43/benchmarks), the commit planned for the PyAthena 4.2.0 release, for #1159.
PyAthena 4.2.0 was tagged on `baee716c`, which differs from `9e99caa8` only in one test file (#1311).
It repeats the selection of the [4.1.0 run](2026-10-13-437276e1-filesystem.md), after #1184 gave the asyncio paths of `AioS3FileSystem` thread pools sized by `max_workers` instead of the event loop's default executor, and #1165 bounded the parts in flight of `S3File` writes.
The cursor run of the same commit is a [separate entry](2026-10-19-9e99caa8.md).

## Environment

| Item | Value |
| --- | --- |
| Commit | `9e99caa84857f8d29abe63435461fc412e040c43`, with a clean checkout |
| Lockfile SHA-256 | `0715fe352738dc098f28c35ed3ff597ac9949387c6aa93595f728ce9f929eac7`, the same as the commit's `uv.lock` |
| Python | 3.12.14 |
| Libraries | boto3 1.43.102, fsspec 2026.9.0 |
| Host | one `c8gn.2xlarge` (arm64, 8 vCPUs, 16 GiB, 25 Gbps baseline network bandwidth), Spot, `us-west-2b`, Amazon Linux 2023 (`ami-0957e38de3db270cc`), kernel 6.18.54 |
| Objects | zero bytes in the stack's scratch bucket in `us-west-2`: 64 MiB (small), 256 MiB (medium), 1 GiB (large), and 6 GiB (xlarge) |
| Block size | 8 MiB for range requests, parts, and copied parts |

## Selection

The suite ran as in the 4.1.0 run: 16 jobs, five repetitions, no warmups.

- **small, medium, large**: reads and writes.
- **xlarge**: writes and copies.

Each operation ran with the sync and aio APIs, `max_workers` 8 and 40, and connection pools (`max_pool_connections`) of 10 and 40.
The sync API calls the filesystem on the trial's thread; the aio API runs reads and writes in `asyncio.to_thread()`, as `AioS3FSCursor` does, so that a file's parallel requests go through `S3AioExecutor` to the file's pool of `max_workers` threads, and awaits the copy coroutine on the trial's event loop, whose part copies run in the filesystem's pool of `max_workers` threads.

## Run record

The queue `fs-1` was published at 07:40 UTC, and its 16 jobs finished on the one host by 08:03 UTC without an interruption; the host then retired itself.
Each of the 64 cases recorded five successful trials and no failure.
The suite does not query Athena; the stack of the [cursor run](2026-10-19-9e99caa8.md) was deployed at the same time and published its queue after this suite had finished.

## Findings

1. **With 40 workers, aio writes and copies ran at the sync throughput** (#1184).
For the 6 GiB object, sync wrote 1,050 to 1,074 MiB/s and aio 1,047 to 1,052 MiB/s (0.98 to 1.00 times sync), against 0.75 to 0.77 times in the 4.1.0 run; for the 1 GiB object, 0.97 to 0.99 times, against 0.81 to 0.83.
Sync copied the 6 GiB object at 1,835 to 1,879 MiB/s and aio at 1,889 to 1,925 MiB/s (1.01 to 1.05 times), against 521 to 540 MiB/s (0.30 to 0.35 times) in the 4.1.0 run.
With the 1 GiB and 6 GiB objects, the aio processes peaked at 52 to 53 threads, against 24 to 25 in the 4.1.0 run and 51 for sync, so their thread counts follow `max_workers`.
2. **For objects of 256 MiB and larger, aio reads and 8-worker writes ran at 0.95 to 1.06 times sync, and 8-worker copies at 1.36 to 1.49 times sync.**
For the 1 GiB object, aio read at 0.96 to 1.06 times sync; with 8 workers, aio wrote at 0.95 to 1.02 times sync from 256 MiB up, and copied at 1.36 to 1.49 times, against 1.33 to 1.46 in the 4.1.0 run.
Against the 4.1.0 run, the aio throughput of these cases rose, except the 8-worker writes of 256 MiB, at 329 and 327 MiB/s against 329 and 346 MiB/s, which ran at 0.95 times sync instead of 1.08 to 1.09.
The 64 MiB transfers ran at 0.74 to 1.29 times sync, without a consistent order among the settings, as in the 4.1.0 run.
The aio reads of the 64 MiB object ran at 230 to 266 MiB/s, against 202 to 312 MiB/s in the 4.1.0 run: slower in three of the four settings, by 17 to 26%, and faster in the fourth; the sync reads ran at 283 to 321 MiB/s, against 215 to 274 MiB/s.
These measurements do not establish a cause.
3. **Writes no longer held the whole object in memory** (#1165).
Writing the 6 GiB object peaked at 690 to 699 MiB with 40 workers and 302 to 305 MiB with 8 workers, with either API, against 6,005 to 6,313 MiB in the 4.1.0 run; the 1 GiB object peaked at 688 to 691 and 302 to 304 MiB, against 1,245 to 1,376 MiB.
4. **Sync transfers of large objects ran faster than in the 4.1.0 run.**
Sync wrote the 6 GiB object at 1,050 to 1,074 MiB/s with 40 workers and 553 to 560 MiB/s with 8 workers, against 861 to 864 and 470 to 487 MiB/s, and copied it with 40 workers at 1,835 to 1,879 MiB/s, against 1,495 to 1,781 MiB/s.
The cause of these differences was not investigated.

For #1159 and #685, the aio paths now match the sync paths for writes and copies, and `S3FileSystem` stays the filesystem that PyAthena registers for fsspec's `s3` and `s3a` protocols.
`AioS3FileSystem` is recommended for asyncio applications, and making it the default is to be revisited when boto3 supports asyncio natively, because `AioS3FileSystem` still runs the blocking boto3 calls in threads.

## Limits

- One host and five trials per case; one `c8gn.2xlarge` host in one Availability Zone.
- The objects hold zero bytes; S3 does not compress them, but other content was not measured.
- Reads of the 6 GiB object did not run, and copies only ran at 6 GiB.
- Comparisons with the 4.1.0 run use the same instance type and selection, but different hosts and days.

## Results

Median throughput is the object size divided by the median transfer time, in MiB per second; threads are the peak thread count of the trial process, and RSS its peak sampled resident memory, including the harness's common imports.

| Scale | Operation | Workers | Pool | sync (MiB/s) | aio (MiB/s) | aio / sync | sync threads | aio threads | sync peak RSS (MiB) | aio peak RSS (MiB) |
| --- | --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| small (64 MiB) | read | 8 | 10 | 295 | 253 | 0.86 | 19 | 21 | 332 | 322 |
| small (64 MiB) | read | 8 | 40 | 321 | 239 | 0.74 | 19 | 21 | 328 | 328 |
| small (64 MiB) | read | 40 | 10 | 308 | 230 | 0.75 | 19 | 21 | 330 | 344 |
| small (64 MiB) | read | 40 | 40 | 283 | 266 | 0.94 | 19 | 21 | 321 | 347 |
| small (64 MiB) | write | 8 | 10 | 131 | 168 | 1.29 | 19 | 21 | 285 | 287 |
| small (64 MiB) | write | 8 | 40 | 171 | 145 | 0.85 | 19 | 21 | 285 | 287 |
| small (64 MiB) | write | 40 | 10 | 162 | 170 | 1.05 | 19 | 21 | 285 | 287 |
| small (64 MiB) | write | 40 | 40 | 170 | 148 | 0.87 | 19 | 21 | 285 | 287 |
| medium (256 MiB) | read | 8 | 10 | 423 | 425 | 1.01 | 19 | 21 | 658 | 650 |
| medium (256 MiB) | read | 8 | 40 | 413 | 414 | 1.00 | 19 | 21 | 655 | 638 |
| medium (256 MiB) | read | 40 | 10 | 512 | 511 | 1.00 | 43 | 45 | 689 | 847 |
| medium (256 MiB) | read | 40 | 40 | 514 | 507 | 0.99 | 43 | 45 | 813 | 764 |
| medium (256 MiB) | write | 8 | 10 | 348 | 329 | 0.95 | 19 | 21 | 301 | 304 |
| medium (256 MiB) | write | 8 | 40 | 343 | 327 | 0.95 | 19 | 21 | 302 | 303 |
| medium (256 MiB) | write | 40 | 10 | 408 | 452 | 1.11 | 43 | 45 | 575 | 577 |
| medium (256 MiB) | write | 40 | 40 | 473 | 452 | 0.96 | 43 | 45 | 575 | 577 |
| large (1 GiB) | read | 8 | 10 | 438 | 465 | 1.06 | 19 | 21 | 2,220 | 2,207 |
| large (1 GiB) | read | 8 | 40 | 468 | 452 | 0.96 | 19 | 21 | 2,182 | 2,184 |
| large (1 GiB) | read | 40 | 10 | 602 | 600 | 1.00 | 51 | 53 | 2,423 | 2,369 |
| large (1 GiB) | read | 40 | 40 | 592 | 592 | 1.00 | 51 | 53 | 2,240 | 2,222 |
| large (1 GiB) | write | 8 | 10 | 496 | 506 | 1.02 | 19 | 21 | 302 | 304 |
| large (1 GiB) | write | 8 | 40 | 512 | 494 | 0.97 | 19 | 21 | 302 | 304 |
| large (1 GiB) | write | 40 | 10 | 831 | 804 | 0.97 | 51 | 53 | 688 | 691 |
| large (1 GiB) | write | 40 | 40 | 823 | 815 | 0.99 | 51 | 53 | 688 | 691 |
| xlarge (6 GiB) | write | 8 | 10 | 553 | 561 | 1.01 | 19 | 21 | 302 | 305 |
| xlarge (6 GiB) | write | 8 | 40 | 560 | 566 | 1.01 | 19 | 21 | 303 | 305 |
| xlarge (6 GiB) | write | 40 | 10 | 1,050 | 1,052 | 1.00 | 51 | 53 | 690 | 699 |
| xlarge (6 GiB) | write | 40 | 40 | 1,074 | 1,047 | 0.98 | 51 | 53 | 690 | 692 |
| xlarge (6 GiB) | copy | 8 | 10 | 285 | 425 | 1.49 | 19 | 20 | 191 | 192 |
| xlarge (6 GiB) | copy | 8 | 40 | 299 | 407 | 1.36 | 19 | 20 | 191 | 192 |
| xlarge (6 GiB) | copy | 40 | 10 | 1,835 | 1,925 | 1.05 | 51 | 52 | 217 | 218 |
| xlarge (6 GiB) | copy | 40 | 40 | 1,879 | 1,889 | 1.01 | 51 | 52 | 217 | 218 |

### Compared with 4.1.0

The same cases in the [4.1.0 run](2026-10-13-437276e1-filesystem.md).

| Scale | Operation | Workers | Pool | sync 4.1.0 (MiB/s) | sync (MiB/s) | aio 4.1.0 (MiB/s) | aio (MiB/s) | aio / sync 4.1.0 | aio / sync | aio threads 4.1.0 | aio threads |
| --- | --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| small (64 MiB) | read | 8 | 10 | 215 | 295 | 304 | 253 | 1.41 | 0.86 | 21 | 21 |
| small (64 MiB) | read | 8 | 40 | 260 | 321 | 309 | 239 | 1.19 | 0.74 | 21 | 21 |
| small (64 MiB) | read | 40 | 10 | 270 | 308 | 312 | 230 | 1.16 | 0.75 | 21 | 21 |
| small (64 MiB) | read | 40 | 40 | 274 | 283 | 202 | 266 | 0.74 | 0.94 | 21 | 21 |
| small (64 MiB) | write | 8 | 10 | 162 | 131 | 175 | 168 | 1.08 | 1.29 | 21 | 21 |
| small (64 MiB) | write | 8 | 40 | 172 | 171 | 167 | 145 | 0.97 | 0.85 | 21 | 21 |
| small (64 MiB) | write | 40 | 10 | 146 | 162 | 163 | 170 | 1.12 | 1.05 | 21 | 21 |
| small (64 MiB) | write | 40 | 40 | 180 | 170 | 162 | 148 | 0.90 | 0.87 | 21 | 21 |
| medium (256 MiB) | read | 8 | 10 | 382 | 423 | 418 | 425 | 1.09 | 1.01 | 22 | 21 |
| medium (256 MiB) | read | 8 | 40 | 359 | 413 | 412 | 414 | 1.15 | 1.00 | 23 | 21 |
| medium (256 MiB) | read | 40 | 10 | 488 | 512 | 457 | 511 | 0.94 | 1.00 | 25 | 45 |
| medium (256 MiB) | read | 40 | 40 | 509 | 514 | 468 | 507 | 0.92 | 0.99 | 25 | 45 |
| medium (256 MiB) | write | 8 | 10 | 302 | 348 | 329 | 329 | 1.09 | 0.95 | 22 | 21 |
| medium (256 MiB) | write | 8 | 40 | 321 | 343 | 346 | 327 | 1.08 | 0.95 | 22 | 21 |
| medium (256 MiB) | write | 40 | 10 | 453 | 408 | 407 | 452 | 0.90 | 1.11 | 25 | 45 |
| medium (256 MiB) | write | 40 | 40 | 448 | 473 | 421 | 452 | 0.94 | 0.96 | 25 | 45 |
| large (1 GiB) | read | 8 | 10 | 432 | 438 | 448 | 465 | 1.04 | 1.06 | 23 | 21 |
| large (1 GiB) | read | 8 | 40 | 453 | 468 | 449 | 452 | 0.99 | 0.96 | 24 | 21 |
| large (1 GiB) | read | 40 | 10 | 550 | 602 | 581 | 600 | 1.06 | 1.00 | 25 | 53 |
| large (1 GiB) | read | 40 | 40 | 565 | 592 | 590 | 592 | 1.04 | 1.00 | 25 | 53 |
| large (1 GiB) | write | 8 | 10 | 448 | 496 | 439 | 506 | 0.98 | 1.02 | 25 | 21 |
| large (1 GiB) | write | 8 | 40 | 423 | 512 | 433 | 494 | 1.03 | 0.97 | 25 | 21 |
| large (1 GiB) | write | 40 | 10 | 718 | 831 | 593 | 804 | 0.83 | 0.97 | 25 | 53 |
| large (1 GiB) | write | 40 | 40 | 712 | 823 | 575 | 815 | 0.81 | 0.99 | 25 | 53 |
| xlarge (6 GiB) | write | 8 | 10 | 470 | 553 | 497 | 561 | 1.06 | 1.01 | 25 | 21 |
| xlarge (6 GiB) | write | 8 | 40 | 487 | 560 | 485 | 566 | 1.00 | 1.01 | 25 | 21 |
| xlarge (6 GiB) | write | 40 | 10 | 861 | 1,050 | 647 | 1,052 | 0.75 | 1.00 | 25 | 53 |
| xlarge (6 GiB) | write | 40 | 40 | 864 | 1,074 | 665 | 1,047 | 0.77 | 0.98 | 25 | 53 |
| xlarge (6 GiB) | copy | 8 | 10 | 267 | 285 | 390 | 425 | 1.46 | 1.49 | 24 | 20 |
| xlarge (6 GiB) | copy | 8 | 40 | 274 | 299 | 366 | 407 | 1.33 | 1.36 | 24 | 20 |
| xlarge (6 GiB) | copy | 40 | 10 | 1,495 | 1,835 | 521 | 1,925 | 0.35 | 1.05 | 24 | 52 |
| xlarge (6 GiB) | copy | 40 | 40 | 1,781 | 1,879 | 540 | 1,889 | 0.30 | 1.01 | 24 | 52 |
Loading
Loading