Skip to content

Conversation

AEnterprise
Copy link
Contributor

noticed when upgrading koel that it needs to redownload a bunch of images, because they are stored in the container itself. This also bloats it quite a bit. The docker compose files already had a partial solution for it so i expanded it with a proper /cache folder. This also gives koel a central place for future expansions.

I considered moving the search index into it as well, people already have that mapped or data in the volume, and while koel can easily recover and re-download images, the search index going poof really breaks the application and needs manual intervention to rebuild

while updating that i also noticed it was doing 2 apt updates so merged them together

@AEnterprise AEnterprise marked this pull request as draft August 15, 2025 20:50
@AEnterprise
Copy link
Contributor Author

this introduces one small caviat: if you provide your own mount instead of a volume you need to make the folders and permissions yourself as well, not really ideal.

gona see about extending the startup script to make the needed folders (that would run as the executing www-data user) to make the needed folders. could maybe do some other docker housekeeping tasks as well to help with container stability

…p-fpm and larvel deployment optimalizations, and run koel:init and koel:doctor on startup
@AEnterprise
Copy link
Contributor Author

alright i kinda ended up down the rabithole with this one so let me know if this needs splitting into multiple PRs.

and i now this is some big changes but all for major performance and size improvements. the docker image is now now 70% smaller. it also builds a bit faster but this is mainly dependant on internet speed cause it needs to download far less data.

Could use a hand with that final test though, i have no idea why it claims the port isn't being listened to when the curl does succeed

initial page load is 20% faster (in absolute numbers its 0.2s so there is a bit of variance between testing), numbers are bit less consistent with a larger library bit same ballpark. search and view loading seems snappier but harder to measure

Before:
image
image

After:
image
image

A bit of an overview of the changes:

  • swaped out the base image to an alpine image and install some dependencies instead, this is the main reason for the massive image size reduction. there was just so much we don't need in the old base
  • remove some more files from the koel artifact being deployed, most notably is that it contained music files used in testing,
  • use php-fpm for processing php faster
  • the entrypoint script now is responsible for starting apache & php-fpm. it does so as root as they simply don't work otherwise. however their actual workers run under the www-data user, only the management processes are root.
  • add koel-init script that (optionally but default) run koel:init and koel:docker . this makes it far easier to deploy in a docker environment as combined with the env var (and file) it eliminates the need to do manual setup inside the container.
  • tests now don't check on explicit services, but they do check that port 80 (apache) and 9000 (php-fpm) are being listened to. in addition to the test of of the body

some thoughts for future possible improvements:

  • the vendor folder is the largest at over 180MB of data on its own, i'm sure some optimalizations can be made here. most notably here is the aws SDK being 46MB
  • docs folder, do we need it in deployments?
  • ideally i'd like to remove the entire test folder but seems some init stuff relies on it (might need to be moved out?) so i settled for just pruning the music files instead. there might be more that can be removed but i'm not super familar with the structure
  • find a way to leverage php-fpm on the cli so we don't need php as well as php-fpm (would be another easy 10MB)

@AEnterprise AEnterprise marked this pull request as ready for review August 16, 2025 19:10
@AEnterprise
Copy link
Contributor Author

@phanan could you take a look at this maybe? it majorly improves performance.

only issue remaining seems goss seems to be doing something weird and not seeing apache listening on the port at all. but if i run the container myself it works fine and is listening on all port 80, all ports

image

@phanan
Copy link
Member

phanan commented Aug 31, 2025

Thanks for the PR. As you said it yourself, the PR covers quite different points, which makes it harder (for me, near impossible) to review. Please consider splitting them into smaller ones.

@AEnterprise
Copy link
Contributor Author

@phanan i've split most of this up in several MRs but left out the base image changes for now. while this is by far the biggest space saving and optimalization: it builds on top of all th other bigger changes and doing these first should make it a lot more managable to review, and not make it merge conflict hell.

as it stands there might be some minor conflicts between some of the MRs but they are going to be very basic ones to resovle and i can deal with those as things get (hopefully) merged

@phanan
Copy link
Member

phanan commented Aug 31, 2025 via email

@AEnterprise
Copy link
Contributor Author

@phanan i'm done with the PRs for now, these would need to be merged before i can do the rest since it would be full of conflicts otherwise

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants