Parallelise the history JSON loads for faster initial load times. #14
Conversation
As a by-product, for my test server using http/2 this halved the load time against the same code using http/1.1.
|
Interesting coincidence: |
|
Hah, @mutability can choose his preferred implementation (or neither)! |
|
This is a nice speedup, thanks! |
|
@mutability it looks like we could do something similar for dbloader.js. Was there a reason for the AJAX queueing system there? If not I'll update that and submit another PR. |
|
I think that was mostly because the db queries are not time critical and flooding out a bunch of requests isn't so great for interactivity since they will preempt the regular data refresh requests |
|
I can see what you mean and have been trying to think of an elegant way to load them in parallel whilst keeping the refresh events top priority. If I come up with something I'll submit a new PR. |
|
@mutability will (are?) this changes be incorporated to https://github.com/mutability/dump1090? Should I close mutability#206 PR? |
…_load Parallelise the history JSON loads for faster initial load times.
Currently the history load code waits for each file to be returned before requesting the next. This modification requests all files at the same time and keeps count of how many are returned. Once they're all back, end_load_history is called as normal. Any files which fail to load are ignored, rather than stopping the load at the point.
Also correct the "applying history" error message to match the counter against the total - previously it finished with "119/120" because the files are numbered from 0.
As a by-product, for my test server using http/2 this halved the load time against the same code using http/1.1 due to the protocol's improvements in parallel resource loads.