We've had a couple of long term customers get in touch with us recently with regard to performance issues (or, more specifically, database deadlocks caused by their SQL server installation of the SCORM Engine).  In each case, these were folks running long since superceded versions of the SCORM Engine (2006.1, 2007.1), but we still have a couple of paths forward in those cases. 

Ideally, folks in this situation will quickly upgrade to the current version of the SCORM Engine (2008.1 at this writing, 2009.1 before too much longer.)  Moving to the current version can have a profound impact. 

Short term possibilities include:

• Using an alternate "DatabasePersistanceEngine".  Under the right set of circumstances, the sqlserver-not_optimized engine can handle high loads better than the sqlserver engine.  Yes, it's ironic.  No, we aren't going to change the names and confuse you further, for now.  If this is a thought for you, ask us.  We'd like to talk through it.
• Tweak your settings for Commit Frequency (a SCORM package property) and potentially Maximum Failed Attempts.  These settings combine to affect the regularity with which the browser is pushing data down to the server.  They have a direct and immediate affect on the server load.  Increases in Commit Frequency have to be considered carefully.  By increasing this number, you are essentially exposing your learners to greater periods of work loss.
  

Put simply, the amount of potential data loss for a learner is (Maximum Failed Attempts) * (Commit Frequency).  At this threshold, your learner would be notified that data loss is occurring.  We often deliver the SCORM Engine with really conservative defaults (2, 10000).  This means the total exposure is 20 seconds, a very comfortable level. 

Were I creating my own LMS and having to balance issues of server load against data loss for a learner, I would probably come out somewhere around (3, 80000).  This would make the maxium exposure 4 minutes, an occurance which would be unlikely.  And it would have a profound on the server requirements. 

As always, feel free to post questions here.  Package properties can be controlled in many ways.  Specifically, they can be affected at a code level through defaults, a database level, and even via the SCORM Package Properties controls.