by Rusty Meyners.
Original (or at least previous) publish date: Wednesday, 12 May 2010, 11:47 AM
Here's what didn't work and did work for us when testing the entire Freshman class of around 90 students simultaneously on netbooks with wireless connections.
Server install DID NOT work – obviously and decidedly so.
- It seemed the most natural way to do things and bandwidth considerations seemed to be the only issue flagged in the Pearson documentation. We had tested groups of class size or smaller in the past with barely tolerable results, usually not seeming to be related to bandwidth. Testing 90 simultaneously crapped out after less than 2 dozen connections. In this case we were using netbooks on wireless connections but no change in perfomance was noted on several that were plugged into ethernet. Best guess is that the program files did not play well when in use by so many users – NOT A GUESS is that critical files were easily broken in this scenario and re-install was the so-called "fix".
Proctor Caching DID work – apparently.
- We have no observation of how things would have performed without this but none of the problems we had indicated a problem with caching, particularly considering good performance after changes were made only to components other than this.
Local install DID work – WITH A TWIST
- After it appeared that a local install was the solution (the Pearson documenation DID NOT give any indication to this effect but phone support did) we successfully circumvented the need to perform a full install on each machine by merely copying the folder from the server installation to each local desktop (NOT an idea we got from phone support). It may be possible to to the same thing with a local install folder but be sure the proctor caching settings are correct and if necessary edit the configuration file for that purpose. No critical .ini files were broken on 90 local instances.
Some tips on this:
- Zip the folder and copy it by USB to the local desktop where it is then unzipped in a separate action and ready for use. It could be copied directly from network but might result in an annoying bottleneck. Attempting to unzip directly from the network share will probably aggravate the bottleneck and uzipping from the USB stick will also be slower than performing the separate actions. This makes a difference when prepping more than a class-sized group.
- If possible, set relevant temp-file paths (different on server vs. local installs) when performing the original install that you are going to copy. Not critical, because we performed an adjustment to each local computer and it wasn't horrendous (compared to running from server the previous day) but could be avoided. The correction is requested after logging in: just click Browse and the default path is normally suitable but if it doesn't work, just click "Skip Upload" (assuming student has no work to save yet).
- On our netbooks, there were two suitable resolution settings, changed by hot-key, however making this change after the test starts will trip the cheat-detector and require the test to be restarted. So try to confirm a correct resolution before hand.
- Because our netbooks are on full-time assignment to students, a special domain login was implemented to ensure a clean profile with less chance of junkware interference.
(Will put updates or link to them here
Now that this reminds me NOT to do network install (hard to believe I'd forgotten THAT), here are some things that immediately come to mind.
Will probably script the copying AND unzipping of files involved in "Local Install" as described above in #3 (WITH A TWIST).
- have recently used scripting for similar delivery from network shares with encouraging results
- 7z zip utility (free) has proven very efficient and effective for this and works well with scripting
After optimizing scripting and zip procedures, will likely retest these from network shares as well as USB or SD card delivery, to evaluate which is/are preferable.