Thanks, Dan and Chris, for your replies.
Let me go a little further. Certainly, I understand the concerns about rearchitecting. I'll give you a few thoughts on what that would entail, though.
As to Dan's question about what's consuming the memory, I don't really have any true stats. But I wasn't suggesting that Model-Glue itself was consuming the memory.
It is most likely that it is due to, as Dan suggests, the large number of singleton model components that are instantiated. My quick guess is that you're talking about perhaps 20 or so model components being instantiated for each of a couple of hundred sites.
That's why the consideration of rearchitecture came up. And it may not be a huge change.
Right now, there's an instance of the framework, along with a single Controller and maybe 20-ish model components, created for each site. Each model component is instantiated with a siteID, and the methods within refer to variables.siteID.
The "rearchitecture" would (I believe) consist primarily of finding the siteID by domain name at the beginning of a session, then setting it into a session variable. That session.siteID would be checked on each request for safety and set to a facade or a local or event variable.
The model components would be instantiated as singletons without a siteID. Their methods would now need a siteID as an argument, which would have been set in OnRequestStart.
That's pretty much the extent of the rearchitecture.
Does the above change your opinions at all? Or do you think it's still better to throw RAM at it?
One other final note, that may or may not be relevant: the generated pages are written to a static file cache, and are served from there until an admin user makes changes to the site. The request still goes through the framework to make sure the cached file exists; but most of the time, the model components aren't doing work, they're just in memory.