| 18 Jun 2026 |
 hexa | zstd should still be plenty fast for very small files | 15:35:44 |
| hexa | https://hydra.nixos.org/build/331667029 | 15:35:59 |
| hexa | 
Download | 15:36:08 |
| hexa | e.g. activate is fairly small | 15:36:18 |
 K900 | But yeah uploads for small outputs look really bad now | 15:36:21 |
| K900 | Significantly worse than before | 15:36:30 |
| hexa | the old queue runner could do unstable-small in 30 minutes with fewest rebuilds | 15:37:13 |
| hexa | Redacted or Malformed Event | 15:37:21 |
| hexa | as a comparison | 15:37:39 |
| K900 | How good is the otel instrumentation currently on the runner/workers? | 15:38:57 |
| K900 | It might be good to spin up a Tempo instance so we can have proper metrics for this | 15:39:17 |
| K900 | Should be fairly easy to do | 15:39:27 |
 Mic92 | You can't really stream zstd with s3 unfortunally because s3 wants to know the size up-front. In niks3 I solved this by having smallish multi-part upload. I just yesterday introduced something similar in queue-runner because before it was just buffering everything in memory. | 15:40:14 |
| Mic92 | But I can try to make the parts a bit smaller. | 15:40:40 |
| hexa | I don't immediately see an option to set up an otel endpoint in the module | 15:46:17 |
| hexa | option('otel', type: 'feature', value: 'disabled', description: 'Enable OpenTelemetry support for Rust components')
| 15:46:50 |
| hexa | does it just eat OTEL_EXPORTER_OTLP_ENDPOINT? | 16:02:55 |
| hexa | Redacted or Malformed Event | 16:03:03 |
| Mic92 | I does but it also needs to be enabled in the package from the looks of things. | 16:07:04 |
| Mic92 | * Itdoes but it also needs to be enabled in the package from the looks of things. | 16:07:11 |
| Mic92 | * It does but it also needs to be enabled in the package from the looks of things. | 16:07:15 |
| hexa | yeah, this meson option | 16:07:27 |
 Arian | In reply to @joerg:thalheim.io
You can't really stream zstd with s3 unfortunally because s3 wants to know the size up-front. In niks3 I solved this by having smallish multi-part upload. I just yesterday introduced something similar in queue-runner because before it was just buffering everything in memory. S3 doesn't require this | 16:14:18 |
| Arian | Or maybe I'm misunderstanding what we mean with size upfront | 16:14:49 |
 Sergei Zimmerman (xokdvium) | I mean, if we want to be able to retry/send the hashsums as x-amz- headers and stuff yeah, it’s kinda necessary to keep the file around.
In nix we that by compressing to an O_TMPFILE fd and seeking in it when we need to retry | 16:17:10 |
| Mic92 | AWS maybe, but there are also other s3 compatible endpoints that require 'Content-Length' headers to be set. | 16:35:12 |
| Arian | Ah wait maybe you're right. NVM | 17:33:43 |
| Arian | Except for multipart uploads but we don't need those for small objects | 17:33:59 |
| Sergei Zimmerman (xokdvium) | In reply to @arianvp:matrix.org
Ah wait maybe you're right. NVM I don’t think we set Content-Length in nix’s s3 client? | 17:35:01 |
| Sergei Zimmerman (xokdvium) | Just for POST, not for PUT | 17:35:37 |
