You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Yongming Zhao <mi...@gmail.com> on 2013/08/02 04:27:47 UTC

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

I'd like to know if we can set default enable on proxy.config.allocator.enable_reclaim, that will show big help in memory control and also better performance due to the threading allocator implement

is there anyone who benefit from it too?

在 2013-7-25,上午12:42,James Peach <jp...@apache.org> 写道:

> On Jul 24, 2013, at 9:16 AM, Mark Harrison <ma...@omniti.com> wrote:
> 
>> 1) The various proxy.config.diags.output options to configure where logs go. The defaults are sometimes not ideal and I'm always looking them up if I want to change them.
>> 
>> 2) I'm not sure there's anything that should be here, unless there are deprecated items such as ssl.enabled that you actively want to discourage the use of.
>> 
>> 3) I usually make the following changes in my records.config. I'm not sure they would make sense as defaults, but I'm mentioning them just in case they do:
>> 
>> proxy.config.http.insert_request_via_str INT 3
>> proxy.config.http.insert_response_via_str INT 3
>> 
>> (for debugging purposes usually/making it easy for people to report issues with caching)
>> 
>> proxy.config.http.server_ports STRING 80
>> 
>> (if reverse proxy/remap_required is the default, then setting the port to 80 might also be a sensible default)
>> 
>> I always manually set proxy.config.cache.ram_cache.size, but I'm not sure changing the default makes sense here as it's a per-system value.
>> 
>> Possibly update the default SSL cipher suite to address recent-ish SSL attacks?
> 
> Should proxy.config.ssl.server.honor_cipher_order then default to 1?
> 
>> 
>> 
>> 
>> 
>> On Wed, Jul 24, 2013 at 11:46 AM, Leif Hedstrom <zw...@apache.org> wrote:
>> Hi all (particularly "users"),
>> 
>> We'd like to get everyone's input on the records.config defaults and what variables are in there, based on user experience. I.e.
>> 
>> 1. Are there configurations that you often use, which are not in the
>>   default records.config today?
>> 2. Are there configurations that are in records.config, that you feel are
>>   so esoteric that they don't deserve to be in the default config file?
>> 3. Are there values that you always change, and feel we ought to modify the
>>   defaults for?
>> 
>> 
>> Please respond to this email asap, so that we can get any such changes in to the records.config.default.in before v3.3.5. 1) and 2) are fairly straight forward to justify, 3) would have to be done with care (since it breaks old behavior).
>> 
>> Cheers,
>> 
>> -- Leif
>> 
>> 
>> 
>> 
>> -- 
>> Mark Harrison
>> Lead Site Reliability Engineer
>> OmniTI
> 


Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 11:00 PM, Yunkai Zhang <yu...@gmail.com> wrote:

>
>
>
> On Fri, Aug 2, 2013 at 4:33 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
>>
>> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
>> after they compiled ATS with --enable-reclaimable-freelist option.
>>
>> They were confused by "enable_reclaim" option, I think we should make it
>> to 1 as default.
>>
>>
>> Seems reasonable to me. Alternatively, how about making it such that you
>> expand it to "1" if the --enable-reclaimable-freelist option was given?
>> That ought to be really easy to do, and avoids confusion.
>>
>> In fact, I'd recommend you doing it such that you *only* have these
>> configurations in the default records.config.default.in *if* the
>> configure option is enabled. Same with the SSD patch IMO.
>>
>
>
> There is a little hard to *hide* reclaimable-freelist configurations in
> records.config.default.in. And there are enough comments for user:
>
>
> ##############################################################################
> #
> # Configuration for Reclaimable InkFreeList memory pool
> #
> # NOTE: The following options are not meaningful unless compiles
> TrafficServer
> #       with '--enable-reclaimable-freelist' option. Looks like:
> #       $ ./configure --enable-reclaimable-freelist
> #
>
> ##############################################################################
> ....
>
> So, I don't want to hide it, but just as you suggested above, I'll make
> "enable_reclaim" expand to "1" only when "--enable-reclaimable-freelist"
> option was given.
>

Sorry, since the comments has told us that "The following options are not
meaningful unless ...",

Why not make the "enable_recalim" to "1" as defalut?

Just do it in simple way.



