On Wed, Dec 10, 2008 at 9:31 PM, Donald Anderson <[EMAIL PROTECTED]> wrote: > If we think the wire size is comparable to zip compressed size, I guess we > could do that.
Yes, I think that is a reasonable assumption. SWF files are already gzip compressed as part of the file format. And if you gzip a DHTML file, that is the same compression as the web servers would be using. > > On Dec 10, 2008, at 7:10 PM, P T Withington wrote: > > Can you remind me why we have to actually fetch the applications via the > server, vs. just lzc-ing them (possibly zipping them) and then comparing > their size? > > On 2008-12-10, at 16:16EST, Donald Anderson wrote: > > Change 20081210-dda-Q by [EMAIL PROTECTED] on 2008-12-10 15:00:18 EST > > in /Users/dda/laszlo/src/svn/openlaszlo/trunk-h > > for http://svn.openlaszlo.org/openlaszlo/trunk > > Summary: Force megatest to fail if application sizes changes by more than a > configurable amount > > New Features: > > Bugs Fixed: LPP-6892 (Generated File Sizes baseline complete; Performance > Tuning ongoing) > > Technical Reviewer: ptw (pending) > > QA Reviewer: (pending) > > Doc Reviewer: (pending) > > Documentation: > > Release Notes: > > Details: > > Enhanced the 'Netsize' program that calculates the size of urls retrieved > and > > compares this to a previously stored version. Now, if the percentage > change is > > out of the acceptable bounds, the program will report a failure. > > This program is run by doing 'ant appsize' at the top level. > > It is also triggered by a run of megatest. > > Two values can be set, and are preconfigured in the top level build.xml: > > -- an overall acceptable size change percentage, currently set at 5% > > -- a default size change percentage enforced per url and per > application, currently set at 20% > > An 'application' is defined by this program as a set of URLs listed and > grouped by name > > in the input configuration file (test/appsize/appsize-input.txt). > > The change percentage is based on the byte count values previously > recorded, > > also in the same input file. > > Each run of 'ant appsize' produces a file test/appsize/appsize-output.txt > that represents > > a new baseline and can be used as a new input file (appsize-output.txt is > NOT in svn). > > It is expected that at each release (or when appsize begins to fail > regularly > > for a good, known reason), appsize-output.txt can be committed to > appsize-input.txt > > to thereby reset the baseline. > > There is general information in test/appsize/readme.txt (which has also > been updated). > > That file is referenced by the build.xml comments. > > NOTE!! this change includes a reversion of test/appsize/appsize-input.txt > to a previous state > > r11108 | dda | 2008-09-19 14:43:42 -0400 (Fri, 19 Sep 2008) > > Using the latest version of this file makes it appear (to me) that the > application has reduced substantially > > in size, and that is certainly not the case. I suspect that later > versions were generated > > by running against a server that does not have compression turned on? > This does mean > > that megatest will fail until the server is fixed. > > Notes for configurating compression are in test/appsize/readme.txt > > Tests: > > ant megatest > > changed values in test/appsize/appsize-input.txt to simulate failures > > nightly build (pending) > > !!!! This will FAIL until compression is turned on for the build server. > See NOTE above. > > Files: > > M test/appsize/appsize-input.txt > > M test/appsize/readme.txt > > M WEB-INF/lps/server/src/org/openlaszlo/test/netsize/UrlSizer.java > > M WEB-INF/lps/server/src/org/openlaszlo/test/netsize/TotalSizer.java > > M WEB-INF/lps/server/src/org/openlaszlo/test/netsize/Netsize.java > > A > WEB-INF/lps/server/src/org/openlaszlo/test/netsize/SizeProperties.java > > M WEB-INF/lps/server/src/org/openlaszlo/test/netsize/Sizer.java > > M WEB-INF/lps/server/src/org/openlaszlo/test/netsize/AppSizer.java > > M build.xml > > Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081210-dda-Q.tar > > > > -- > > Don Anderson > > Java/C/C++, Berkeley DB, systems consultant > > voice: 617-306-2057 > > email: [EMAIL PROTECTED] > > www: http://www.ddanderson.com > > > > > > > > -- > Don Anderson > Java/C/C++, Berkeley DB, systems consultant > > voice: 617-306-2057 > email: [EMAIL PROTECTED] > www: http://www.ddanderson.com > > > > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
