what we want to do is make the 8k doc into doc or ssd as more as possible, which can reduce hdd read IO times.

Hi @wangchunpeng,

As I understand it, ATS's behavior when handling a 304 Not Modified response from the origin is mostly the same whether using the Slice plugin or not. In both cases:

1. A new metadata record is created for a "header update," only one per URL regardless of slicing.
2. A subsequent client request requires two I/O reads per slice: one for the metadata and one for the body data.

Are you seeing I/O overhead that is different for slicing, specifically when handling 304?

I think what's happening is that each slice of that asset is having to handle and store the 304 response. In the general case I'm not sure how to get around that since individual slices of the same asset name might have different content from multiple different versions of the named asset.

A possible solution:

Use a reference slice. That should always have the most up to date etag/last-modified "variant identifier" (or whatever it's called).

Pass this reference slice etag/last-modified "variant identifier" to subsequent calls of the CRR plugin. If the CRR plugin encounters a STALE in-cache result (from cache read hook) but the variant identifier matches, switch to FRESH and continue (reference regex_revalidate plugin for a rough example). This should stop the CRR plugin from going to parent and also should result in not having a variant header being written to cache. I think.

Hi @wangchunpeng,

As I understand it, ATS's behavior when handling a 304 Not Modified response from the origin is mostly the same whether using the Slice plugin or not. In both cases:

1. A new metadata record is created for a "header update," only one per URL regardless of slicing.
2. A subsequent client request requires two I/O reads per slice: one for the metadata and one for the body data.

Are you seeing I/O overhead that is different for slicing, specifically when handling 304?

The version we use is 9.3.2, and for the very first request, each slice request is stored using only one doc when the request is closed when writing to the Vol