>
>
>
>>
>> -- Leif
>>
>>
>
>
> --
> Yunkai Zhang
> Work at Taobao
>



-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 11:00 PM, Yunkai Zhang <yu...@gmail.com> wrote:

>
>
>
> On Fri, Aug 2, 2013 at 4:33 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
>>
>> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
>> after they compiled ATS with --enable-reclaimable-freelist option.
>>
>> They were confused by "enable_reclaim" option, I think we should make it
>> to 1 as default.
>>
>>
>> Seems reasonable to me. Alternatively, how about making it such that you
>> expand it to "1" if the --enable-reclaimable-freelist option was given?
>> That ought to be really easy to do, and avoids confusion.
>>
>> In fact, I'd recommend you doing it such that you *only* have these
>> configurations in the default records.config.default.in *if* the
>> configure option is enabled. Same with the SSD patch IMO.
>>
>
>
> There is a little hard to *hide* reclaimable-freelist configurations in
> records.config.default.in. And there are enough comments for user:
>
>
> ##############################################################################
> #
> # Configuration for Reclaimable InkFreeList memory pool
> #
> # NOTE: The following options are not meaningful unless compiles
> TrafficServer
> #       with '--enable-reclaimable-freelist' option. Looks like:
> #       $ ./configure --enable-reclaimable-freelist
> #
>
> ##############################################################################
> ....
>
> So, I don't want to hide it, but just as you suggested above, I'll make
> "enable_reclaim" expand to "1" only when "--enable-reclaimable-freelist"
> option was given.
>

Sorry, since the comments has told us that "The following options are not
meaningful unless ...",

Why not make the "enable_recalim" to "1" as defalut?

Just do it in simple way.



>
>
>
>>
>> -- Leif
>>
>>
>
>
> --
> Yunkai Zhang
> Work at Taobao
>



-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 4:33 PM, Leif Hedstrom <zw...@apache.org> wrote:

>
> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
>
> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
> after they compiled ATS with --enable-reclaimable-freelist option.
>
> They were confused by "enable_reclaim" option, I think we should make it
> to 1 as default.
>
>
> Seems reasonable to me. Alternatively, how about making it such that you
> expand it to "1" if the --enable-reclaimable-freelist option was given?
> That ought to be really easy to do, and avoids confusion.
>
> In fact, I'd recommend you doing it such that you *only* have these
> configurations in the default records.config.default.in *if* the
> configure option is enabled. Same with the SSD patch IMO.
>


There is a little hard to *hide* reclaimable-freelist configurations in
records.config.default.in. And there are enough comments for user:

##############################################################################
#
# Configuration for Reclaimable InkFreeList memory pool
#
# NOTE: The following options are not meaningful unless compiles
TrafficServer
#       with '--enable-reclaimable-freelist' option. Looks like:
#       $ ./configure --enable-reclaimable-freelist
#
##############################################################################
....

So, I don't want to hide it, but just as you suggested above, I'll make
"enable_reclaim" expand to "1" only when "--enable-reclaimable-freelist"
option was given.



>
> -- Leif
>
>


-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
在 2013年8月2日星期五,Leif Hedstrom 写道:

> On Aug 2, 2013, at 1:07 PM, Yunkai Zhang <yunkai.me@gmail.com<javascript:;>>
> wrote:
>
> > On Fri, Aug 2, 2013 at 6:15 PM, Leif Hedstrom <leif@ogre.com<javascript:;>>
> wrote:
> >
> >
> >
> > The reason of why reclaming memory is need is that:
> >
> > In the freelist, there are different size blocks:
> >
> > 1KB, 2KB, 4KB, 8KB, ...
> >
> > different size block will be placed into different list.
> >
> > suppose at some time, 2KB block is hot, so ATS will allocate many 2KB
> > blocks and put them into 2KB-list.
> >
> > After a while, 4KB block becomes hot, then ATS will allocate many 4KB
> > blocks and put them into 4KB-list.
>
> Ok, that makes sense. Note sure why things are spiking in such different
> patterns, but at least it adds up with how the free list behaves :).
>
> I'd still vote on leaving this out as a default until after v3.4.0. We
> need some stability IMO.


i
 Ok for me. reclaimable-freelist is stable at Linux platform I think, but I
