cwichura wrote:I read through the BTS ticket you referenced about sending only stuff that is needed. I guess I'd like to throw out that there needs to be some cache management if this is added. Otherwise, one will eventually end up with a slave having a ton of cached objects that are no-longer ever going to be referenced. So maybe have a config value for max cache size (with a default of 1GB) and then deleted oldest unreferenced item when space is needed. But now you also need to keep track of the cache items; I dunno if there is an open source library for cache management that would help with this.
cwichura wrote:But I have to admit, it seems like a lot of work for not much gain. Sending files to the slaves on startup has never been an issue for me. The only time where this is slow is if I'm using an EC2 instance for additional slave power. But in that case, it's a spot instance that has just been spun up and so will have no cached objects anyway...
cwichura wrote:Would this also include support for allowing multiple slaves to spin up at the same time, rather than having to wait for each one to start completely before moving to the next like it currently does?
cwichura wrote:I dunno how hard it would be, but perhaps another thing to consider is having lux hold off on any network requests for a bit when its gets a message that the OS was just resumed? Though this becomes less important once the reconnect bug gets fixed.
Users browsing this forum: No registered users and 0 guests