BrowserMetrics

Alexandra-R (and Edge team devs):

Other things of note that I've recently noticed (or heard from others):

To recap this entire discussion, it seems there are two (separate but related) issues that need to be fixed:

1. Edge is keeping more than one BrowserMetrics file around, and for far too long
   1. As I understand it, having more than one file in the BrowserMetrics directory is designed to only ever be a short-term (i.e. 30-60 minutes max) occurrence
2. For some combination of builds/users/conditions, Edge is creating these new files at a very high rate (6-300 files / hour).
   1. Even if the previous issue is corrected, this one is arguably more important and will have more impact on the overall UX of Edge.
   2. Whether or not they are full of data, that can result in a ton of small disk accesses.
      1. Pity those unfortunate students using low-end laptops* with spinning HDDs!
         1. Memory-mapped files like this sometimes get written to very often, since the data is saved in very tiny chunks.
         2. Based on some of the reports from above, one can imagine the poor little hard drive heads bouncing back-and-forth nearly constantly, impacting system responsiveness and the user's overall opinion of Edge
            1. An average laptop HDD may only get 60 operations, likely fewer, each second, for the entire operating system and all applications
            2. The fastest server HDDs still only allow a maximum of about 200 operations / second
         3. As I have previously mentioned (ok, mildly ranted), each new file can drive activity from filesystem, antivirus/Defender, Windows Auditing, disk indexing, and potentially other processes. To the extent that most of these are reads, their biggest negative impact relates to HDDs.
         4. * some customers may even have Windows Virtual Desktop instances backed by HDDs, driven by inertia or Azure budgets
      2. This causes unnecessary wear on consumer SSDs as well.
         1. The primary concern here is with the frequent small disk writes; read cost / wear is fairly insignificant
         2. (I believe Chromium on Android turns this feature off altogether, choosing instead to just keep the data in RAM until it needs to be uploaded.)

Thank you for all the attention you and your team are giving to this! 

Happy hunting,

  - Jim

Detail [1] from item (3) in above list:

Detail [2] from item (5) in above list:

Beta - Version 90.0.818.22 (Official build) beta (64-bit)

  --> Normal (working) process, that prevents build-up of "BrowserMetrics-hhhhhhhh-hhhhh.pma" files:

  CreateFile                                              Desired Access: Generic Read/Write, Disposition: OpenIf, 
                                                            Options: Synchronous IO Non-Alert, Non-Directory File, 
                                                            Attributes: n/a, ShareMode: Read, Write, Delete, 
                                                            AllocationSize: 0, OpenResult: Created
  CreateFileMapping                                       SyncType: SyncTypeCreateSection, 
                                                            PageProtection: PAGE_EXECUTE_READWRITE
                    Result: FILE LOCKED WITH WRITERS
  QueryStandardInformationFile                            AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, 
                                                            DeletePending: False, Directory: False
  SetEndOfFileInformationFile                             EndOfFile: 4,194,304
  CreateFileMapping                                       SyncType: SyncTypeOther
  ReadFile                                                Offset: 0, Length: 32,768, I/O Flags: Non-cached, Paging I/O, 
                                                            Synchronous Paging I/O, Priority: Normal
	...
  CreateFile                    IRP_MJ_CREATE
  QueryAttributeTagFile         IRP_MJ_QUERY_INFORMATION  Type: QueryAttributeTagFile, Attributes: AC, ReparseTag: 0x0
  SetDispositionInformationEx   IRP_MJ_SET_INFORMATION    FILE_DISPOSITION_DELETE, FILE_DISPOSITION_POSIX_SEMANTICS, 
                                                            FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK
                                IRP_MJ_CLEANUP
  CloseFile                     IRP_MJ_CLOSE

lexcyn (and dave260) Have you tried turning on automatic compression for the BrowserMetrics folder, as I detailed above? (If so, do you have anything notable to report?)

Anyone else?

(I haven’t personally seen any ill effects yet from enabling automatic compression.)

PSA: if you can fulfill the data request from Alexandra-R, please do that first! The sooner the team gets data the sooner they can figure this out.

 - Jim

