• Nils Goroll's avatar
    Optimize 304 template object copying · 98b6b954
    Nils Goroll authored
    When copying a stale object after a 304 revalidation, we iterated over
    it and allocated new storage for each storage segment.
    
    So, at best, we kept the fragmentation of the existing object, or made
    it even worse. This is particularly relevant when the existing object
    was created from a chunked response, in which case the original
    segments might have been particularly small and, consequently, many in
    number.
    
    Because we wait for the stale object to complete, we know the total
    length (OA_LEN) upfront, and can ask the storage serving the copy for
    exactly the right length. This is much more efficient, as
    fragmentation is lowered and the storage engine might make a much
    better allocation decision when it knows the full length rather than
    getting piecemeal requests.
    
    We implement the improved allocation scheme through additional state
    kept for the duration of the template object copy: struct
    vbf_objiter_priv holds the pointer to the newly created busy object,
    the total yet unallocated length (initialized to OA_LEN of the existing
    object) and pointer/length to the unused portion of the currently open
    segment, if any.
    98b6b954
cache_fetch.c 31.2 KB