[ 
https://issues.apache.org/jira/browse/TS-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John updated TS-3662:
---------------------
    Attachment: cache_range_requests.diff

Fix an edge case where the origin does not support range requests.  diff file 
does not include the a change needed in configure.ac and 
plugins/experimental/Makefile.am

> 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
>
>         Attachments: cache_range_requests.diff
>
>
> 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)

Reply via email to