h0bb3
commented
5 months ago done some initial tests here and it is actually quite interesting.
100 sequential calls to an API endpoint will take approximately 100 seconds as we process one API call message per second. Result was 99.14073038101196 - Think the less than 100 depends on luck, i.e. when you get the first message.
This was tested with the hello endpoint on a local network - so really minimal overhead.
However, the story is different considering parallel requests. Then basically all requests will be done at the same time as the threads are blocked when the request is done (waiting for their 1 second slot in the queue). This means a number of sockets opened at the same time and a big queue of requests. Threads will start to time out and also be abruptly disconnected. I guess there is some logic for this in the underlying layers.
The server logs look pretty fine and the server itself ticks along nicely - this was basically the desired behavior. API requests should not disturb harvesting and definitely not future control signals.
The problem is then of course for clients eg the ble-service and others - they cannot expect timely responses and an mechanisms to remedy this should be put in place. I.e. allowing for ample timeouts and retrying after sleeping.
It would also be interesting to test more intricate scenarios like reading from the inverter and see if this hinders harvesting, etc.
Threading could be used to a greater extent.. but then we lose control over when things are executed - but maybe that is worth it...
We could do some automated stress/performance testing of the REST API and possibly also the BLE service.
This could possibly be further developed to checking if harvests are missed/delayed during API stress.