----

Aside: With the explosion (in both usage and number) of plain-text configuration, log, and analytics files in recent years, I wonder if NTFS compression should be used by default in many more places...

[Even with medium-speed SSDs, accessing a compressed file might be faster (fewer IOPS as well), let alone for those poor souls still using HDDs for their boot disk.

I’m not well-versed to know for sure, but memory-mapping files that a program needs extensive access to may contribute to the current disk performance challenges across various ‘modern’ operating systems (in theory and benchmarking, maybe this shouldn’t be a problem due to something like ‘intelligent caching’ in disk and VM systems, but in real-world multi-threaded multi-tasking usage, might not even the most ‘intelligent’ cache prediction system fail to determine user intent in order to optimize performance?).

It shouldn’t be that surprising that browsers such as Chromium-based Edge, in some ways nearly mini-OSs themselves, might end up being a canary for this sort of systemic issue. They are very complex and usage can vary widely by user and time - this isn’t just ‘winword.exe accessing hugereport.doc’ anymore!]

... and all that is aside from the performance impacts of having thousands or more files per process - each one places load on systems and filesystems upon reading (e.g. for each and every file opened, even read-only: verifying access rights, recording ‘atime’ access time, and performing other security/audit logging), writing (most of those same activites, plus updating modification times and file system journals, and perhaps SSD ‘write amplification’), and for purposes of indexing, backup, and security (Windows Defender Real-Time Protection). Many are likely to be left behind when new builds are installed. Sure, some of those things can be disabled on a per-file, directory, or process basis, but... without giving admin rights to the application?

Even if developers of most programs know how to do this, even if allowed to by system security and domain group policy, why would they remember to do this on every release? If using a cross-platform framework, they may not even _be aware_ of these issues, or have an API to address them.

Yes, I'm up to 14 GB since 3/20/21; almost 3 GB/day. Some of you seem to be having much higher usage by Browser Metrics. I'm hoping for progress by the Microsoft Edge team soon!

EDIT:

This does NOT work.

    (It shouldn't hurt anything, but my post below for the explanation of why it won't help for any files created after you turn on compression.)

This still might: (Potential alternate kludgy fix in post further below)

(original post follows):

-----

Okay, so this may end horribly, but I just turned on NTFS compression for the BrowserMetrics folder.

Actual disk usage is now 0.62% of what it was.

(New files are created about every 10 minutes, and so far it appears they are being properly compressed.)

Even if this works, it's still a kludge. This is not tested; buyer beware.

Vovan / Edge team:

The site (pomotodo) that you mention uses something called 'web workers' (the Chromium 'Blink' rendering engine apparently calls them 'Blink Workers').

In my (very limited) understanding, this causes a piece of JavaScript to run on a different thread than the one controlling the display of the page to which it belongs, allowing it to run on a different actual (or virtual) CPU.

If each of these new threads (as many as one or more every time you switch pages?) causes Edge to create a new file in BrowserMetrics (whether intentionally or not), maybe they are crashing or quitting before it can clean up the excess files.

Metrics files from different files are supposed to be automatically collected into a single file, but perhaps that part of the code (e.g. subprocess_metrics_provider.cc, or something that calls / is called by a function or method there or elsewhere) is malfunctioning.

Many (most?) sites these days use 'web workers', but the inconsistent (across the Edge user base) nature of this problem suggests that if they are indeed part of what causes this, something in the JavaScript on certain sites is triggering this (the browser should behave even in the presence of horrible / buggy JavaScript, of course).

- Jim

This has become an issue again, which seemed initially to be solved, Yesterday admittedly after having an Edge session with multiple tabs probably open for most of the week the Browser Metrics folder had ballooned to 179GB, currently with 2 tabs open it's generating 20 4MB files a minute so 4.8GB an hour so I now have 32Hrs 30 minutes of disk space until Edge fills my OS SSD again.

I've already added the reg key described and set to 0 and confirmed that this has applied in edge://policy. I can't find a root cause for this but unless I'm able to pretty soon I'll just have to go back to chrome.