can't promise at other platforms.

Just keep old version freelist as default, don't too aggressive:)



> -- leif
>
>

-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 2, 2013, at 1:07 PM, Yunkai Zhang <yu...@gmail.com> wrote:

> On Fri, Aug 2, 2013 at 6:15 PM, Leif Hedstrom <le...@ogre.com> wrote:
> 
> 
> 
> The reason of why reclaming memory is need is that:
> 
> In the freelist, there are different size blocks:
> 
> 1KB, 2KB, 4KB, 8KB, ...
> 
> different size block will be placed into different list.
> 
> suppose at some time, 2KB block is hot, so ATS will allocate many 2KB
> blocks and put them into 2KB-list.
> 
> After a while, 4KB block becomes hot, then ATS will allocate many 4KB
> blocks and put them into 4KB-list.

Ok, that makes sense. Note sure why things are spiking in such different patterns, but at least it adds up with how the free list behaves :).

I'd still vote on leaving this out as a default until after v3.4.0. We need some stability IMO.

-- leif


Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 6:15 PM, Leif Hedstrom <le...@ogre.com> wrote:

>
> On Aug 2, 2013, at 12:01 PM, Yongming Zhao <mi...@gmail.com> wrote:
>
> > I'd like to enable that reclaimable free list by default building &
> installation, can we?
>
> I'd prefer not for v3.3.5 / 3.4.0. If you still do, I'd absolutely insist
> on it being off by default. We do not have enough data points for the
> usefulness of this feature, and what impact it might have on other systems
> / platforms / services (or e.g. NUMA).
>
> As you know, I still don't buy the reasons why reclaiming memory is
> necessary. It feels like a duct tape solution to an unknown problem (why is
> it allocating more memory than you want it to? Why are you running other
> applications / tools that are competing for memory? How do you avoid for
> the two to not compete for the same memory?).
>


The reason of why reclaming memory is need is that:

In the freelist, there are different size blocks:

1KB, 2KB, 4KB, 8KB, ...

different size block will be placed into different list.

suppose at some time, 2KB block is hot, so ATS will allocate many 2KB
blocks and put them into 2KB-list.

After a while, 4KB block becomes hot, then ATS will allocate many 4KB
blocks and put them into 4KB-list.

... 8KB ...
... 16KB ...
.... .... ....

After ATS running a long time, the number of allocated blocks in each list
will reach the *peek* level, but at some time, *not all* block is hot!

The blocks which not hot, but have been allocated at *peek* level, is the
root cause of memory wast.

That is why reclaiming memory is necessary for ATS, and why
reclaimable-freelist patch can take effect.



>
> All my $.01 of course.
>
> -- Leif
>
>


-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 6:15 PM, Leif Hedstrom <le...@ogre.com> wrote:

>
> On Aug 2, 2013, at 12:01 PM, Yongming Zhao <mi...@gmail.com> wrote:
>
> > I'd like to enable that reclaimable free list by default building &
> installation, can we?
>
> I'd prefer not for v3.3.5 / 3.4.0. If you still do, I'd absolutely insist
> on it being off by default. We do not have enough data points for the
> usefulness of this feature, and what impact it might have on other systems
> / platforms / services (or e.g. NUMA).
>
> As you know, I still don't buy the reasons why reclaiming memory is
> necessary. It feels like a duct tape solution to an unknown problem (why is
> it allocating more memory than you want it to? Why are you running other
> applications / tools that are competing for memory? How do you avoid for
> the two to not compete for the same memory?).
>


The reason of why reclaming memory is need is that:

In the freelist, there are different size blocks:

1KB, 2KB, 4KB, 8KB, ...

different size block will be placed into different list.

suppose at some time, 2KB block is hot, so ATS will allocate many 2KB
blocks and put them into 2KB-list.

After a while, 4KB block becomes hot, then ATS will allocate many 4KB
blocks and put them into 4KB-list.

... 8KB ...
... 16KB ...
.... .... ....

After ATS running a long time, the number of allocated blocks in each list
will reach the *peek* level, but at some time, *not all* block is hot!

The blocks which not hot, but have been allocated at *peek* level, is the
root cause of memory wast.

