In profiling vtquery under load with @mapsam I recall seeing that the JSON response creation runs on the main event loop and takes a non-trivial amount of time to return as a JS object.
Given this fact there are several things we can consider that would speed up the response:
Async json generation in threadpool
We could generate the JSON response async inside the thread pool (so inside Execute() rather than on the main thread like is currently done (
|
void HandleOKCallback() override { |
).
This would require serializing the JSON to a string and then passing the data back from the threadpool in the same way that we pass vector tiles back from the threadpool to the main thread in vtcomposite and vtshaver (as a node.Buffer).
Compressing the JSON response
Now that we're working with a string, we could also gzip compress the JSON string in the threadpool before sending back. This could help speed up the transfer of the data to clients.
In profiling vtquery under load with @mapsam I recall seeing that the JSON response creation runs on the main event loop and takes a non-trivial amount of time to return as a JS object.
Given this fact there are several things we can consider that would speed up the response:
Async json generation in threadpool
We could generate the JSON response async inside the thread pool (so inside Execute() rather than on the main thread like is currently done (
vtquery/src/vtquery.cpp
Line 390 in 96c645b
This would require serializing the JSON to a string and then passing the data back from the threadpool in the same way that we pass vector tiles back from the threadpool to the main thread in vtcomposite and vtshaver (as a node.Buffer).
Compressing the JSON response
Now that we're working with a string, we could also gzip compress the JSON string in the threadpool before sending back. This could help speed up the transfer of the data to clients.