Closed Bug 522807 Opened 11 years ago Closed 6 years ago
Create new Talos suite: cold ts for windows
see bug 510587. mac and linux are done, but we haven't found a way to reliably emulate a cold startup on windows.
notes from vlad, via adw at https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements_Notes: First, if you're on Vista/7, you need to delete the preload cache data. In your windows dir, ... argh, can't find it atm, but there's a precache or preload or something, and there should be a firefox.exe-like dir inside it that you need to delete. Otherwise vista/7 will start doing its app preload acceleration stuff which will screw over the data you're trying to collect. Then, grab something like flushmem: http://aegisknight.org/2009/04/flushing-disk-cache/ There's another tool that's more flexible and might be faster, but that one should get the job done. Then run the app. Gotta do these steps before each start to simulate cold start. - Vlad
much more from adw here: http://tinyurl.com/yk7hf3p
i don't think we need to achieve perfect cold startup emulation. if we can get reliably mostly-cold startup wrt to absolute startup time, that's probably fine.
Do we have a proof of concept anywhere that this works? Releng won't do integration till we have evidence that things will function.
see comment #0.
11 years ago
Summary: need a cold ts for windows → Create new Talos suite: cold ts for windows
consume.exe, a utility in the Windows Server 2003 Resource Kit, might help out here. it can pressure physical memory, cpu, page file, for a user-specified amount of seconds. running just the physical memory option for 5 seconds before timing startup had a massive affect on startup time. i'll play with the options to see if i can get something that puts as at the same level as post-boot startup.
some notes from testing consume.exe on windows 7: using "consume.exe -time 15 -physical-memory" before startup, i can reliably cause firefox to startup in 21-23 seconds. very few times was it outside of that range. the only point at which it was higher was when i switched between different versions of the up. eg, after testing a few startups of 3.5, then testing 3.6. those startups were in the 45 - 50 second range. (i got to 15s by starting from 5s and increasing the number until i hit the ceiling of startup time (so basically it takes 15s for consume.exe to fill my physical ram up to 100%). i did about 3 runs of each version, and the startup times across 3.5, 3.6 and 3.7 did not noticeably differ when testing this way. interestingly, "consume.exe -time 15 -kernel-pool" reliably started up the app in ~7s. the other options did not have a noticeable effect. note that prefetching is turned *off* for the duration: * disabling prefetch on winxp: http://www.tweakxp.com/article37028.aspx * disabling superfetch on vista/win7: http://www.addictivetips.com/windows-tips/disable-windows-7-superfetch/
link to the w2k3 server resource kit for consume.exe: https://developer.mozilla.org/en/QA/Stress_Testing
wip. currently freezing whole OS unrecoverably. yay. sequence works outside of talos, so the problem is probably a mispythonunciation on my part.
Assignee: nobody → dietrich
Status: NEW → ASSIGNED
Alice, the attached patch works in my environment. I tested consume.exe standalone (ie: outside of all the other resource kit files) and it works fine. Just needs to be put somewhere in the path of Talos.
Dietrich, does this require the registry changes mentioned in previous comments? Is this just a standalone script that talos can run? Also, has there been any testing done on vista?
Per Taras' post, mounting a drive containing Firefox might be a better approach: http://blog.mozilla.com/tglek/2010/01/04/windows-7-startup-exploration/ I'm going to look into whether drives mounted via subst are treated the same, with respect to caching, etc: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/subst.mspx?mfr=true
Moving to Talos component.
Component: General → Talos
Given horrible windows startup issue(bug 593614) that we only noticed recently, measuring cold startup should be given a high priority. We need to setup a windows box that reboots and then launches firefox soon after startup. I'd also like to have windows capture an xperf log while doing that. logman start "NT Kernel Logger" -o browser.etl -p "Windows Kernel Trace" 0x237f start firefox logman stop "NT Kernel Logger" -ets I'm not sure if it's viable to reboot windows on every commit. It would be good enough have a cold startup test box cycling nightly.
Priority: -- → P1
Talos boxes are rebooted after every test run.
Usage siggi.exe d:\ l: "powershell startup_script.ps1" Where d:\ is the drive that that firefox binaries are on, l: is the new virtual drive that will be assigned to the snapshot drive and the last argument is the command to run. This uses the windows backup service to create a brand new view of the harddrive which means that existing windows caches wont be used =D
Attachment #411865 - Attachment is obsolete: true
powershell script to time startup
The upside of this approach is that this gets us the same effect as unmount/mount on unix-like systems(ie application binaries are not in OS caches). The downside is that firefox has to be run as administrator due to windows UAC sucking and not being able to drop privileges.
Which versions of windows will this patch work on? Do we need to have a d drive set up for this to work?
(In reply to comment #21) > Which versions of windows will this patch work on? > > Do we need to have a d drive set up for this to work? works on xp and vista + newer, just has to recompiled separately for xp or vista+newer.
Is this still wanted? We do a reboot before running the test. I would like to get some action items here or close the bug.
(In reply to Joel Maher (:jmaher) from comment #23) > Is this still wanted? We do a reboot before running the test. I would like > to get some action items here or close the bug. This would be nice to have but for now I think our time is better spent on moving bug 770317 to a useful stage.
Roberto- is this the same as you have?
Joel, I didn't understand the question.
Roberto, I was not very clear! Should this be a duplicate of bug 936617?
Yes, this is a duplicate.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 936617
You need to log in before you can comment on or make changes to this bug.