That is why reclaiming memory is necessary for ATS, and why
reclaimable-freelist patch can take effect.



>
> All my $.01 of course.
>
> -- Leif
>
>


-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Leif Hedstrom <le...@ogre.com>.
On Aug 2, 2013, at 12:01 PM, Yongming Zhao <mi...@gmail.com> wrote:

> I'd like to enable that reclaimable free list by default building & installation, can we?

I'd prefer not for v3.3.5 / 3.4.0. If you still do, I'd absolutely insist on it being off by default. We do not have enough data points for the usefulness of this feature, and what impact it might have on other systems / platforms / services (or e.g. NUMA).

As you know, I still don't buy the reasons why reclaiming memory is necessary. It feels like a duct tape solution to an unknown problem (why is it allocating more memory than you want it to? Why are you running other applications / tools that are competing for memory? How do you avoid for the two to not compete for the same memory?).

All my $.01 of course.

-- Leif


Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yongming Zhao <mi...@gmail.com>.
I'd like to enable that reclaimable free list by default building & installation, can we?


在 2013-8-2,下午4:33,Leif Hedstrom <zw...@apache.org> 写道:

> 
> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
> 
>> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1 after they compiled ATS with --enable-reclaimable-freelist option.
>> 
>> They were confused by "enable_reclaim" option, I think we should make it to 1 as default.
> 
> Seems reasonable to me. Alternatively, how about making it such that you expand it to "1" if the --enable-reclaimable-freelist option was given? That ought to be really easy to do, and avoids confusion. 
> 
> In fact, I'd recommend you doing it such that you *only* have these configurations in the default records.config.default.in *if* the configure option is enabled. Same with the SSD patch IMO.
> 
> -- Leif
> 


Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 4:33 PM, Leif Hedstrom <zw...@apache.org> wrote:

>
> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
>
> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
> after they compiled ATS with --enable-reclaimable-freelist option.
>
> They were confused by "enable_reclaim" option, I think we should make it
> to 1 as default.
>
>
> Seems reasonable to me. Alternatively, how about making it such that you
> expand it to "1" if the --enable-reclaimable-freelist option was given?
> That ought to be really easy to do, and avoids confusion.
>
> In fact, I'd recommend you doing it such that you *only* have these
> configurations in the default records.config.default.in *if* the
> configure option is enabled. Same with the SSD patch IMO.
>

It sounds good to me. Let me cook a patch:)


>
> -- Leif
>
>


-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yongming Zhao <mi...@gmail.com>.
I'd like to enable that reclaimable free list by default building & installation, can we?


在 2013-8-2,下午4:33,Leif Hedstrom <zw...@apache.org> 写道:

> 
> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
> 
>> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1 after they compiled ATS with --enable-reclaimable-freelist option.
>> 
>> They were confused by "enable_reclaim" option, I think we should make it to 1 as default.
> 
> Seems reasonable to me. Alternatively, how about making it such that you expand it to "1" if the --enable-reclaimable-freelist option was given? That ought to be really easy to do, and avoids confusion. 
> 
> In fact, I'd recommend you doing it such that you *only* have these configurations in the default records.config.default.in *if* the configure option is enabled. Same with the SSD patch IMO.
> 
> -- Leif
> 


Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 4:33 PM, Leif Hedstrom <zw...@apache.org> wrote:

>
> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
>
> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
> after they compiled ATS with --enable-reclaimable-freelist option.
>
> They were confused by "enable_reclaim" option, I think we should make it
> to 1 as default.
>
>
> Seems reasonable to me. Alternatively, how about making it such that you
> expand it to "1" if the --enable-reclaimable-freelist option was given?
> That ought to be really easy to do, and avoids confusion.
>
> In fact, I'd recommend you doing it such that you *only* have these
> configurations in the default records.config.default.in *if* the
> configure option is enabled. Same with the SSD patch IMO.
>

It sounds good to me. Let me cook a patch:)


>
> -- Leif
>
>


-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
On Fri, Aug 2, 2013 at 4:33 PM, Leif Hedstrom <zw...@apache.org> wrote:

