I was trying to get a better understanding of the caching algorithm and what items it would evict when the cache was full and how long it would take to fill the cache. Hence the small cache size, faster to fill.
I wasn't going to report the issue, but a segmentation fault is probably something that should be looked at as you pointed out. Anyway, as pointed out in previous threads, the cache is a circular buffer and the least recently used items get evicted first, as long as the item is cacheable the headers do not affect how long it remains in the cache, the LRU determines this. As for how long it takes to fill the cache, if you subtract 65M from the value specified for the cache size in the storage config. If I set the cache size to 128M in the storage config, then the cache is 63M, according to the debug statements in the traffic.out and in practice this seems to be the case. Is this 65M for the ram cache or the http header store else, or something else, I don't know. If the the compression is not turned on then it is roughly a one to one mapping between the http object sizes and what the cache stores, there is a little overheard per http item though, is this attributed to the cache key and that http objects are stored as fragments? Thanks, Kevin. On 28 Jun 2011, at 16:45, Igor Galić wrote: > > > ----- Original Message ----- >> Hi, >> >> I turned enabled the debugging for the cache, I noticed that the >> cache size is always 65M less than the value I specified in the > > People will usually complain about their multi-TB sized caches > getting a little wonky at times. But I've never heard someone > complain about 65M - that sounds terribly small for a cache.. > >> storage.config >> and also if I set it to a value less than 65, 64 for example >> traffic_server throws a segmentation fault on startup. Is this a >> bug? > > However, a Segmentation fault always sounds like a bug to me.. > > >> Does anyone know why it always takes 65M away? > > Lets start out by having you submit that as a bug: > https://cwiki.apache.org/confluence/display/TS/Filing+useful+bug+reports > >> Thanks and Regards, >> >> Kevin. > > i > > -- > Igor Galić > > Tel: +43 (0) 664 886 22 883 > Mail: i.ga...@brainsware.org > URL: http://brainsware.org/
