Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Don Quixote -
Number of replies: 31

Hi all,

I've read with much interest some scattered postings regarding this subject. That's why I would like to start a new thread about this.

  • What are the pros and cons?
  • What's the future? 

It would be great to hear the opinion of people in different positions (sys admins, teachers, administration officials, politicians, ... or whoever is involved in this subject). Personally I am currently trying to establish a concept which I believe could have some potential to solve certain disadvantages of both, centralization and decentralization.

A first draft of pros and cons from my part ready for being discussed:

ProsCons
Decentralication (one system per each department)...
  • more flexible and autonomous for special needs
  • less uniform (departmental identity)
  • higher non-technical quality for the student
  • technically "slim" (less performance issues (?), less dependent from a single infrastructure)
  • better integration into departmental infrastructure
  • lack of human resources in dept's
  • problem of the technically professional maintenance (technical quality)
  • integration in the overall (institution wide) infrastructure
  • more expensive (?)

In my opinion it is also interesting that for instance regarding the quality we have two opposite aspects:

  • the non-technical quality for the learner, teacher
  • the technical quality

I have a concept in mind where departments of the same field (in my case math departments - but I think it would be interesting in general) are sharing the infrastructure. Does it has the potential to resolve some of the pros and cons? Would it support collaboration between different departments in the same field? (e.g. collaborative creation of high quality learning content?)

One problem could be that sharing the infrastructure like this could in fact lead to an even more centralized (bigger) IT infrastructure. On the other hand, it could be managed and controlled by the community itself which could be attractive (in the case of the math departments for instance by national mathematical societies or the IMU etc...).

I am very curious about your opinions!

Cheers

Andreas

Average of ratings: -
In reply to Don Quixote

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Zbigniew Fiedorowicz -
Andreas,

My preference is for the departmental server approach rather than the institution-wide server approach. I think that similar departments at different institutions will have more in common with each other than with unrelated departments at their own institution. Also, especially with large institutions, I fear that a great deal of flexibility in customizing Moodle will be lost under the institution-wide server approach.

