Still slogging through this flu.
Today we have a conference call with AppLabs. They are the firm we've identified to help us create 'real load' against our Sakai QA environment. We don't have the capability to flog the Sakai deployment with enough boxes, with enough boxes, to produce realistic levels.
The Cloaking Device is in suitable shape for this testing. I've written about it a bit at the Sakai Confluence wiki, and in the internal Stanford Academic Computing wiki (ConSUL), so I'll hold off on describing deeply here. Shortly it is a set of Groovy scripts which manage 'fake' users in our Sakai databases. The UserDirectoryProvider (UDP) I wrote for Stanford, SKrbLDAP, gets two new configuration properties which tell it to use fake First and Last names for fake Ids, yet to use the real Id to resolve LDAP bio / affiliation information. This latter is needed to drive our Sakai User Type settings.
The AppLab testing will use these alternate Ids; up to 1500 of them. While it is true you can often stress test a system with just a few Ids I wanted to stress test the UDP's Caching. That requires Real Ids. I also want to see where we get into the bounds of needed an LDAP connection pool to the Stanford OpenLDAP installation.
I call these modified users "cloaked users." Their FN/LN comes from CourseWork Classic's PERSON table, just all mangled up - random selections of names are persisted into the Cloaking Device. The fake names persist to allow QA to build up test cases for re-use and automation. The fake Ids are randomly generated in a format outside of the Stanford SUnetID namespace.
I've gotten permission to provide the cloaked-user filled CM database tables to the Sakai Project. They could be used as a basis for load-testing CM, or for default deployments from standard check-outs. I suspect that there will be wrinkles around our EID formats, but those can be resolved.