[
https://issues.apache.org/jira/browse/TS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Plevyak updated TS-120:
----------------------------
Attachment: ts-120-121-jp-v1.patch
This patch changes the ram cache replacement algorithm and add
support for automatic compression and decompression of ram cache
entries.
The new policy takes into account frequency and size using an algorithm
loosely based on a number of ones I have been reading about including
the CLOCK and 2Q algorithms as well as GDSF. It does not use a priority
queue so it is very fast. It uses 2 levels of history. I have done some
testing
and it seems to be reasonable, but we need some traces to get hard data.
Compression must be enabled at startup and is configurable as a percent
of the ram cache (the most recently used is left uncompressed in the hope
that it might be reused). Compression is via zlib and configure.ac has been
enhanced to detect it.
Unfortunately some surgery on the cache was required as we store the
unmarshalled HTTP headers in the cache and share them read only for
efficiency, and those cannot be compressed. Therefore when compression
is enabled, the HTTP headers are stored marshalled in the ram cache which
is somewhat less efficient, but hey, you are burning cycles on compression.
However, this means that compression cannot be dynamically turned on
and off, although the percentage can be modified.
> Automatic compression/decompression in the RAM cache
> ----------------------------------------------------
>
> Key: TS-120
> URL: https://issues.apache.org/jira/browse/TS-120
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cache
> Reporter: John Plevyak
> Assignee: John Plevyak
> Priority: Minor
> Attachments: ts-120-121-jp-v1.patch
>
>
> It would be nice if we could enable automatic compression/decompression in
> the RAM cache.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
