Closed shish closed 2 years ago
Man you are motoring on this.
I think I want to swoop in and do some thinking about this before this is merged.
the get_json
has a @cache
decorator and will never expire.
https://github.com/calaldees/KaraKara/blob/c73d231304f88fe15c10c1e7d95785fdea762976/api_queue/api_queue/queue.py#L42
More tests would/should reveal this.
I'm unsure how to deal with settings ... if we have to load the settings from disk every single request, that's pretty heavy .... but with 4 simultaneous async threads, I don't know how to share data effectively and expunge cache over a number of workers.
I was differing how to handle this until later. My hope was not to implement this for the next event.
Do we need to update the settings from the client for the upcoming event? My plan was to just hard code settings for this event and restart the server when we want new settings.
Mostly all the client code assumes settings are going to be live-updated via mqtt - and adding live-updating settings to the server is easier than adding hard-coded settings to the client :P
if we have to load the settings from disk every single request, that's pretty heavy
Is it? I just benchmarked it and found that it adds 0.0000195 seconds per request... I mean yeah, that's 10x slower than doing a cache lookup... but I think we can live with an extra picosecond if it gives us a useful feature and makes the code simpler :D
I think we can live with an extra picosecond You're talking sense. That's why you get paid the big bucks!
I want to change the queue settings o.o