Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#38537 closed enhancement (wontfix)

Swap out md5 for base32 in feed ETag generation

Reported by: geekysoft's profile geekysoft Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: Feeds Keywords:
Focuses: Cc:

Description

All feed ETags are currently a MD5 of the last modified timestamp. This ETag is non-reversible, meaning the ETag is entirely useless as anything but a unique identifier.

Swapping this for a base32 of the same timestamp means the ETag can be reversed back to a timestamp (if needed for plugins or whatever). Mean processing time to generate a feed with 10 entries drops by 10–15 ms on a fast PC and 15–30 on a slow VPS with this base32 patch versus the current md5 solution.

The ETag length drops from 32 to 7–9 characters so the response and subsequent validation requests are made slightly smaller as well.

Potential problems: Every client that has stored a ETag in their cache will get one cache-miss when WordPress is updated. Considering that every subsequent request will be faster, I find that totally acceptable.

Attachments (1)

class-wp.php-base_convert-etag.patch (663 bytes) - added by geekysoft 6 years ago.

Download all attachments as: .zip

Change History (3)

#1 @dd32
6 years ago

I'd be fine with switching this, but the question I have is, what's the benefit?
Having a reversible ETag doesn't seem to offer any benefit (nor does having a irreversible ETag though) - an ETag doesn't need to be human readable, just a unique single-phrase identifier for caching systems that isn't going to collide.

Performance isn't a reason here, it's not executing that often, and even if it were, md5() is going to be 10x performant as the proposed replacement here.
Out of curiosity I went ahead and benchmarked it, and it's nearly exactly 10x.. running 10,000 iterations of the two options here with date('r') as the static input.. md5: 0.00673s date: 0.07212s If you use strtotime() instead of date_* functions it's only 4x longer to execute (0.0274s). edit: those times are per 10,000 iterations, not individual runs
We're talking microseconds here, I've spent more time reading and responding than this would save the average site in it's lifetime.

Last edited 6 years ago by dd32 (previous) (diff)

#2 @stevenkword
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.