Skip to content

A high number of puzzle-solving in a bundle prolongs the retrieval time of content #16

Description

@bsenel

Puzzle-solving at the client doesn't add significant delay on TTFB as it is likely around 60-70 ms on average. However, in the current implementation, retrieving a file at around 5 MB in size contains four bundles. Each bundle typically holds twelve data chunks. And there are three handling operations for each bundle. Each handling operation includes getting four data chunks, solving the puzzle jumping game, and decrypting the data. So the first three bundles have nine puzzle-solving, and the last bundle has two because it contains seven data chunks instead of twelve. As a result, there are eleven puzzle-solving operations, including data decryption.

From this point on, I give the figures from a measurement in which caches run in Wisconsin. The average retrieval time of a file at around 5 MB in size is approximately 1.8 seconds. Eleven puzzle-solving, including data decryption, costs 660-770 ms on average at a retrieval time of 1800 milliseconds. I think this is an enormous delay. My suggestion is to lower this effect, changing the required data chunk count to access the solution in order to solve the puzzle.

For instance, if we had one handling bundle operation per bundle that contains twelve data chunks, the client could commence puzzle-solving after retrieving the first four chunks. In this way, there would be four puzzle-solving despite eleven so that it would cost 240-280 milliseconds. It is possible to play with these numbers to reach an optimum state.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions