-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API: change compressed output format for get_val to reduce serialisation cost #327
Comments
OpenCPU supports outputting as feather and parquet, and you can pass arguments to their respective writing functions via the url: https://github.com/opencpu/opencpu/blob/80ea353c14c8601f51ed519744149411d9cc3309/NEWS#L20-L23 |
The albertkanaal request takes just under 4GB to run on it's own:
This is without writing it to rds. |
Feather uses less memory, and is faster, both for reading and writing. But it, in OpenCPU, we can only use it for tabular data (because it passes via However, Writing to local files on the OpenCPU server, fetching the temp key, somehow listing these files, and then fetching them via GET requests over the OpenCPU files API (not documented), example request: Realistically, once we have a URL, I could read it directly with |
Benchmarking feather retreival vs rds: feather is slightly faster and uses way less memory on the client, but also on the service. It does introduce an extra dependency. It's probably a good idea to repeat the test with a truly big dataset. 2014_demerfeather
rds
|
Benchmarking feather retreival vs rds: feather is slightly faster and uses way less memory on the client, but also on the service. It does introduce an extra dependency. It's probably a good idea to repeat the test with a truly 2014_demerfeather
rds
2014_demer, 2010_phd_reubens_sync, 2012_leopoldkanaalfeather
|
Had a child process die while testing the rds version of the query above: get_val_rds <- function(temp_key, api_domain = "https://opencpu.lifewatch.be") {
# request data and open connection
response_connection <- httr::RETRY(
verb = "GET",
url = glue::glue(
"{api_domain}",
"tmp/{temp_key}/R/.val/rds",
.sep = "/"
),
times = 5
) %>%
httr::content(as = "raw") %>%
rawConnection()
# read connection
api_response <- response_connection %>%
gzcon() %>%
readRDS()
# close connection
close(response_connection)
# Return OpenCPU return object
return(api_response)
} error:
I was able to get it to run after restarting, but there does seem to be instability. I can't exclude that this instability exists in the feather version, it might be just a coincidence it happened during rds testing. |
Tried Google protoBuff as implemented in As explained in the arrow FAQ: https://arrow.apache.org/faq/#how-does-arrow-relate-to-protobuf, protobuff is less suitable for large file transfers. I also noticed it filling my swap file, and crashing on large dataset transfers. I feel this avenue is not worth it. I'll stick to Apache Arrow |
Currently the
get_val()
helper supports fetching from OpenCPU as JSON or RDS.In #323 , Stijn found that we are crashing the session by running out of memory, possibly on a serialisation process. I believe
base::writeRDS()
->base::serialize()
might be the cause of this memory usage. Assuming the crash happens on the writing of the object as RDS to the output stream. I've not been able to replicate this issue locally or on the RStudio Server.There are a few open issues on opencpu for child processes that died:
I did a quick local test on a deployments table to see if outputting as feather or parquet might help:
It looks like both are faster on my system, I have not benchmarked memory usage yet.
This is using lz4 compression for feather, snappy for parquet and gzip for rds.
Stijn proposes using an alternative fetch method; returning the session id and writing out paged result objects to the session dir, then having the client fetch these objects and serializing on the client. This ties in to an existing paging branch, but Stijn mentioned this will probably require some optimisation on the database so we have a nice column to sort on.
to benchmark:
Blockers / Action Points
Install
arrow
on Lifewatch RStudiogcc
>7 currently 5.4.0Implement query paging on
etnservice
Optional:
etnservice
The text was updated successfully, but these errors were encountered: