You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2020/04/08 03:07:30 UTC
Is anyone using the %{<...>records} log tag?
Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
%<{proxy.process.version.server.build_number}record>
Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
Thoughts?
— leif
P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Bryan Call <bc...@apache.org>.
+1 - Creates lock contention and shouldn’t be used in a production system.
-Bryan
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Patrick O'Brien <pa...@tetrisblocks.net>.
+1
On Tue, Apr 7, 2020 at 8:07 PM Leif Hedstrom <zw...@apache.org> wrote:
> Accidentally (I blame Bryan …) we discovered that using this log tag can
> put some noticeable pressure on mutexes in the librecords subsystem. You’d
> use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if
> no one really objects, I’d like to recommend that we mark this log tag as
> “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on
> performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to
> suggest that we simply implement normal log tags (which was tried before,
> and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Bryan Call <bc...@apache.org>.
+1 - Creates lock contention and shouldn’t be used in a production system.
-Bryan
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Bryan Call <bc...@apache.org>.
+1 - Creates lock contention and shouldn’t be used in a production system.
-Bryan
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Bryan Call <bc...@apache.org>.
+1 - Creates lock contention and shouldn’t be used in a production system.
-Bryan
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Bryan Call <bc...@apache.org>.
+1 - Creates lock contention and shouldn’t be used in a production system.
-Bryan
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Sudheer Vinukonda <su...@yahoo.com.INVALID>.
+1
We don’t use this log tag. If anyone’s using this, I’d be very curious to hear the reasons to include the server version in the access logs.
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Bryan Call <bc...@apache.org>.
+1 - Creates lock contention and shouldn’t be used in a production system.
-Bryan
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s
Re: Is anyone using the %{<...>records} log tag?
Posted by Sudheer Vinukonda <su...@yahoo.com>.
+1
We don’t use this log tag. If anyone’s using this, I’d be very curious to hear the reasons to include the server version in the access logs.
> On Apr 7, 2020, at 8:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Accidentally (I blame Bryan …) we discovered that using this log tag can put some noticeable pressure on mutexes in the librecords subsystem. You’d use it like
>
> %<{proxy.process.version.server.build_number}record>
>
>
> Seeing that this (ab)use of librecord is not how it was intended for, if no one really objects, I’d like to recommend that we mark this log tag as “Deprecated” for 9.0.0 (it’ll still function), with a big fat warning on performance problems. And then for 10.0.0, we remove it.
>
> If people have use cases like the above, Randall and I would like to suggest that we simply implement normal log tags (which was tried before, and was shutdown unfortunately).
>
> Thoughts?
>
> — leif
>
> P.s