[
https://issues.apache.org/jira/browse/TS-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577722#comment-14577722
]
John commented on TS-3662:
--------------------------
I took care of an edge case where the origin does not service range requests
and instead sends the entire object with a 200 response. In this case, the
plugin allows the response through to the client with the 200 response but
disables cache writing so that multiple copies of the object are not cached
with different cache keys.
> Caching range requests plugin.
> ------------------------------
>
> Key: TS-3662
> URL: https://issues.apache.org/jira/browse/TS-3662
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
> Reporter: John
> Assignee: John
> Fix For: 6.0.0
>
>
> We are using ATS to cache very large binary files 60gb + for a customer. The
> customers user client software is used to fetch these files using HTTP range
> requests in a predictable manner ie, all clients request the same byte
> ranges. In any event, if we were to cache the large 60gb file obtained from
> the origin, the ATS would save it to a single stripe or disk drive using the
> background fetch plugin. When we tried this method, we discovered that the
> thousands of range requests to a single disk drive caused a significant
> performance issue, high I/O wait and load average on the host running ATS.
> The plugin I have written, see the attached patch, transforms the range
> requests at various points in the HTTP flow so that the ATS may cache the
> range requests as individual objects by modifying the the request URL,
> removing and restoring the range request headers where appropriate. This
> allows the individual range requests to be stored and retrieved as individual
> objects that are spread over multiple disk drives. See the source as it is
> well commented.
> We have this plugin in production within our CDN and have seen a dramatic
> improvement for delivery of our customers files using range requests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
