My project to test Holster started hitting 100% CPU the other day during peak processing times, so have been doing some investigation. It's not a big server, but Holster shouldn't need the resources it was using and this was a great opportunity to identify what needed improving.
This has led to a few performance improvement releases this week. The first was that the caching radisk was doing was only for the most recent file. This doesn't do very much when keys come in randomly for different files, and each key caches a new file. Holster is currently not designed to hold heaps of data, so it now just caches all files, which was a big improvement as reading from disk is expensive.
Next was improving the client throttling to use an actual processing queue. It previously tried to throttle with timeouts but this just caused messages to build up later. The advantage of a processing queue is that you can also return an error if the queue gets too long, because there is probably something wrong with your Holster queries if this happens (ie requesting too much data.)
Lastly the Holster website got an update! It now has a nice little visualization of connected clients.
Claude
I'm honestly surprised to be saying this but I've been working on Holster recently using claude.ai. I've thrown away a bunch of attempts, but have recently found a way to develop using small incremental improvements.
This means I've managed to get through the TODO list I had written up. The first task was limiting graph size which was done in 1.0.8. The other tasks were to do with wire performance, which I thought would take much longer. Browsers now store data based on what they've requested previously, either via get or put. Messages are still always passed through the network so that synchronisation is possible.
The other wire performance required is that I noticed when a browser hadn't connected for a while that it would pull data as quickly as possible. If it has a lot to catch up on then this overloads both the browser and server. There is now some nice throttling added in 1.0.9 that means browsers will sync eventually but the server is not overloaded.
Performance Improvements
This has led to a few performance improvement releases this week. The first was that the caching radisk was doing was only for the most recent file. This doesn't do very much when keys come in randomly for different files, and each key caches a new file. Holster is currently not designed to hold heaps of data, so it now just caches all files, which was a big improvement as reading from disk is expensive.
Next was improving the client throttling to use an actual processing queue. It previously tried to throttle with timeouts but this just caused messages to build up later. The advantage of a processing queue is that you can also return an error if the queue gets too long, because there is probably something wrong with your Holster queries if this happens (ie requesting too much data.)
Lastly the Holster website got an update! It now has a nice little visualization of connected clients.
Claude
This means I've managed to get through the
TODOlist I had written up. The first task was limiting graph size which was done in 1.0.8. The other tasks were to do with wire performance, which I thought would take much longer. Browsers now store data based on what they've requested previously, either viagetorput. Messages are still always passed through the network so that synchronisation is possible.The other wire performance required is that I noticed when a browser hadn't connected for a while that it would pull data as quickly as possible. If it has a lot to catch up on then this overloads both the browser and server. There is now some nice throttling added in 1.0.9 that means browsers will sync eventually but the server is not overloaded.