The latency is coming from some old design elements.
- Notify task - This task is used to mark the piece ready for PDP and thus enable the retrievals for it.
- Double upload in classic upload path - we stream the bytes to a temporary upload space and then park it later. This basically means double write. Ideally on a single machine this is copy on same disk so it should be fast but this should still be removed.
Current status
- Next Curio release will have fast harmony scheduler. It should reduce the latency from scheduling notify task. We can test again after release. If the improvement in not there, we get rid of the notify task altogether.
- Once Notify task has been removed, if latency is still significant, we must rework the classic upload API to directly write into the piece store.
Retrieval
Hot latency is 100-200 ms. This is acceptable and cold latency after first upload should ideally come closer to this. Cold latency when retrievable is around 670.2 ms. We can test if there is perf improvment by turning off the mime sniffer. If there is then perhaps, we need to rethink mime sniffer side of things.
The latency is coming from some old design elements.
Current status
Retrieval
Hot latency is 100-200 ms. This is acceptable and cold latency after first upload should ideally come closer to this. Cold latency when retrievable is around 670.2 ms. We can test if there is perf improvment by turning off the mime sniffer. If there is then perhaps, we need to rethink mime sniffer side of things.