However the institution-wide approach is probably more convenient for students. To get the best of both approaches, there should be some way of crosslisting courses between different servers at the same institution. (I brought this up earlier: http://moodle.org/mod/forum/discuss.php?d=3194. Also another thought: is there some protocol in SCORM/IMS for moving such information between servers?)

Zig



Average of ratings: -
In reply to Zbigniew Fiedorowicz

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Françoise Blin -
I think it really depends on your institution. In ours, a lot of our courses are multidisciplinary and can be administered and delivered jointly not only by two different departments but also by two different faculties (and even more). If each of us had a separate server, I really think it would be totally unmanageable and really confusing for students who may feel that they belong to more than one sub-community within the institution. The support issue is also critical.

It is true that we may be loosing some flexibility, but this is where Moodle has attracted us: even though we have adopted a centralised approach, each course can have its own idendity. Okay, maybe not in terms of themes, but I don't think this really matters.

Also, one big advantage I see in centralisation, is the possibilities it offers for sharing experiences and ideas between different departments and faculties. In my case, I think I have more in common with a colleague from the School of Nursing who is into constructivist approaches to learning than with a colleague in my own department (Languages) who uses a paper-based grammar-translation approach to learning (just an example...).

Françoise
Average of ratings: -
In reply to Zbigniew Fiedorowicz

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Don Quixote -

Hi Zig, Françoise,

I tend to think that in some fields the departmental approach is more attractive. Although I see from what Françoise wrote, that it might not hold for all institutions in general.

On the other hand, mathematics is also a field with many interdisciplinary relations (who is not using math? wink ). I think Zig's earlier posting (http://moodle.org/mod/forum/discuss.php?d=3194) points out an important aspect in the case of a decentralized infrastructure. Maybe there should be two different types of student accounts in a moodle system: A student can have a unique "primary" or "master" account at the departmental server where he studies his primary branch and several "secondary" accounts on other moodle systems. (Only the primary account then contains the principal data to avoid redudancy).

This would also be desirable in the case of math departments running an own moodle, because I agree that a student should have a list of all courses he is enrolled, regardless at which department he has logged in.

I am not sure, if there are cases where a student couldn't be assign to a specific dept.!? But a centralized solution is already well supported by moodle, so this would be a case where Françoise' approach is the preferred one.

Also, I think that such a distributed system could be quite challenging from the development point of view. (I don't think that the maintenance and the administration would be the big problem. Once implemented this could be quite "transparent" for admin's, students, teachers, etc...).

I am not an expert of distributed systems. But I also prefer a more decentralized, "self organized" approach than big systems, which tend to be inflexible, "dull" (sorry maybe this isn't the right English expression) and  - at a certain point - can even become more expensive and more difficult to manage.

Average of ratings: -
In reply to Don Quixote

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Zbigniew Fiedorowicz -
I think the decentralized approach with course crosslisting could work along the following lines. One of the Moodle servers at the institution could be designated as having the responsibility of keeping track of student enrollments in Moodle courses across the entire institution.  Whenever a student logs into one of the department servers, that server inquires the central server for a listing of all courses that the student is enrolled in.  The department server then copies that information to the "My Courses" page that is served to the student, with appropriate links to other servers (and also certifying Moodle login authentication if the student clicks on such a link).  If the department server notices that the student is enrolled in some course within the server which is not in the central listing, it sends an update message to the central server with that information.
Average of ratings: -
In reply to Zbigniew Fiedorowicz

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Don Quixote -

I agree. This seems to be the most "natural" way and would simply mean to separate student data from course data. "Natural" in the sense that normally students belong to the whole institution and courses to a department.

Average of ratings: -
In reply to Zbigniew Fiedorowicz

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Zbigniew Fiedorowicz -
Let me just add that the solution outlined above presupposes some centralized authentication/identification scheme.  I don't think that any crosslisting of courses is possible under, e.g. email based authentication, since there would be no reliable way of determining whether user accounts on different servers belong to the same student.
Average of ratings: -
In reply to Zbigniew Fiedorowicz

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Don Quixote -

There could be a central "moodle institution server" who stores:

- student accounts (so that students are uniquely determined)

- department server accounts

Then decentralized department servers could be plugged into the institution server via these department server accounts.

I think this would solve many of the pros and cons.

Average of ratings: -
In reply to Don Quixote

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
Sounds like My WebCT smile

Ok, my solution here, a generic one, would be to run an institution wide
"portal". For us, it's my.wisc.edu. And I just happened to be the original
project manager for that one (I've since given it up to go back to this teaching and learing stuff). This would be an entirely separate deployment with loose
integration with the CMS (course management system). Unlike the CMS, the
portal looks at all of the functions of the university. Student services, Library,
Human Resources, just to name a few areas.

One does see in many popular CMS systems such as BlackBoard, WebCT, and Desire2Learn, they provide a "home page" for you as an individual. This is an overlap with the "portal", and one that I'd like to avoid. Of course one could do this with Moodle, but I'd like to explore with you all making this much more loosely coupled.

The portal we started with back in 1999 was Epicentric. It was ok and maybe even great. Also cost a fair amount in licensing. This year, by Fall 2005, we are going to switch to uPortal, which will save us the licensing costs (other costs of implementation remain), and get us in alignment with other peers (we were about the only place doing Epicentric).

We already have a model of linking to the "courses", whereever they are hosted, be it our blessed enterprise CMS or a departmental site or even a personal web page for the faculty. This is on the "Academic" tab of my.wisc.edu, and do take Annie Student for a test drive to see for yourself. The Academic tab is essentially the same as the My WebCT or My BB or My Moodle page. It's a launching point for these courses. With some XML magic (think Web Services), one could include time changing info like "there are 2 new assignments" on the list of courses in a portal.
It's a loosely coupled model.

Course, we'd have to solve the SSO (single signon) between the portal and the CMS.
The approach we'd like to move to is PubCookie, www.pubcookie.org
Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Michael Penney -
HI Dirk, have you seen the CAS (uportal) authentication module that  romuald lorthioir released? Discussed here: http://moodle.org/mod/forum/discuss.php?d=18179

I know there are implementations for CAS for Blackboard (Enterprise) in the CSU and I think there are some folks working on one for WebCT.
Average of ratings: -
In reply to Michael Penney

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
I am familiar with CAS, yes. This comes from our friends at Yale.
Has some following in the uPortal world.

At UW, we are currently more interested in PubCookie, www.pubcookie.org.
We are in the process of deploying it for many of our enterprise web apps.
Our uPortal implementation will use it in it's Fall 05 deployment.

In short how Pubcookie works is via,
an Apache/IIS AuthN plugin. Authenticates on each http
request as a web server "authentication method". Will set the REMOTE_USER environment var and some cookies. In Apache, it's just like a simple
config change to enable. Up to the underlying app to deal with the rest.
I'm thinking this is minutes to hours to setup for Moodle smile
Average of ratings: -
In reply to Don Quixote

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Zbigniew Fiedorowicz -
I don't think a centralized Moodle server would work very well at our institution, Ohio State University. We tend to be very bureaucratic. Here's how I fear that all but the simplest communications between a mathematics instructor and Moodle central server administrator would have to proceed:

instructor
  --> department chairman
  --> dean of mathematical-physical sciences
  --> executive dean of liberal arts and sciences
  --> vice president of information technology
  --> director of technology enhanced learning and research
  --> server administrator

I think there is little danger of Ohio State adopting Moodle as its official CMS. The office of information technology is pretty much committed to an expensive commercial solution (currently WebCT). [And the communications scenario outlined above is pretty much how things work with WebCT.]

However it is my hope that eventually other departments at Ohio State might become interested in using Moodle on their own servers, and having a possibility of crosslisting Moodle courses between servers would be an additional attraction. (I envision our mathematics server as playing the role of central server for crosslisting courses, at least initially, as outlined in my previous post.)

Average of ratings: -
In reply to Don Quixote

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
Here as University of Wisconsin-Madison, we already have the problem
of cross-listed courses. It's no easier to solve this with a single deployment.
Some one department has to be seen as the "owner". When we create the
course space, it needs to be associated with some particular department.
This came up pretty fast for us, in 1999, and has been with us ever since.
For grade reporting (which we have been doing for 3+ years), we have to
make sure these go back to the correct original "department".

I see this more as a "business process" issue, not a technology one.
The department's have to first figure it out.

Average of ratings: -
In reply to Don Quixote

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
I'm with you Andreas (about a year later). Having been involved with a number
of implementations at the "enterprise" level (WebCT and D2L), I see problems
there on scaling and permissions.

On the Pro side, I'd add
* easier to update, do a rolling update. We are having a heck of a time finding
a window for largish updates.
* possible to have different versions per dept.
some want to go faster on new features, others want to wait for a very stable
version.
* possible to add custom modules per dept.
some are willing to take more risk of new modules. this puts that risk
squarely with them who will benefit.
* scaling by adding more computers.
my model here is a generic "web hosting" one. put multiple depts on the same
commodity server.
* more robust.
any one "instance" going down should not affect other depts.
* Hosting by central IT or departments,
This could be done by central IT, for the depts without
sufficient IT resources. similar to how email gets done.
For those depts that have IT staff to pull off a dept server, they could do so.
* easier to upgrade to newer hardware.
since you have a fleet of servers, its easier to think about migrating to
newer hardware overtime. instead of one big purchase every 3-5 years,
do a lease and rotate some set of servers every year.
* delegated admin for the department
this tends to be hard on a single enterprise deployment, with lots of permissions
and inheritance. in this model it's easy and safe from a security perspective.
* easier to run multiple environments for dev, testing, QA, etc
instead of needing to replicate a large single system (which we do now)
for non-production envs, could do a simpler one at a dept level.
particularly useful for performance testing.


I'm not sure how the costs will play out. I'm thinking it costs the same and you
get better performance.
Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Sean McKay -
Here are some thoughts -- I haven't been following your entire thread, but we are running approx 1100 users, two sites on one box, one for official courses, and one for projects. The official course site authenticates our centralized authentication system and the project site uses self-registration.

This setup has worked very well for us (we presented on the use of Moodle at Site 2005). Having a centralized server works well from a support perspective (with about two 1/2 time FTE's to support it amidst other responsibilities).

I do have to say that Moodle has been troublefree at this point. I am very pleased with the flexibility, agility, and stability that it has provided to us so far.

One additional thought, it seems to me that having a single server would be advantageous in terms of staying on top of updates at both the OS level and at the Moodle level.

Now, having said all that, I'd like to experiment with something like the Xen virtualization monitor and load multiple Moodle instances under seperate virtualized machines. This would enable one to isolate the different instances of Moodle. I'd imagine that it would take a boatload of RAM. Maybe just running multiple Moodles on one Apache server would suffice. Following Dirk's post, I think that he makes a good point about how having multiple Moodles running would allow for bleeding edge departments to have more experimental modules loaded.

One more thought on the side of running a single centralized server is that the look and feel can be standardized for all of your students--which can be helpful in that you are not re-oriented students to a new CMS every time they take a different course.
Average of ratings: -
In reply to Sean McKay

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
Thanks everyone for humoring me on this thread. I do appreciate that there is an active community. I'm still learning about Moodle and all of this is enlightening.

If Sean (or others) could further enlighten me, I'm wondering about how updates are done to Moodle. Are these scripted? I have sometimes referred to this as a "patch technology". This is one of the requirements for a decentralized deployment.

I'm still contemplating this area and one of the possible next steps is to do
some performance analysis (on paper) and benchmarking (in the lab). This is something that I'm prepared to do locally (meaning I would find the budget). However, I'm wondering if someone has already gone THERE and done some formal performance analysis on Moodle?
Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Michael Penney -
Martin Langhoff and the folks at the NZVLE would be the ones to check with, as they have 30k on their cluster and IIRC scaling to 90k by the end of year.

If you can get a budget and if Martin's research is good enough for your needs, IMO it would be great to fund development of code that would enable the control of available blocks and mods at the course format level.

This would allow a 'simple' course for beginner teachers without all the scary stuff in the drop downs, more advanced courses for experienced teachers, and experimental or discipline specific courses with specialized modules, while providing the advantages of a centralized server or cluster.


Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Martín Langhoff -
Thanks Michael for the reference! A lot of the stuff Dirk has mentioned resonates with me (J-curves, etc), and was the drive behind my early benchmarking of Moodle, ATutor and Ilias3 as part of our in-depth review of the three. You can find it in the document's page of the NZVLE project http://nzvle.eduforge.org/

That document is somewhat dated and doesn't have that much detail on our benchmarking. It led to our adoption of Moodle, and we did a lot of performance work, specifically in the field of scalability and Postgres support. Right now I am testing some patches that will give Postgres an important performance boost on writes (which are the key bottleneck in clustered scenarios), and we are working on some optimizations that we hope will help all writes (MySQL as well).

Most of our current performance work is based on very fine-grained monitoring of our production cluster, rather than synthetic benchmarks. It'd be a _lot_ of fun to setup a small cluster to benchmark, and we could capture traffic from our production site and replay it *fast* to see how far we can take it and what bottlenecks we find.

What scalability are you after? How many users?
Average of ratings: -
In reply to Martín Langhoff

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
The scalability I am looking for would allow for every course
in the University of Wisconsin to use the system.

The number of users (students) we have is 160,000.
Of course, that's not sufficient to truly think about load,
you have to add the usage characteristices.
In our eLearning RFP done in 2002, I was responsible for the
technology portion, I did put in a section on load characteristics.
It had a flavor of:
N quizzes with M questions used by O students with no worse than 5 sec
responses.

I can dig this up, if there is interest, it's a completely public document.

Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Michael Penney -
Hi Dirk, it would be great if you could dig this

I can dig this up, if there is interest, it's a completely public document.

up!




Average of ratings: -
In reply to Michael Penney

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
Here's the appendix with our special terms and conditions.
I'm just giving you this much, the full RFP is about 200pp.

The performance metrics are hopefully obvious. If not, feel free to
inquire further.
Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Martín Langhoff -
A well configured Moodle install can meet those requirements. Our current cluster meets and easily exceeds the requirements under the "sustained" column. More hardware and tuning would be required to achieve the "peak" load you picture.

This kind of performance tuning is what we enjoy being involved in. Is there interest at UoWM in working with third parties?
Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Martín Langhoff -
As for deployment and cluster management, we have a full toolchain (which includes 'patch' as well as other tools) that manages all the stack: OS, libraries, configuration and application code.

We can guarantee all hosts have the same versions of dependencies, exact same configurations, and exact same moodle code. It's flexible, so we can also run some hosts with any of those things 'different', and then bring them back to "standard". We sometimes do that to 'test the waters' with config changes.

Edit: have you seen the "Moodle Enterprise" thread?
Average of ratings: -
In reply to Don Quixote

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Michael Penney -
I'd think with course themes and metacourses in 1.5, many of the decentralized issues fade away.

Meanwhile with the centralized solution, you gain siginificant performance overhead if you have a powerful server or better a cluster, w/as with decentralized the local server can get overwhelmed by peak loads.

Seems to me managing the currency of the codebase is going to be pretty hard with a decentralized system, w/as local customization might be better done via themes, course formats, and metacourses delivered from a central server or cluster.

Average of ratings: -
In reply to Michael Penney

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
I fully agree with Michael here.
Course themes and metacourses solve all needs for "corporate image"  customization by Departments, while, with LDAP enrolment, allowing a decent management of users.

In addition to code base, management of users would be very complex in a decentralized setup. If students are following cross-department (or multi-department) courses, the user experience can degrade a lot: multiple user/pass to access, no single MyCourses page etc. There are solutions for this, but I see the HA cluster, with all its problems, an easier way.  Fortunately, there is growing experience in setting up such clusters for Moodle.

- Enrique -
Average of ratings: -
In reply to Enrique Castro

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
Let me response to the need for "themes and corporate image".

Any changes here only occur occationally. Once per semester.
That I feel could be managed by some "human process", we don't
need to have it driven programatically.

As for code base management ... this is the same problem that Moodle
(or any product) as a whole has. When there is a new release or patch,
it needs to be distributed and installed across the entire user base.
Same thing as OS releases and patches.

As for management of users, my model is
that ALL users with enterprise accounts (we call this NetID) could
login anywhere (to any dept). You don't get into courses
until you are enrolled. We'd have to run the "enrollment" updates
to each dept server, but in this case we'd ONLY send that depts
data. The time for the update is the same.
While you might think that troubleshooting would be harder,
I'd be logging info to some central place, that would be the main
troubleshooting.

Average of ratings: -
In reply to Dirk Herr-Hoyman

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Michael Penney -
As for code base management ... this is the same problem that Moodle

Well if you are letting users run local installs so they can customize them, they your code base managment gets more problematic--you have x moodles to update vs. 1.

If you aren't going to allow customization of local installs, then I don't see any reason for local installs?
Average of ratings: -
In reply to Michael Penney

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Zbigniew Fiedorowicz -
If a department customizes its Moodle code, then it is responsible for maintainance/upgrades.
Average of ratings: -
In reply to Enrique Castro

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Zbigniew Fiedorowicz -
I strenuously disagree.  The issue is not themes, images and other style issues.  For mathematics, physics, engineeering, we need different modules, filters and other kinds of software, e.g. computer algebra systems, which say language courses would have no need for.  As for centralized versus decentralized server hardware, I suspect this will go the way of the old mainframe versus PC debate.  In a few years, typical desktop systems will be able to do just about everything you need a server cluster for currently.
Average of ratings: -
In reply to Zbigniew Fiedorowicz

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Michael Penney -
IMO, module/block/filter availability should be handled at the course format level rather than forcing the installation and maintenance of numerous Moodle installs.

In a few years, typical desktop systems will be able to do just about everything you need a server cluster for currently.

Except that your LMS will be doing much more, so you'll still need a cluster to run ittsmile. Hasn't the actual (user perceived) performance of desktop systems more or less flat-lined as these systems now run much more complicated applications, interfaces, and backround processes than they used to? Mine certainly have, my newer machines with XP SP2 don't seem much faster than my old machines that run Win2ksad.

I was running OS 9 on a new iMac the other day for testing things. It was amazing how much faster than 'Panther' it seemedsurprise.
Average of ratings: -
In reply to Enrique Castro

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Martín Langhoff -
"Course themes and metacourses solve all needs for "corporate image" customization by Departments, while, with LDAP enrolment, allowing a decent management of users."

Exactly. This is where the NZVLE project efforts are moving towards. We recently considered running several Moodle installs in parallel with glue interconnecting them (Auth/SSO, crosslisting of courses/events) and later decided to alter the course towards (ab)using the new theming hooks in 1.5.

In fact, I've added some hooks (which will show up in 1.6) that allow each top-level categoty to drive a theme across all the courses nested inside.

Things however seem to be going in both directions at once -- better SSO, and perhaps some course/event sharing blocks, as well as theming and metacourses. We all get to be right ;)
Average of ratings: -
In reply to Michael Penney

Re: Centralized versus decentralized hosting of moodle (VLE's) in HE - what's the future?

by Dirk Herr-Hoyman -
Until I see performance numbers, I'm not willing to say that a centralized
server will scale better under peak load. See, the problem is that the peak
load comes all at the same time, oh like the 1st week of classes, and in the same
time of the day. This will, in turn, really heat up the database, which is the shared
resource.

I'm also coming from the place on performance that says:
"all performance curves are J-curves". Nothing is truly linear if your N is
large enough. By putting everything into a central server, you have taken
your N farther out on that performance curve.

What tends to happen with the peak load, like the 1st week of courses, is
that you go from something managable, like 20-50% load, to bottleneck
80%+ really fast, with no chance for adjustment.

Another variable here is the size of the database.
With indexing, you can make things go faster on any one table.
However, with more data one tends to make more relations.
For example, keeping track of which department and school you
are in. Let's call this M. Now, the performance here will tend to
be logM, this isn't a J-curve. However ... if you add in the joins that
happen because you normalize a larger enterprise data model,
you could add in a linear term.

On the systems we are currently running, it's the database that's the bottleneck,
not the app server.

What I'm suggesting here is that by splitting up the load, which means
making N smaller, you never hit the "tipping point" in the J curve. That we
could ascertain by performance load testing.

Average of ratings: -