The road to improving Janitor performance

development

#1

This is mostly a spin from IRC on the performance-win opportunities we’ve identified in this GitHub “Project”, but please feel free to add questions, suggestions or general comments below.

17:31:14 <@janx> Janitor does have its performance problems (or “opportunities for improvement”) even though we’ve paid some attention to perf and I’d say we’re among the fastest NodeJS apps out there https://github.com/JanitorTechnology/janitor/projects/3

These items fall into the following categories:

  • We could improve our UX by completing user-requested actions instantly instead of waiting for the back-end to catch up
    • E.g. no need to wait for the Docker server to finish cleaning up every layer to remove a container from the UI!
    • Also the confirmation prompt needs to die)
  • Improve server response times with tricks like:
    • HTTP pre-load (and/or HTTP/2)
    • Better caching (better cache headers + a service worker)
    • Better compression (need to make sure compression is actually even enabled today, and we could add Brotli support because it’s supported everywhere now)
  • Improve app startup-time by 500ms by not loading two useless LetsEncrypt dependencies
  • We could add sensible rate-limits to our Docker containers (which currently have unlimited power, CPU, RAM, disk, etc)
    • And also stop them when they’re not being used
    • But our :warning: biggest Docker problem today is the accumulation of very old containers and images (we need to make containers disappear after some time, e.g. somewhere between a few hours and a few years, in order not to fill our hard drives up so quickly).

Generally these are small things and we’re already super fast, but being even faster would be super cool!