|
| 1 | +# Performance > Parallel workloads in Node.js |
| 2 | + |
| 3 | +Other sections such as bundle sizing, dependency count, and dynamic imports |
| 4 | +cover aspects of performance related to the initial startup of your application. |
| 5 | + |
| 6 | +This section focuses on post-startup performance of request throughput. Specifically, |
| 7 | +we cover performance configuration of the AWS SDK for JavaScript (v3) |
| 8 | +in Node.js using HTTP/1.1 and the `node:https` module via the SDK's requestHandler |
| 9 | +dependency, `@smithy/node-http-handler`. |
| 10 | + |
| 11 | +## What is a parallel workload? |
| 12 | + |
| 13 | +A parallel workload is any time you make more than one request |
| 14 | +before the first request has completed. |
| 15 | + |
| 16 | +In single-threaded JavaScript, this is accomplished via the asynchronicity of `Promise`s. |
| 17 | + |
| 18 | +## Configuration options related to throughput |
| 19 | + |
| 20 | +Here is an example containing SDK Client configuration options that have |
| 21 | +an effect on request throughput. |
| 22 | + |
| 23 | +```ts |
| 24 | +// example: configuring an SDK client for throughput. |
| 25 | +import { S3 } from "@aws-sdk/client-s3"; |
| 26 | +import { NodeHttpHandler } from "@smithy/node-http-handler"; |
| 27 | +import { Agent } from "node:https"; |
| 28 | + |
| 29 | +const s3 = new S3({ |
| 30 | + /** |
| 31 | + * Default is false. Setting this to true caches |
| 32 | + * middleware resolution and prevents modifications |
| 33 | + * to the middlewareStack from taking effect. |
| 34 | + * |
| 35 | + * Use only if you are not adding custom middleware. |
| 36 | + */ |
| 37 | + cacheMiddleware: true, |
| 38 | + requestHandler: new NodeHttpHandler({ |
| 39 | + httpsAgent: new Agent({ |
| 40 | + /** |
| 41 | + * Default is true. This should be left as true |
| 42 | + * generally speaking, unless you have very specific |
| 43 | + * use-case needing the alternative. |
| 44 | + */ |
| 45 | + keepAlive: true, |
| 46 | + /** |
| 47 | + * See expanded note below about sockets. |
| 48 | + * You should use a number that is the size |
| 49 | + * of your parallel workload batch. |
| 50 | + */ |
| 51 | + maxSockets: 50, |
| 52 | + }), |
| 53 | + }), |
| 54 | +}); |
| 55 | + |
| 56 | +// shorthand syntax available since v3.521.0 |
| 57 | +const client = new S3({ |
| 58 | + requestHandler: { |
| 59 | + requestTimeout: 3_000, |
| 60 | + httpsAgent: { maxSockets: 50 }, |
| 61 | + }, |
| 62 | +}); |
| 63 | +``` |
| 64 | + |
| 65 | +## Client instances |
| 66 | + |
| 67 | +In this SDK, much functionality is cached for performance reasons, but |
| 68 | +the cache is usually associated with the client instance. In particular, |
| 69 | +the following are cached on the client instance: |
| 70 | + |
| 71 | +- credentials fetched by async function calls |
| 72 | + - if your client is configured to source credentials from a provider that includes |
| 73 | + a network request and/or file-system read, this work is done once per client until |
| 74 | + expiration of the credentials. If you instantiate a new client for every request, |
| 75 | + this will slow things down substantially. |
| 76 | +- middleware function stack when `cacheMiddleware=true` |
| 77 | +- `node:https` Agent and its socket pool |
| 78 | + |
| 79 | +If you do need multiple instances of an SDK client, but don't want to |
| 80 | +have separate credentials and socket pools, you can share |
| 81 | +credentials and requestHandlers between clients. |
| 82 | + |
| 83 | +```ts |
| 84 | +// example: credential and socket pool sharing from primary client. |
| 85 | +import { S3 } from "@aws-sdk/client-s3"; |
| 86 | + |
| 87 | +const s3_east = new S3({ region: "us-east-1" }); |
| 88 | + |
| 89 | +const { credentials, requestHandler } = s3_east.config; |
| 90 | + |
| 91 | +const s3_west = new S3({ |
| 92 | + region: "us-west-2", |
| 93 | + credentials, |
| 94 | + requestHandler, |
| 95 | +}); |
| 96 | +``` |
| 97 | + |
| 98 | +```ts |
| 99 | +// example: credential and socket pool sharing from user instantiated objects. |
| 100 | +import { S3 } from "@aws-sdk/client-s3"; |
| 101 | +import { fromNodeProviderChain } from "@aws-sdk/credential-providers"; |
| 102 | +import { NodeHttpHandler } from "@smithy/node-http-handler"; |
| 103 | + |
| 104 | +const credentials = fromNodeProviderChain(); |
| 105 | +const requestHandler = new NodeHttpHandler({ |
| 106 | + httpsAgent: { |
| 107 | + maxSockets: 100, |
| 108 | + }, |
| 109 | +}); |
| 110 | + |
| 111 | +const s3_east = new S3({ region: "us-east-1", credentials, requestHandler }); |
| 112 | +const s3_west = new S3({ region: "us-west-2", credentials, requestHandler }); |
| 113 | +``` |
| 114 | + |
| 115 | +## Node.js Sockets |
| 116 | + |
| 117 | +The `node:https` Agent class manages sockets on your behalf. The most impactful configuration you can make for parallel workloads is to set |
| 118 | +the value of `maxSockets`. |
| 119 | + |
| 120 | +Configuring the `maxSockets` value for the SDK's requestHandler should |
| 121 | +be based on the parallelism or parallel workload batch size of your application |
| 122 | +and usage scenario. |
| 123 | + |
| 124 | +- Configuring too few sockets leads to a slowdown as this is equivalent to |
| 125 | + setting a lower cap on the parallel workload batch size. |
| 126 | +- Configuring too many sockets can _also_ slow down your application. This is |
| 127 | + because the application may open a new socket, which takes some CPU time, when |
| 128 | + an existing socket was about to become free for reuse. |
| 129 | + - configuring too many sockets can cause you to hit the file descriptor limit of the |
| 130 | + operating system. This can manifest as `Error: EMFILE, too many open files` |
| 131 | + in Node.js. |
| 132 | + |
| 133 | +## Example Scenario |
| 134 | + |
| 135 | +You have 10,000 files to upload to S3. |
| 136 | + |
| 137 | +- Uploading one at a time is too slow. |
| 138 | +- Uploading all at once risks crashing your application process, or |
| 139 | + being throttled by the server. |
| 140 | + |
| 141 | +#### Recommendataion |
| 142 | + |
| 143 | +Test your application to determine the right level of parallel request traffic. |
| 144 | +After that, configure the `maxSockets` value to be equal to the batch size, or |
| 145 | +a factor of it. |
| 146 | + |
| 147 | +```ts |
| 148 | +// example: workload of 10,000 files, batch size of 100. |
| 149 | +import { S3 } from "@aws-sdk/client-s3"; |
| 150 | + |
| 151 | +const files = [ |
| 152 | + /*... */ |
| 153 | +]; |
| 154 | +const BATCH_SIZE = 100; |
| 155 | + |
| 156 | +const s3 = new S3({ |
| 157 | + requestHandler: { |
| 158 | + httpsAgent: { maxSockets: 100 }, |
| 159 | + }, |
| 160 | +}); |
| 161 | + |
| 162 | +const promises = []; |
| 163 | +while (files.length) { |
| 164 | + promises.push( |
| 165 | + ...files.slice(0, BATCH_SIZE).map((file) => { |
| 166 | + return s3.putObject({ |
| 167 | + Bucket: "...", |
| 168 | + Key: file.name, |
| 169 | + Body: file.contents, |
| 170 | + }); |
| 171 | + }) |
| 172 | + ); |
| 173 | + await Promise.all(promises); |
| 174 | + promises.length = 0; |
| 175 | +} |
| 176 | +``` |
| 177 | + |
| 178 | +In this example we've adhered to the best practices mentioned in this section: |
| 179 | + |
| 180 | +- use one client instance for repeated requests |
| 181 | +- set a `maxSockets` value that is a factor of the batch size |
0 commit comments