>
> On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:
>
> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
> after they compiled ATS with --enable-reclaimable-freelist option.
>
> They were confused by "enable_reclaim" option, I think we should make it
> to 1 as default.
>
>
> Seems reasonable to me. Alternatively, how about making it such that you
> expand it to "1" if the --enable-reclaimable-freelist option was given?
> That ought to be really easy to do, and avoids confusion.
>
> In fact, I'd recommend you doing it such that you *only* have these
> configurations in the default records.config.default.in *if* the
> configure option is enabled. Same with the SSD patch IMO.
>


There is a little hard to *hide* reclaimable-freelist configurations in
records.config.default.in. And there are enough comments for user:

##############################################################################
#
# Configuration for Reclaimable InkFreeList memory pool
#
# NOTE: The following options are not meaningful unless compiles
TrafficServer
#       with '--enable-reclaimable-freelist' option. Looks like:
#       $ ./configure --enable-reclaimable-freelist
#
##############################################################################
....

So, I don't want to hide it, but just as you suggested above, I'll make
"enable_reclaim" expand to "1" only when "--enable-reclaimable-freelist"
option was given.



>
> -- Leif
>
>


-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:

> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1 after they compiled ATS with --enable-reclaimable-freelist option.
> 
> They were confused by "enable_reclaim" option, I think we should make it to 1 as default.

Seems reasonable to me. Alternatively, how about making it such that you expand it to "1" if the --enable-reclaimable-freelist option was given? That ought to be really easy to do, and avoids confusion. 

In fact, I'd recommend you doing it such that you *only* have these configurations in the default records.config.default.in *if* the configure option is enabled. Same with the SSD patch IMO.

-- Leif


Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 2, 2013, at 9:49 AM, Yunkai Zhang <yu...@gmail.com> wrote:

> So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1 after they compiled ATS with --enable-reclaimable-freelist option.
> 
> They were confused by "enable_reclaim" option, I think we should make it to 1 as default.

Seems reasonable to me. Alternatively, how about making it such that you expand it to "1" if the --enable-reclaimable-freelist option was given? That ought to be really easy to do, and avoids confusion. 

In fact, I'd recommend you doing it such that you *only* have these configurations in the default records.config.default.in *if* the configure option is enabled. Same with the SSD patch IMO.

-- Leif


Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
after they compiled ATS with --enable-reclaimable-freelist option.

They were confused by "enable_reclaim" option, I think we should make it to
1 as default.


On Fri, Aug 2, 2013 at 10:27 AM, Yongming Zhao <mi...@gmail.com> wrote:

> I'd like to know if we can set default enable on
> proxy.config.allocator.enable_reclaim, that will show big help in memory
> control and also better performance due to the threading allocator implement
>
> is there anyone who benefit from it too?
>
> 在 2013-7-25,上午12:42,James Peach <jp...@apache.org> 写道:
>
> > On Jul 24, 2013, at 9:16 AM, Mark Harrison <ma...@omniti.com> wrote:
> >
> >> 1) The various proxy.config.diags.output options to configure where
> logs go. The defaults are sometimes not ideal and I'm always looking them
> up if I want to change them.
> >>
> >> 2) I'm not sure there's anything that should be here, unless there are
> deprecated items such as ssl.enabled that you actively want to discourage
> the use of.
> >>
> >> 3) I usually make the following changes in my records.config. I'm not
> sure they would make sense as defaults, but I'm mentioning them just in
> case they do:
> >>
> >> proxy.config.http.insert_request_via_str INT 3
> >> proxy.config.http.insert_response_via_str INT 3
> >>
> >> (for debugging purposes usually/making it easy for people to report
> issues with caching)
> >>
> >> proxy.config.http.server_ports STRING 80
> >>
> >> (if reverse proxy/remap_required is the default, then setting the port
> to 80 might also be a sensible default)
> >>
> >> I always manually set proxy.config.cache.ram_cache.size, but I'm not
> sure changing the default makes sense here as it's a per-system value.
> >>
> >> Possibly update the default SSL cipher suite to address recent-ish SSL
> attacks?
> >
> > Should proxy.config.ssl.server.honor_cipher_order then default to 1?
> >
> >>
> >>
> >>
> >>
> >> On Wed, Jul 24, 2013 at 11:46 AM, Leif Hedstrom <zw...@apache.org>
> wrote:
> >> Hi all (particularly "users"),
> >>
> >> We'd like to get everyone's input on the records.config defaults and
> what variables are in there, based on user experience. I.e.
> >>
> >> 1. Are there configurations that you often use, which are not in the
> >>   default records.config today?
> >> 2. Are there configurations that are in records.config, that you feel
> are
> >>   so esoteric that they don't deserve to be in the default config file?
> >> 3. Are there values that you always change, and feel we ought to modify
> the
> >>   defaults for?
> >>
> >>
> >> Please respond to this email asap, so that we can get any such changes
> in to the records.config.default.in before v3.3.5. 1) and 2) are fairly
> straight forward to justify, 3) would have to be done with care (since it
> breaks old behavior).
> >>
> >> Cheers,
> >>
> >> -- Leif
> >>
> >>
> >>
> >>
> >> --
> >> Mark Harrison
> >> Lead Site Reliability Engineer
> >> OmniTI
> >
>
>


