Timeseries create/store is slow.
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 28
- Forks
- 25
- Avg merge
- 4d 22h
- Merged PRs (30d)
- 20
Description
The timeseries create and zstore_ts are slow.
TimeseriesControllerTestIT test_big_create (possibly renamed test_medium_create) used to create an input timeseries with 200k+ points.
We should investigate:
- Did the test formerly pass and how long did it take?
- Can anything be done to speed up the stores?
- Can a pl/sql ut be created that does a bulk store to push the performance test down a layer.
I made the TimeseriesControllerTestIT use a smaller number of points. 12k is currently taking 31s to store. That seems excessive.
The 200k points was something like a 6mb file. So big but not obnoxious. The file with the 12k+ points is 350kb. Seems like we should be able to handle more than that at a time.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with TimeseriesControllerTestIT, including test_big_create and its possible test_medium_create replacement, and compare the current 12k-point timing with the former 200k-point test. Investigate the timeseries create and zstore_ts store paths, and assess whether a PL/SQL bulk-store unit test can measure performance lower in the stack. Done means the bottleneck and a reproducible performance result are documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, sql
- Domain
- api, database, performance, testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100