Mailing-List: contact dev-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@trafficserver.apache.org
MIME-Version: 1.0
In-Reply-To: <1712764968.390066.1496410199175@mail.yahoo.com>
References: <CA+cOPRiNeHRams8SddNpoJMR6-shzGcLgZy_zDuAM-2yVwisPg@mail.gmail.com>
 <1976302073.4177723.1496235304074@mail.yahoo.com> <CA+cOPRghXFr2LYmcRAtqHEu+Qye6zr3dtFSs8Unvos2J4mp+zQ@mail.gmail.com>
 <1377142285.293088.1496283816785@mail.yahoo.com> <CA+cOPRjQ1YOA+JPci34tKBg2Pde+wmUS=Hku5w7gYipa5ZHe2Q@mail.gmail.com>
 <1203885926.220357.1496321191545@mail.yahoo.com> <CACgLx2opjX_dM2aGx5W05QFk4mqi+d6F66w9Xzb4Yafkh=RBpg@mail.gmail.com>
 <CA+cOPRhYJOgaqsOQ+AN3W8OgWFF1J7Yz2=tLm=Xom=WH=Bo=Jw@mail.gmail.com> <1712764968.390066.1496410199175@mail.yahoo.com>
From: "Anh Le Duc (2)" <anhld2@vng.com.vn>
Date: Mon, 5 Jun 2017 11:24:41 +0700
Message-ID: <CA+cOPRgdzUeABA3Y-jHTKm+_N0WxN0Ho7L_dZ8-QhJRdtPtXAg@mail.gmail.com>
Subject: Re: Question about ATS garbage collector
To: dev@trafficserver.apache.org
Content-Type: multipart/alternative; boundary="f403045e4188ceb59205512ee1e0"
archived-at: Mon, 05 Jun 2017 04:24:50 -0000

--f403045e4188ceb59205512ee1e0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@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 <=3D N =3D 2000 / fragmentSize


On Fri, Jun 2, 2017 at 8:29 PM, Alan Carroll <
solidwallofcode@yahoo-inc.com.invalid> wrote:

> Correct. For a specific fragment, the size is adjusted to be approximatel=
y
> the size of the content in the fragment. When we talk of "fragment size" =
we
> generally mean the maximum allowed size.
>
>
>
> On Thursday, June 1, 2017, 8:39:00 PM CDT, Anh Le Duc (2) <
> anhld2@vng.com.vn> wrote:
>
> @Alan: Fragment sizes are not fixed, right? By the formula in section
> Stripe
> Directory
> <https://docs.trafficserver.apache.org/en/latest/developer-guide/cache-
> architecture/architecture.en.html#stripe-directory>,
> we have adaptive sizes
>
> ( *size* + 1 ) * 2 ^ ( CACHE_BLOCK_SHIFT + 3 * *big* )
>
>
> On Fri, Jun 2, 2017 at 2:05 AM, John Plevyak <jplevyak@acm.org> wrote:
>
> > While large objects are not stored contiguously, the chunk size is
> > configurable (as Alan pointed out).
> > Increasing the chunk size increases memory usage and decreases the numb=
er
> > of seeks required to
> > read an object.  It does not decease the number of seeks required to
> write
> > the object because
> > we use a write buffer which is separately sized for write aggregation.
> >
> > The default chunk size is set such that for spinning media (HDDs) the
> > amount of time spent reading
> > the object is dominated by transfer time, meaning that total disk time
> will
> > decrease by only
> > a small amount if the chunk size is increased.  Indeed for SSDs, the
> chunk
> > size can be
> > decreased to free up more memory for the RAM cache and to decrease the
> > number of
> > different block sizes.
> >
> > On Thu, Jun 1, 2017 at 5:46 AM, Alan Carroll <
> > solidwallofcode@yahoo-inc.com.invalid> wrote:
> >
> > > You might try playing with the expected fragment size. That's tunable
> and
> > > you can get a partial effect of more contiguous fragments by making i=
t
> > > larger, although I think the absolute maximum is 16M. This doesn't co=
st
> > > additional disk space as it is a maximum fragment size, not a forced
> one.
> > >
> > >
> >
>
>
>
> --
>
> *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:* anhld2@vng.com.vn
>
> *W: *www.vng.com.vn
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.vng.com.vn&
> sa=3DD&sntz=3D1&usg=3DAFQjCNHYo7I_1mPESzfIvCNjLtAJOq8xsg>
>
> *=E2=80=9CMake the Internet change Vietnamese lives=E2=80=9D*


--=20

*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:* anhld2@vng.com.vn

*W: *www.vng.com.vn
<http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.vng.com.vn&sa=3DD&sntz=3D1&=
usg=3DAFQjCNHYo7I_1mPESzfIvCNjLtAJOq8xsg>

*=E2=80=9CMake the Internet change Vietnamese lives=E2=80=9D*

--f403045e4188ceb59205512ee1e0--