For objects which do not have more than one version (alternate, e.g. Vary header) and where the header and body fit into a single fragment only a single seek is required.
This is the case for many smaller objects, e.g. images. On Tue, Jun 6, 2017 at 8:34 AM, Alan Carroll < solidwallofc...@yahoo-inc.com.invalid> wrote: > No, 2 disk operations are still required in general because there is other > meta data (such as the response header) that is needed. > > > > On Monday, June 5, 2017, 8:52:03 PM CDT, Anh Le Duc (2) <anh...@vng.com.vn> > wrote: > > If an object are split into multiple fragments and fragments may not be > adjacent to each other, there's are at least 2 I/O ATS uses when serving > range requests: > > + One to read meta data about the object (for example: the fragment tables) > > + One for fetching requested data > > If we can get rid of fragment tables by: > + Define a fixed fragment size for each cache span (or volume, stripe) > + Have adaptive routing policies to route objects to appropriate spans > (based on their sizes) > > Then we only need 1 I/O to serve range requests, right? > > On Mon, Jun 5, 2017 at 9:57 PM, Alan Carroll < > solidwallofc...@yahoo-inc.com.invalid> wrote: > > > In practice the fragments are not all the same size. The sizing logic is > a > > bit sloppy because it was not considered important at the time to get the > > fragments consistently sized (why does it matter if all fragments will be > > read on a cache hit?). When I put in the range acceleration I didn't want > > to deal with that change as well. With the POC update the fragment table > is > > still needed, even though the fragments for an object are consistent > sized, > > to hold state information about the fragments. > > > > > > On Sunday, June 4, 2017, 11:24:52 PM CDT, Anh Le Duc (2) < > > anh...@vng.com.vn> wrote: > > > > > > @Alan: I saw your answer for my issue #2023 > > <https://github.com/apache/trafficserver/issues/2023>. To handle range > > requests, we must efficiently know which fragments to read. By using > > fragment tables, we can achieve that purpose. > > > > For example: if we serve a range request of bytes 1000-2000, with > fragment > > tables, we know the Nth fragment (from the current one) containing > > requested data. By continuously applying hash functions on the request's > > key N times, we may effectively locate the fragment. > > > > My question is: if we split a specific object into multiple fragments > > having the same size, are fragment tables useless? Because we can quickly > > have: > > > > 1000/fragmentSize <= N = 2000 / fragmentSize > > > > > > > > > -- > > *Anh Le (Mr.)* > > *Senior Software Engineer* > > *Zalo Technical Dept., Zalo Group, **VNG Corporation* > > 5th floor, D29 Building, Pham Van Bach Street, Hanoi, Vietnam > > *M:* (+84) 987 816 461 > > *E:* anh...@vng.com.vn > > *W: *www.vng.com.vn > <http://www.google.com/url?q=http%3A%2F%2Fwww.vng.com.vn&; > sa=D&sntz=1&usg=AFQjCNHYo7I_1mPESzfIvCNjLtAJOq8xsg> > > *“Make the Internet change Vietnamese lives”* >
