[HN Gopher] Shared Memory Versioning to improve slow interactions
___________________________________________________________________
Shared Memory Versioning to improve slow interactions
Author : feross
Score : 27 points
Date : 2024-06-03 17:33 UTC (5 hours ago)
(HTM) web link (blog.chromium.org)
(TXT) w3m dump (blog.chromium.org)
| liuliu wrote:
| This is light on details. What's the typical way to propagate
| version from shared memory to each renderer process so they know
| it is up-to-date / stale? Wouldn't a naive implementation has
| thundering herd problem?
| xuhu wrote:
| They possibly store just the version number for each cookie in
| shared memory, whereas storing complete cookie data in shared
| memory would need more synchronization.
| kevingadd wrote:
| You could come up with a scheme to store each version of the
| cookie in an accessible part of the SHM at a fixed address,
| but then you have to do GC to evict the oldest versions over
| time without causing problems etc. So I'd bet they are still
| retrieving the actual cookie contents via an RPC like before.
| tedd4u wrote:
| They don't quite spell it out fully but it seems like a good
| guess that they use a datatype (like a 64-bit word) for the
| version number that can be read and written atomically, so no
| synchronization is needed at all and it can be very fast. So
| it's only if you don't have the latest version that you do a
| slower fetch of the updated value (that you can cache) with a
| mutex to make sure you don't get a partial update.
| chaboud wrote:
| Yeah. I was looking for something a little more meaty, but
| there are solid ways to attack this.
|
| I like to use copy-on-write reference immutable tree storage
| with self-recycling/self-freeing reference counting shared
| memory objects. Entities can retain prior versions for as long
| as necessary and then pop over to new versions when they're
| ready, wait free. For ultimate cache and TLB performance, some
| other approaches (including deliberate copies) can be useful,
| but I've found the approach to be very friendly to multi-thread
| and multi-process scale for a long time.
| kevingadd wrote:
| Reading a version number from shared memory is basically free,
| and you already had the "thundering herd" before this fix, the
| herd was just issuing tons of RPCs to get the latest cookie,
| and now they will be checking the version in shm and then
| early-out skipping the RPC operation because the cookie hasn't
| changed.
| simscitizen wrote:
| Not sure there is much of a herd, because document.cookie is
| only shared amongst same-site renderer processes.
| Groxx wrote:
| > _We were astonished to discover that 87% of cookie accesses
| were redundant..._
|
| er. really? it has no "it has been updated" event, polling it
| even when unnecessary is kinda the only option. honestly I'm
| surprised it's _only_ 87%, I would 've bet it was much closer to
| 99%. tbh it makes me wonder if there's some incorrect caching
| going on in some popular frameworks.
|
| > _... and that, in some cases, this could happen hundreds of
| times per second._
|
| ignoring intentional stuff like cross-tab communication via
| cookies (there are much better options nowadays, but not all code
| has switched), yeah - also not all that surprising, but
| definitely one of those "... but why?" discoveries.
| rob74 wrote:
| ... and now that they made it faster, the authors of popular
| frameworks can get away with even worse mistakes. Hooray for
| progress!
| kevingadd wrote:
| Between "this framework was requesting cookie data too often"
| and "this framework was incorrectly caching cookies and
| causing weird data inconsistency errors that frustrate users"
| the former is probably better, and they fixed that. The
| latter is something that isn't straightforward to fix without
| introducing the former issue.
| Groxx wrote:
| 100% agreed, I would much rather have things just hammer
| the browser and be trivially correct. Far easier to debug
| and layer in a cache if needed when you know your specific
| case, rather than trying to debug a flawed cache.
| tedd4u wrote:
| "we ... determined that it ... improved the slowest interactions
| by approximately 5% ... result[ing] in more websites passing Core
| Web Vitals"
|
| Thanks, Google.
| JackYoustra wrote:
| not even just that! "Combined with other changes" like ???
| camtarn wrote:
| The article doesn't mention why versioning was used instead of
| just storing the cookie string in shared memory. Something about
| atomicity, perhaps? i.e. you can't guarantee that a string is
| updated atomically without synchronisation, so synchronisation
| would be needed, which could cause blocking or cause requests to
| queue; whereas a simple version number can be written and read
| atomically?
| saagarjha wrote:
| Maybe because cookies can be of arbitrary size and you don't
| want to keep them around all the time?
| scottlamb wrote:
| > This is why we've been focused on identifying and fixing slow
| interactions from Chrome users' field data, which is the
| authoritative source when it comes to real user experiences. We
| gather this field data by recording anonymized Perfetto traces on
| Chrome Canary, and report them using a privacy-preserving filter.
|
| This is a great example of the positive value to the user of this
| kind of telemetry. Of course this doesn't mean people aren't also
| right to fear it's used in ways that aren't in their best
| interest. No clear moral here, just a data point.
| csande17 wrote:
| Couldn't this particular issue have been discovered just as
| easily by visiting a bunch of websites in a lab, rather than
| collecting website performance data from end users?
| scottlamb wrote:
| Sure, but there's always the question of how realistic your
| test is in terms of websites you choose, the way you use
| them, your hardware setup, etc. I think their "Chrome users'
| field data ... is the authoritative source when it comes to
| real user experiences" is totally valid.
___________________________________________________________________
(page generated 2024-06-03 23:01 UTC)