Single vs multiple instances

[Tom McNeer]

I am working on an application which was built according to the experience of the original developer - that being, a small number of sites, all with high traffic, which shared the same application code.

So the application was built to create an instance of the application for each site, with their own controller and model layers.

The reality of the business, however, is a large number of sites per server (maybe a couple of hundred), each of which has extremely low traffic.

Thus we have probably a couple of hundred instances of a Model-Glue application running on the server. It's been pumped up with RAM to try to handle the load, but there are still performance problems.

The question I've been asked to put to the group is simply, "Does the best course seem to be to keep adding RAM, or rearchitect so that there's a single instance of the app, and the individual siteID is set into a session variable then used in calling methods in the model?"

I have an opinion, but frankly I have no experience with lots of M-G instances on a server, and I don't know what all the implications might be.

Thanks in advance for any advice or tales from your own experience.

--

Thanks,

Tom

Tom McNeer
MediumCool
http://www.mediumcool.com
1735 Johnson Road NE
Atlanta, GA 30306
404.589.0560

[Dan Wilson]

Wow. Well, in all my years of dealing with performance problems, if given the choice to rearchitect working code, or add memory, I'd prefer to add memory.

You can get an incredible amount of memory for what a single developer costs the company in a week.

A rearchitecture of the sites would likely take longer than a week and could introduce instability of it's own, so my first choice would be to add RAM until it's no longer feasible.

DW

Tom McNeer

Wednesday, January 28, 2015 2:30 PM

--
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
 
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
---
You received this message because you are subscribed to the Google Groups "model-glue" group.
To unsubscribe from this group and stop receiving emails from it, send an email to model-glue+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Peterson]

I completely agree with Dan, infrastructure changes are most often far cheaper than development / QA resources.  If memory cannot be expanded any further, you can always slice off 1/2 the sites to a 2nd server as well and reduce the memory needs further.

Chris

--

Hey! I dont tell you how to tell me what to do, so dont tell me how to do what you tell me to do! ~ Bender (Futurama)

[Dan Wilson]

I had another thought about this problem you have. The memory footprint of Model Glue itself is rather small. Are you sure the memory is being consumed by Model Glue?  A lot of times a Model can be rather large, especially if used in a singleton fashion. Also I've seen session objects that were enormous. So before you make a determination of which way to go, you would need to find out why the memory is bloated. I would be surprised if in fact, the Model Glue framework was especially large. Even if used 100 times.


DW

Tom McNeer

Wednesday, January 28, 2015 2:30 PM

[Tom McNeer]

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.

[Dan Wilson]

So, all of the hundreds of sites share the EXACT model objects and view objects?

dW

Tom McNeer

Friday, January 30, 2015 11:11 AM

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.

Dan Wilson

Friday, January 30, 2015 9:53 AM

[Tom McNeer]

Correct. No difference at all.

[Dan Wilson]

Yeah, that is weird.

I usually handle this through a cookie, rather than a session variable. Cookies are more useful when dealing with loadbalanced infrastructures, versus sessions, which do not replicate.  Plus, once set, they would be available on the client, for any client side trickery you want to use.

But if in fact, you can be 100% sure all of the views and all of the model objects are the same, then I think the refactor would be pretty simple. Still though, before I invested more than a day on it, I'd see how much RAM could be utilized. Like I said, programming is more expensive than RAM. And there are no weird anticipated side effects from adding RAM. If you miss some critical business logic, that would cause problems.


DW

Tom McNeer

Friday, January 30, 2015 1:31 PM

Correct. No difference at all.

[Tom McNeer]

On Fri, Jan 30, 2015 at 1:36 PM, Dan Wilson <sipa...@gmail.com> wrote:

I usually handle this through a cookie, rather than a session variable. Cookies are more useful when dealing with loadbalanced infrastructures, versus sessions, which do not replicate.  Plus, once set, they would be available on the client, for any client side trickery you want to use.

True. That's a better solution.

 

But if in fact, you can be 100% sure all of the views and all of the model objects are the same, then I think the refactor would be pretty simple.

Yes. We can be sure of that.

 

Still though, before I invested more than a day on it, I'd see how much RAM could be utilized. Like I said, programming is more expensive than RAM. And there are no weird anticipated side effects from adding RAM. If you miss some critical business logic, that would cause problems.

True. Which just means there's no simple answer, which is what I expected. The solution for years now has been just to add RAM to the server, or upgrade to a more powerful server. And that can continue indefinitely, along with adding a second server.

Anyway, thanks very much for your thoughts. Jeff Gladnick just wanted to hear what you had to say before we made a decision. But we didn't expect a hard-and-fast answer, to be truthful.