Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: pass (athena.apache.org: domain of jplevyak@gmail.com designates
 209.85.214.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F9636AD.3030208@apache.org>
References: <1335221727.37747.YahooMailNeo@web31806.mail.mud.yahoo.com>
	<1335233072.24851.16.camel@taorui-ThinkPad-X201>
	<CACgLx2qgyx2DaHTKO9t6hv5EESkC_+TKKvu6GdaUSZGVw4o0fw@mail.gmail.com>
	<4F9636AD.3030208@apache.org>
Date: Tue, 24 Apr 2012 11:07:18 -0700
Message-ID: 
 <CACgLx2oZxtw7P8rZmyVVenNNEsTsFdVSLv-HZtwWZqit-VAHxA@mail.gmail.com>
Subject: Re: any sort of 32bit limitation preventing large file caches?
From: John Plevyak <jplevyak@gmail.com>
To: users@trafficserver.apache.org
Content-Type: multipart/alternative; boundary=0015175cd8be1819aa04be70a0dc

--0015175cd8be1819aa04be70a0dc
Content-Type: text/plain; charset=ISO-8859-1

Yes, you could increase that, up to closer to ~4MB (AGG_SIZE - sizeof_DOC)
 That would give you up to 20GB files.  Certainly, we could bump up
AGG_SIZE, although tying up the disk with large writes might impact read
latency to some extent.    We could make AGG_SIZE 8MB for example which at
100MB/sec transfer rate is going to eat up ~80msec at the disk.

john


On Mon, Apr 23, 2012 at 10:14 PM, Leif Hedstrom <zwoop@apache.org> wrote:

> On 4/23/12 9:42 PM, John Plevyak wrote:
>
>>
>> Humm... it would be easy to enlarge the aggregation buffer or disable the
>> fragment offsets in the header.   The former is probably the most powerful
>> solution since if you are serving huge documents, you probably want the
>> ability to restart/seek and likely also have significant memory on a per
>> disk basis.   We could make it configurable.
>>
>>
> Is this something we should add for v3.1.4 / v3.2?
>
> Also, does increasing the fragment size change any of this ? Perhaps not
> an ideal solution, but, we still haven't fixed TS-475 anyways so can't
> position / seek afaik ?
>
> -- Leif
>
> CONFIG proxy.config.cache.target_**fragment_size INT 1048576
>

--0015175cd8be1819aa04be70a0dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Yes, you co=
uld increase that, up to closer to ~4MB (AGG_SIZE - sizeof_DOC) =A0That wou=
ld give you up to 20GB files. =A0Certainly, we could bump up AGG_SIZE, alth=
ough tying up the disk with large writes might impact read latency to some =
extent. =A0 =A0We could make AGG_SIZE 8MB for example which at 100MB/sec tr=
ansfer rate is going to eat up ~80msec at the disk.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">john =A0</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><br>=
<div class=3D"gmail_quote">On Mon, Apr 23, 2012 at 10:14 PM, Leif Hedstrom =
<span dir=3D"ltr">&lt;<a href=3D"mailto:zwoop@apache.org" target=3D"_blank"=
>zwoop@apache.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 4/23/12 9:42 PM, John P=
levyak wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
Humm... it would be easy to enlarge the aggregation buffer or disable the f=
ragment offsets in the header. =A0 The former is probably the most powerful=
 solution since if you are serving huge documents, you probably want the ab=
ility to restart/seek and likely also have significant memory on a per disk=
 basis. =A0 We could make it configurable.<br>

<br>
</blockquote>
<br></div>
Is this something we should add for v3.1.4 / v3.2?<br>
<br>
Also, does increasing the fragment size change any of this ? Perhaps not an=
 ideal solution, but, we still haven&#39;t fixed TS-475 anyways so can&#39;=
t position / seek afaik ?<br>
<br>
-- Leif<br>
<br>
CONFIG proxy.config.cache.target_<u></u>fragment_size INT 1048576<br>
</blockquote></div><br></div>

--0015175cd8be1819aa04be70a0dc--