mirror of
https://git.asonix.dog/asonix/pict-rs
synced 2024-11-01 01:59:58 +00:00
84 lines
4.1 KiB
Markdown
84 lines
4.1 KiB
Markdown
# pict-rs 0.5.8
|
|
|
|
## Overview
|
|
|
|
pict-rs 0.5.8 improves reliability of deletions by allowing background tasks to be retried.
|
|
Otherwise changes are fairly minor.
|
|
|
|
### Changes
|
|
|
|
- [Improved Task Reliability](#improved-task-reliability)
|
|
- [Improved Latency](#improved-latency)
|
|
|
|
|
|
## Upgrade Notes
|
|
|
|
There is a small repo format migration between 0.5.7 and 0.5.8. For sled it's simply opening a new
|
|
tree, for postgre it involves adding a new column to the job_queue table. These changes will
|
|
automatically apply when launching pict-rs 0.5.8. Upgrading should be as simple as pulling a new
|
|
version of pict-rs.
|
|
|
|
|
|
## Configuration Notes
|
|
|
|
Check your configurations to make sure you haven't enabled the tokio-console integration unless
|
|
you're using it. In my local testing, I've found the console subscriber to use a significant amount
|
|
of CPU. While it is very useful for debugging, it shouldn't be used generally in production.
|
|
|
|
The relevant configuration values are `PICTRS__TRACING__CONSOLE__ADDRESS` with environment variables
|
|
or `[tracing.console] address = ""` in the toml.
|
|
|
|
|
|
## Packaging Notes
|
|
|
|
While I have never recommended packaging pict-rs with non-default crate features enabled, and the
|
|
binaries and containers I provide enable only the default features, there are two new crate features
|
|
in this release that I would advise against enabling in downstream packaging environments.
|
|
|
|
The new features are `poll-timer-warnings` and `random-errors`. These are each described below if
|
|
you want to learn about them, but as a general recommendation, do not enable non-default features
|
|
when packaging pict-rs (yes, i'm talking to you `grawlinson` from the AUR).
|
|
|
|
The other optional feature, `io-uring`, is considered less stable. It's possible that folks will
|
|
find it works alright, and maybe Arch can enable it since they can assume recent kernels, but I
|
|
don't personally test much with `io-uring`. It exists mostly as a historical curiosity. Please
|
|
consider carefully before enabling io-uring for pict-rs.
|
|
|
|
|
|
## Descriptions
|
|
|
|
### Improved Task Reliability
|
|
|
|
pict-rs 0.5.8 adds the ability for tasks to be retried. pict-rs generally spawns background tasks to
|
|
handle things like Image deletion or other cleanup operations. Until now, if a background task
|
|
failed, the only indication would be a warning that appeared in the logs. These warnings are
|
|
generally descriptive and help track the error source, but end users aren't notified, and the repo
|
|
or store state can become inconsistant.
|
|
|
|
With the newly added ability to retry tasks, operations should be completed more reliably. By
|
|
default, a failed task will be retried after a 2 minute wait, and if it continues to fail, it will
|
|
be retried up to five times. If a task fails after 5 retries, an additional warning will be output
|
|
to the log.
|
|
|
|
In order to test this, I've added a new optional crate feature called `random-errors`, which will
|
|
inject errors into various pict-rs operations randomly. This feature should never be enabled in
|
|
production scenarios, and two warnings will be printed when launching pict-rs if it was compiled
|
|
with this feature enabled.
|
|
|
|
|
|
### Improved Latency
|
|
|
|
pict-rs 0.5.8 implements a couple new techniques to improve system latency.
|
|
|
|
1. The postgres connection pooling library has been swapped from deadpool to bb8. Not only does this
|
|
(slightly) improve connection pool access times, but it also means pict-rs is no longer pinned
|
|
to an outdated version of deadpool.
|
|
2. Processes like ffmpeg, imagemagick, and exiftool are now spawned from background threads,
|
|
rather than from within the webserver threads. This is notable, since the act of spawning a
|
|
process ends up using a good amount of time, and prevents other requests from being handled
|
|
until the spawning has completed.
|
|
3. pict-rs now has the ability to monitor polling times for futures. By default, any task pict-rs
|
|
spawns itself will be monitored to report polling times, and a trait has been added to enable
|
|
easily tracking more polling times in the future. These polling times will appear in the
|
|
prometheus metrics, as well as in logs at DEBUG or TRACE visibility. There's an optional crate
|
|
feature called `poll-timer-warnings` that will upgrade some of these logs to WARN visibility.
|