• Brian did some preliminary stuff in Perl, but it would be better to re-use stuff in Chandler
• Someone would need to pull out that code from Chandler
• Ideally we'd use jmeter (it is open source) since it has a means to manage testing distrubted across multiple clients, but could be too much trouble to write the WebDAV and CalDAV extensions
• Another problem: we don't know typical load that Cosmo will encounter so what are our performance goals?
• We need a statement of goals, then it would be eaiser
• What does the average user look like, how often do they sync, etc.
• How often are people sharing with chandler as opposed to scooby as opposed to other clients (they all can behave very differently (eg. Scooby would be chattier than Chandler since Scooby doesn't have its own local storage)
• Another part of story getting todd to simulate firefox usage --Lisa
• Chandler is using this assumptuon - have a 3000 event/user goal. Start testing with 500, 1000, etc. to work up to goal
• Lisa proposes an initial goal would be 10,000 users with an average of 1000 events each
• Jared says important to test for peak performance
• if we do an invitation type registration system (ala gmail) what is that boundary?
• FYI - 20 simulated users going as fast as possible ~~ 200 real users
• Bear will take over mem testing framework, will investigate load testing, what tinderbox stuff he knows
• bcm can take over mem profiling

Cosmo

• bcm has been running on a memory profiler
• Heaps size after 500 event import grows very little each time - there's about a 10k mem leak
• Not a big mem leak, but memory use during the is large 100 megs for inserting a 500 event calendar
• One thing to help is to get rid of sessions being created for CalDAV users
  • probably won't help too much mem wise though
  • but makes security config simpler
• Cyrus committed some initial support for CalDav^? queries
• Brian looking into the way Jackrabbit stores stuff
  • 500 events takes up 200,000 files
  • wow! That's way too much
• Trying to quantify variables to measure
• question: how many files does a single calendar take?

Scooby

• Schedule some time for overlay, searching, tix UI
• lisa to read through, review specs
• mimi forwarded thread on Design about alternate ways to display calendar data
  • mimi -- how experimental do we want to be?
  • lisa -- depends on how much work into design
  • matt -- how much should scooby be chandlesqye so people don't get lost
  • mimi -- but now is the time to innovate before people get stuck into 1.0
  • So Bobby will schedule a general scooby GUI meeting, with a ~1/2 hour in the front for experimentation
• Matt - working on async stuff, making things more responsive, and memory leaks
• Bobby on mem leaks as well in the client side