I have a bunch of ideas but I haven’t implemented any yet because dreamhost keeps claiming I have unlimited storage and I want to test them on that
You can do some housekeeping that deletes files that are no longer needed or cache files:
Depending on what version you started out with, you may have a bunch of old images stored that are no longer needed. Older versions used to generate the waterfall and optimization checklist when the tests were run and the images were stored. They are generated dynamically now in code so you can delete all of them (I think it’s *waterfall.png and *optimization.png but it’s been a while so I could be wrong).
The code also caches thumbnails (.tbn) for the waterfall, screen shots, etc. You can delete them and they will be re-generated on-demand if anyone goes to look at the old test results.
From there you get into a mode of being lossy (without changes to the code anyway):
Do you need screen shots of all of the old tests? If not just go through and delete them all. Same goes for the raw headers and optimization report. The only things that are REALLY needed for the times, waterfalls and checklists are the testinfo ini file and the IEWTR.txt/IEWPG.txt files.
All of the tests are stored in a date-based directory structure (and completely self contained) under /results. The directory structure is in the form YY/MM/DD/Test ID so if you just want to nuke (or archive off) old tests you can just grab the tree from whatever point you want and do it manually. The only other place they are referenced is in the test history which is in the /logs directory (one file per day).
I’ve been considering a few things to enable archiving while keeping everything intact but haven’t implemented anything yet:
1 - I could support zipping up each test into a zip file and extracting it as needed. This will significantly reduce the space taken by the text files (some of which can be pretty big).
2 - I could support having an external archive server that tests would be pulled from dynamically if they aren’t found locally.
I’ll probably implement both at some point but it hasn’t been a pressing problem yet so it hasn’t made it’s way to the top of my list.