Hello, Jimmy!
There are some other issues to speed up server start and reduce memory usage to keep larger amount of jobs.

1. On start let server solve constructed jobs while it still reads other jobs. It can read jobs from disk in store folder modification order.
2. Deleted jobs should be stored in some archive at first before a real deletion. This way you reduce the amount of jobs that server keeps in memory. But you can't have a bigger running amount of jobs.
   Archive jobs #240

Even when clearing the job database with jobs, we still have about 10k as a minimum which takes about 10 min to load on cached files.
I've started doing an experiment with replacing the Jsonwrite function to use redis backend and will make some benchmarks to compare the performance. It just uses the filepath as key which makes it a drop in replacement.

Hej @lithorus did you get anywhere with this? We are hitting the same issue. It would be great to be able and offload the done jobs so:

1. they are not all loaded at startup -> faster start -> faster solve cycles -> better responsiveness of afserver
2. they are stored in a database where we can keep them for an extended amount of time, able to restore if needed, able to see all the data it produced.

I had a look at replacing the file based json files with a NOSQL database. This way it would keep the same structure, but wanted to test if it was actually any faster. The next step would be to create a proper database structure, but it will be hard to keep compatibility with current implementation.

I might have just do a hard fork with the database work to test it out. Also, I'm looking into why it's so slow at loading at times. Startup of one of our afanasy servers with 17k jobs took about atleast 1 hour to start.

Also it's worth noting that if you change too many jobs at a time, it will crash with this many jobs, especially if changing priorities on several hundred jobs at a time.