This is based off of the 5-commit branch at
https://github.com/neobooru/szurubooru/blob/docker-development-setup.
Compared to said branch, we
* Exclude extraneous changes such as
* Any formatting
* The use of deprecated/ineffectual top-level `version:` in composer files
* Support controlling $THREADS (modernizing the branch to upstream)
* Integrate into master more cleanly
However, client/docker-start-dev uses a temporary hack -- due to
volume mounting overwriting node_modules at arbitrary points during the
`docker compose build` step, we run `npm i` before any given
`npm run watch`.
To see the effects of this commit in action, run:
docker compose -f ./docker-compose.dev.yml up
This should fix most scaling problems without needing to start
more server instances. By default, waitress maintains at most
4 threads. This works fine if the database is small (sub 100k posts)
but causes a large Task queue depth to occur if the database is larger.
Letting users increase the amount of threads means that one server instance
is able to handle more requests without locking up the rest of the site.
This adds a new environment variable to .env, THREADS, which can be used to
configure the amount of threads to start and is by default set to 4
(the default amount used by waitress).
Furthermore, an update to Pillow has improved the floating-point
precision of the image hash algorithm, requiring minor updates to
the respective unit tests.
See https://github.com/python-pillow/Pillow/pull/4320
