Hi Traffic Controllers,
I am working on a feature that will allow for pattern-based consistent hashing
in Traffic Router in order to ignore variable parts of a request path, such as
a zip code, during cache selection to increase the likelihood of hashing
similar content requests to the same caches.
For the implementation, I would like to propose adding a delivery service regex
field that would go into the CRConfig, and then be leveraged in Traffic Router
to modify the request path before passing the value to the ConsistentHasher to
select a cache. More specifically, I would like to use regex grouping in order
to extract the desirable parts of a request path and construct the path to be
used for cache selection. Here’s what this would look like:
For the request paths:
/foo/123/bar/index.m3u8
/foo/321/bar/index.m3u8
Provided the regex:
(/.*?)/\d*?(/.*?)(/*.m3u8)
Resulting path to use for cache selection:
/foo/bar/index.m3u8
Due to the potentially risky nature of modifying cache selection, I plan to
include a front-end testing tool for verifying a provided regex against a
provided request path, so that the user knows that the resulting path is what
they expect. If the regex does not match against the request path, the original
request path will be used for cache selection.
Here is a summary of the component changes for my proposed implementation for
the pattern based consistent hashing feature:
-new optional field in the delivery_service table, delivery service form,
crconfig
-TR parsing and leveraging regex field from crconfig; unit tests; API endpoint
for testing tool
-TP testing tool that will take a regex and request path, return the resulting
path to be used for cache selection
Please respond with any questions, comments, or concerns.
Thanks,
Jesse Rivas
