You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Vlad (JIRA)" <ji...@apache.org> on 2013/11/22 20:08:36 UTC
[jira] [Comment Edited] (TS-2384) Regression in key-lookup code
between 4.0.x and 4.1.x
[ https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830237#comment-13830237 ]
Vlad edited comment on TS-2384 at 11/22/13 7:07 PM:
----------------------------------------------------
Hi,
Igor asked me to comment on this ticket with info about my system and options I've used to compile ATS.
Compile options:
./configure --prefix=/opt/trafficserver-4.1.1 --enable-experimental-plugins --enable-reclaimable-freelist --with-user=ats --with-group=ats --enable-cppapi
hwloc-devel package installed.
System:
CentOS 6.4 - 2.6.32-358.18.1.el6.x86_64
My previous installation was under /opt/trafficserver-4.0.1, then I've compiled 4.1.1 to /opt/trafficserver-4.1.1 and copied all config files. When I've ran a new ATS 4.1.1, I've found, that all previously cached objects are MISSed. But, after switched back to 4.0.1, all objects was in cache and HITed again.
was (Author: vlad.bach):
Hi,
Igor asked me to comment to this ticket, with info about my system and options I've used to compile ATS.
Compile options:
./configure --prefix=/opt/trafficserver-4.1.1 --enable-experimental-plugins --enable-reclaimable-freelist --with-user=ats --with-group=ats --enable-cppapi
hwloc-devel package installed.
System:
CentOS 6.4 - 2.6.32-358.18.1.el6.x86_64
My previous installation was under /opt/trafficserver-4.0.1, then I've compiled 4.1.1 to /opt/trafficserver-4.1.1 and copied all config files. When I've ran a new ATS 4.1.1, I've found, that all previously cached objects are MISSed. But, after switched back to 4.0.1, all objects was in cache and HITed again.
> Regression in key-lookup code between 4.0.x and 4.1.x
> -----------------------------------------------------
>
> Key: TS-2384
> URL: https://issues.apache.org/jira/browse/TS-2384
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
> Reporter: Igor Galić
> Fix For: 4.1.2
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial 388912
> header length 2480
> fragment type 1
> No of Alternates 1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial 388912
> header length 2480
> fragment type 1
> No of Alternates 1
> {noformat}
> When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these objects downloading from parent, and then they HIT again.
> *Note* This does not cause the cache to be reinitialized.
> It's just that the generated cache-lookup *key* is wrong in 4.1.x. This means that the existing objects on the disks will stay in place, but we won't be able to find them, because we are looking in the wrong place. As such we simply store the object again.
> That's *almost* the same for people running with a 60 TiB cache, because everything requested is also stored again,
> and after a while the old objects that have been lying around for a while will be rotated out so that's bad. People with
> tiny caches or very high turn overs might even notice the downward spike in 304s.
--
This message was sent by Atlassian JIRA
(v6.1#6144)