-- 
Yunkai Zhang
Work at Taobao

Re: [DISCUSS] Updates to records.config (default) for v3.4.0

Posted by Yunkai Zhang <yu...@gmail.com>.
So many users forgot to set "proxy.config.allocator.enable_reclaim" to 1
after they compiled ATS with --enable-reclaimable-freelist option.

They were confused by "enable_reclaim" option, I think we should make it to
1 as default.


On Fri, Aug 2, 2013 at 10:27 AM, Yongming Zhao <mi...@gmail.com> wrote:

> I'd like to know if we can set default enable on
> proxy.config.allocator.enable_reclaim, that will show big help in memory
> control and also better performance due to the threading allocator implement
>
> is there anyone who benefit from it too?
>
> 在 2013-7-25,上午12:42,James Peach <jp...@apache.org> 写道:
>
> > On Jul 24, 2013, at 9:16 AM, Mark Harrison <ma...@omniti.com> wrote:
> >
> >> 1) The various proxy.config.diags.output options to configure where
> logs go. The defaults are sometimes not ideal and I'm always looking them
> up if I want to change them.
> >>
> >> 2) I'm not sure there's anything that should be here, unless there are
> deprecated items such as ssl.enabled that you actively want to discourage
> the use of.
> >>
> >> 3) I usually make the following changes in my records.config. I'm not
> sure they would make sense as defaults, but I'm mentioning them just in
> case they do:
> >>
> >> proxy.config.http.insert_request_via_str INT 3
> >> proxy.config.http.insert_response_via_str INT 3
> >>
> >> (for debugging purposes usually/making it easy for people to report
> issues with caching)
> >>
> >> proxy.config.http.server_ports STRING 80
> >>
> >> (if reverse proxy/remap_required is the default, then setting the port
> to 80 might also be a sensible default)
> >>
> >> I always manually set proxy.config.cache.ram_cache.size, but I'm not
> sure changing the default makes sense here as it's a per-system value.
> >>
> >> Possibly update the default SSL cipher suite to address recent-ish SSL
> attacks?
> >
> > Should proxy.config.ssl.server.honor_cipher_order then default to 1?
> >
> >>
> >>
> >>
> >>
> >> On Wed, Jul 24, 2013 at 11:46 AM, Leif Hedstrom <zw...@apache.org>
> wrote:
> >> Hi all (particularly "users"),
> >>
> >> We'd like to get everyone's input on the records.config defaults and
> what variables are in there, based on user experience. I.e.
> >>
> >> 1. Are there configurations that you often use, which are not in the
> >>   default records.config today?
> >> 2. Are there configurations that are in records.config, that you feel
> are
> >>   so esoteric that they don't deserve to be in the default config file?
> >> 3. Are there values that you always change, and feel we ought to modify
> the
> >>   defaults for?
> >>
> >>
> >> Please respond to this email asap, so that we can get any such changes
> in to the records.config.default.in before v3.3.5. 1) and 2) are fairly
> straight forward to justify, 3) would have to be done with care (since it
> breaks old behavior).
> >>
> >> Cheers,
> >>
> >> -- Leif
> >>
> >>
> >>
> >>
> >> --
> >> Mark Harrison
> >> Lead Site Reliability Engineer
> >> OmniTI
> >
>
>


-- 
Yunkai Zhang
Work at Taobao