It would be interesting to find out what mysterious bug or
configuration problem is causing this "Heidelberg's dotLRN runs
pathetically slowly even when only one user is requesting one page at
a time" problem.
But you may well be wasting your time. One, that problem is
reasonably likely to be peculiar to your particular installation on
that particular Sun box. Two, even if you fix the problem, and
especially given that you're running a bunch of other software on the
same low-end Sun box, that box is likely to still be far too wimpy to
handle the loads you expect.
So why don't you just buy a dual Opteron or dual Xeon Linux box with 4
to 8 GB of RAM and a bunch of fast RAID disks, set that up, and do
whatever further debugging and tuning you need to there? Maybe the
mysterious performance problem will not reappear, which would be a
nice bonus. If it does reappear on the new machine, that also would
tell you something and might help your debugging. But the main point
is that the few anecdotal reports we have from current high-volume
dotLRN users seem to say that your current shared Sun box is unlikely
to meet your needs, and that you're going to need a new machine
anyway.
Of course, I suspect Mike and Janine know that, so what's the deal?
No money in the hardware budget currently to buy a Linux box? Do you
really think that shared Sun 280R will meet your client's needs? Or
what?
Time constraints? Getting a new machine up and running going to take
quite some time, of course. (Even longer if the customer has
bureaucratic purchasing rules.) But Furfly already has various other
Oracle installations up and working, right? So how about setting up a
Heidelberg Dev site on an entirely different machine, using known-good
hardware and a known-good Oracle instance? If the mysterious problem
re-appears there as well, then you know with about 99% certainty that
it's not the hardware or Oracle, that the mysterious problem has
got to be in your site OpenACS, dotLRN, or AOLserver code or
configuration.
