4 ms·
Shared Memory Versioning to improve slow interactions
- liuliu 2y agoThis 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 2y agoThey 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 2y agoYou 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 2y agoThey 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.
- OlivierLi 2y agoRight now it’s falling back on a mojo IPC. Next step is indeed shared memory mutex :)
- OlivierLi 2y agoHey, one of the authors here. That’s pretty much it. That said I’m currently working in the next iteration of this which would indeed share more. That said for now it’s not super trivial because it needs a cross-platform condition variable like abstraction that works across shared memory. The pthread based one is not that bad and I’m hacking on it.
- chaboud 2y agoYeah. 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.
- OlivierLi 2y agoThis is interesting stuff. I’m one of the author of the change and working on the next iteration. If you have an example of what you describe I’d love to have a look!
- kevingadd 2y agoReading 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.
- OlivierLi 2y agoYep that’s pretty much it. There’s no pushing of the version from the privileged process to the renderer, only pulling. So there’s not many renderers unblocking at the same time to create any kind of herd.
- simscitizen 2y agoNot sure there is much of a herd, because document.cookie is only shared amongst same-site renderer processes.
- Groxx 2y ago>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 2y ago... and now that they made it faster, the authors of popular frameworks can get away with even worse mistakes. Hooray for progress!
- kevingadd 2y agoBetween "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 2y ago100% 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 2y ago"we … determined that it … improved the slowest interactions by approximately 5% … result[ing] in more websites passing Core Web Vitals" Thanks, Google.
- JackYoustra 2y agonot even just that! "Combined with other changes" like ???
- camtarn 2y agoThe 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 2y agoMaybe because cookies can be of arbitrary size and you don’t want to keep them around all the time?
- gary_0 2y agoProbably security, too: cookie data is security-critical, since you can use it for session hijacking, etc. The version doesn't leak anything about the cookie's contents so it can be directly accessed without any security checks. The whole point of isolating the process running each website from other browser resources (like cookies) is an added layer of security.
- deleted 2y ago[deleted]
- scottlamb 2y ago> 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 2y agoCouldn'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 2y agoSure, 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.
- eviks 2y agoThere are always questions, like whether your telemetry is measuring things correctly or not introducing more slowdowns, so it's not that authoritative So this isn't a great example because you can indeed see that many requests are redundant and are frequent by visiting a few sites: these facts don't depend on any hardware etc.
- orf 2y agoThey might well depend on available hardware, given the specific nature of the problem (multiple processes and the level of concurrency within). Ultimately the source of truth is actual end-user performance. If you’re not measuring that directly, then you’re hoping what you’re doing is a proxy for end-user performance. Sometimes a suitable proxy is available. Often, it’s not.