Katie Capps Parlante wrote: > 1) A set of use cases and target times that represent "acceptable" > performance for our 0.7 target user. This means being clear about our > target user and the set of 0.7 use cases. It means identifying a target > data size (target calendar size, target # of tasks, that sort of thing.) > I don't think we're quite ready to do that, as Sheila mentioned, but > we're close and should put this on the list of things we need from design.
I believe our 3000 event calendar is good for calendar data still. But we should think about adding reasonable RSS and email data packs to the picture. In real use cases both of these will dwarf calendar data for many people (thousands, or even hundreds of thousands of email messages and RSS items might be in the same ballpark). > - New event creation (file menu) and (in place) could become one test > for both empty repository and 3000 item calendar I am not sure what you mean. It is also not possible to run a test for empty and filled repository at the same time (its possible to run the same script, but Chandler would need to be started separately with empty and filled repositories). > - Cut the test that creates a new calendar on empty repository Ok. > We could also proceed with adding a test or two that exercises a bigger > repository, some 10,000 item test. I'm not sure that a 10,000 item > calendar test is appropriate, though. Perhaps we could add the email > test that Andi wrote (or a variant), or revive the old RSS test. There is a limit to what we can run continuously on Tboxes simply because I think the test cycle should be fast. Ideally I'd like to see the cycle complete in an hour (we are about there now). In the most extreme case perhaps as slow as 6 hours would work, but we'd need more support in the graphing stuff and perhaps automated notifications for perf regressions as well for cycles that slow (because it would be unreasonable to have anyone wait that long for the results). -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
