This repository has been archived by the owner on Jan 20, 2025. It is now read-only.
Optimise Transformer PSC #262
Comments
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Transformation is very slow. It takes around 2.03 s/statement (*):
(*): Note that these measurements are from a development environment on a small Elasticsearch instance, not a production Elasticsearch cluster.
I think this has most likely always been the case, although it's possible that things are currently running slower than they used to (I am not sure why, if so). There could be a mixture of reasons for this, including: design, extensive work within Ruby code, Elasticsearch roundtrip, Elasticsearch write-confirmations.
Given our current design and performance characteristics, this means we couldn't cope with even 1 event/s from upstream PSC datasource, and that if the transformation stream falls behind, catching up could take an exceedingly long time.
It's worth spending some time trying to see if there are any simple performance improvements which could be made, here. Anything more complex would likely be too risky or time-consuming to change, but if some small improvements could be found here or there (or perhaps some regression discovered and fixed), even a 0.5 s/event increase in speed would compound to our benefit.
Although this prioritises optimisation of the PSC data transformation pipeline only, any benefits would likely also be applicable to SK and DK pipelines.
This was already known about from bulk data imports, but work on #251 made this more obvious and easier to measure.
The text was updated successfully, but these errors were encountered: