[Deploying Sakai] Deployment sizing question

R.P. Aditya rpaditya at umich.edu
Wed May 13 17:48:17 PDT 2009

Hi Todd, 

[I'm keeping this thread on the production mailing list for posterity :-)]

On Wed, May 13, 2009 at 04:35:00PM -0400, Todd Williams wrote:
> R.P. Aditya wrote:
> >  http://tinyurl.com/ctstats
> Wow, thanks for sharing this.  I'm looking over the graphs now, and 
> there's a lot of info in there.  Curious though, I see a total of 1k to 
> 1.2k total users for yesterday and today.  Are you guys in summer 
> semester right now?  UF is currently in its summer term, so our user 

yes, we're in our "spring/summer" term -- if you click on the "Past month"
view you can see what we were at...(though our Fall term is usually the
heaviest, so you can click on "Past year" to see that...

> load is way down- ~400 concurrent users instead of the usual ~1000-1200 
> concurrent users we see during the fall/spring semesters.
> I completely appreciate over-specing the application tier and my 
> experience indicates that it's generally a good idea.  With webct we've 
> experienced periods of instability that required using cron jobs and 
> check scripts to detect down app servers and runaway java processes.

we have a script (run from Nagios but could be done in many different ways)
that tries to retrieve a text Sakai "resource" every 5 minutes (with a 30
second timeout) and then retries 4 more times every minute, and if that fails
restarts the Sakai JVM...

> So do you have webdav as a window into your binary file storage?  In 

We allow webdav to Sakai resources, yes.

> conjunction with that question, do you keep binary files in your 
> database or do you have a separate file server for binary objects?

we keep them on the filesystem -- in fact on the same fileserver (via NFS on a
Netapp) as the Oracle db.

> Coming from webct we're accustomed to having everything, including 
> binary objects, in the Oracle database.  The upside of this is that all 
> of our data for the application is caught in our Oracle incremental 
> backup regime.  The downside is that our database is pretty large- 
> currently ~3.5 TB.  I'm interested if you folks have a strong preference 
> one way or another on this issue?

yes, we moved from having it in the db to having it on the filesystem -- we do
full backups twice a week, so that was too slow when having the binaries in
the db -- also we now use snapmirror to replicate our Sakai resources to our
secondary site (for disaster recovery) every 10 minutes.

There are a couple of threads on the Sakai production and devel mailing lists
about this -- see:


for example.

> >>Has anyone implemented Oracle RAC in support of their Sakai system?
> >
> >we tried it in our development environment and determined it was more 
> >complex
> >than we wanted and it didn't buy us enough (we couldn't figure out 
> >transparent
> >jdbc failover with the oracle thin client)
> >
> Curious, what jdbc driver were you using?  Also, we're furiously having 
> the same debate about what RAC buys us.

the Oracle 10g thin jdbc driver

> >>Has Oracle 11g been successfully implemented as the backend for Sakai?
> >
> >we have successfully run our load-test environment against 11g and are
> >planning to upgrade to it in production this calendar year
> >
> Great, that's good to know.  What are the specs on your production DB 
> server?

currently a Sun T2000 with 16GB or RAM, moving to a T5140 with 64GB of RAM


More information about the production mailing list