Michael,
On 9/2/25 1:09 PM, Michael Osipov wrote:
On 2025/09/02 16:03:56 Mark Thomas wrote:
On 02/09/2025 17:00, [email protected] wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 9126de9274 Switch strong ETag generation from SHA-1 to SHA-256
9126de9274 is described below
commit 9126de92742cb5eeaef5fa6b902eaec4291cd7de
Author: Mark Thomas <[email protected]>
AuthorDate: Tue Sep 2 17:00:43 2025 +0100
Switch strong ETag generation from SHA-1 to SHA-256
Given the RFC 9110 recommendation, I'm minded to back-port this all the
way to 9.0.x. Thoughts?
The computational overhead can be neglected?
This was my first thought, followed by "well, reading all the bytes
twice is probably worse than anything".
Modern CPUs have both of these algorithms in hardware. I ran "openssl
speed" on my Mac M4 and I was surprised by the results:
SHA-1
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 219546.89k 547063.27k 978184.94k 1228685.32k 1326181.23k
SHA-256
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha256 120006.08k 394487.52k 1283243.12k 2437685.65k 3289483.23k
SHA-256 turns out to be *faster* than SHA-1 for all but small data
chunks (16 and 64 bytes). All of the other numbers are faster.
On my CPU, as long as the file isn't being processed in very small
chunks (which would be silly anyway), I think the computational overhead
is not much different from using SHA-1.
On an x86-64 EC2 instance (which has many opportunities for skew), I got
these results.
SHA-1
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
16384 bytes
sha1 36122.99k 115037.18k 268401.07k 449486.17k 564688.21k
567367.00k
SHA-256
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
16384 bytes
sha256 30714.37k 84638.57k 171081.13k 231399.08k 253952.00k
260500.14k
This is more like what I had expected: SHA-256 is ~2x the wall-clock time.
On this other CPU, the computational overhead is ~2x but I suspect that
reading the file is going to be what dominates the speed equation for
overall performance.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
