| 23 Aug 2023 |
 raitobezarius | yeah | 12:05:07 |
 @linus:schreibt.jetzt | it does pool them | 12:05:08 |
| @linus:schreibt.jetzt | Aug 23 13:58:54 garage-muc atticd[286]: 2023-08-23T11:58:54.590061Z ERROR tower_http::trace::on_failure: response failed classification=Status code: 500 Internal Server Error latency=30003 ms
Aug 23 14:02:44 garage-muc atticd[286]: 2023-08-23T12:02:44.976132Z ERROR attic_server::error: Database error: Failed to acquire connection from pool
| 12:05:45 |
| raitobezarius | how many connections do you allow now? | 12:06:02 |
| @linus:schreibt.jetzt | I have no idea :D | 12:06:08 |
| @linus:schreibt.jetzt | maybe I should just dig into it rather than putting every intermediate thought in here :p | 12:06:39 |
| raitobezarius | max_connections is the right knob | 12:06:51 |
| @linus:schreibt.jetzt | I don't think this is on the postgres side, it's on the attic side | 12:07:15 |
| raitobezarius | Ah right I agree | 12:07:27 |
| raitobezarius | https://github.com/NixOS/nixos-org-configurations/tree/master/metrics/fastly | 13:19:45 |
| raitobezarius | We kinda have weak popcount | 13:20:49 |
| 24 Aug 2023 |
 Mic92 | I actually wonder if attic is not massively increasing the s3 costs over just downloading nars because it splits up nars into smaller files that can be deduplicated. You pay also per request and not just for the bandwidth. | 06:53:29 |
| Mic92 | I also noticed when using local storage it will put all objects in one directory. This might scale badly for large number of files. It's better to create subdirectories based on the filename prefix. | 06:55:28 |
 @andreas.schraegle:helsinki-systems.de | In reply to @joerg:thalheim.io
I actually wonder if attic is not massively increasing the s3 costs over just downloading nars because it splits up nars into smaller files that can be deduplicated. You pay also per request and not just for the bandwidth. that depends on your s3 provider | 08:10:33 |
| raitobezarius | In reply to @joerg:thalheim.io
I actually wonder if attic is not massively increasing the s3 costs over just downloading nars because it splits up nars into smaller files that can be deduplicated. You pay also per request and not just for the bandwidth. we can run simulations against AWS S3 | 08:57:53 |
| raitobezarius | I am running attic seriously yet so I don't know how easy this is | 08:58:03 |
| raitobezarius | * I am not running attic seriously yet so I don't know how easy this is | 08:58:06 |
 flokli | This stuff heavily depends on how good your caching in front of this is | 10:12:16 |
| flokli | Of course, if we don't cache and always reach out to S3 to always assemble stuff it'll be more requests, no surprise | 10:12:40 |
| flokli | But if you can keep the hot NARs in fastly or whatever caching layer we use, hopes are the less frequent, but much nicer deduped NAR contents will outweigh the > number of requests you need to reassemble less hot paths, if you need to. | 10:13:37 |
| flokli | I'd probably even go with our own caching layer in between, so we have a bit more control over it. | 10:13:57 |
| @linus:schreibt.jetzt | You can also reduce the amount of requests (but also the space savings) by adjusting the chunking parameters | 10:13:58 |
| @linus:schreibt.jetzt | and wouldn't it make more sense to cache chunks than assembled nars? | 10:14:29 |
| flokli | It depends on how smart your edge is | 10:14:47 |
| flokli | if your NAR-assembling thing is running at the edge, caching the chunks before assembly, rather than the assembled NARs might work. | 10:15:18 |
| flokli | But there's usually some limits on how many requests a single request can generate (looking at you, cloudflare) | 10:15:36 |
| flokli | so YMMV | 10:15:41 |
| @linus:schreibt.jetzt | oh right, yeah, if it's just a CDN without extra smarts that makes sense | 10:15:56 |
| @linus:schreibt.jetzt | but depending on how costly requests are, it could make sense to have caching both behind and in front of the assembly bit | 10:16:28 |
| flokli | I still think you should optimize for disk storage on S3 / $backingStore, so small chunk sizes, because everything in the front is cache-able. | 10:16:33 |
