site cache and load balancing

thanks for the repl, I think they are also in the post below??
http://rtfm.modx.com/display/revolution20/modRegistry#modRegistry-RegisteringLoadBalancedWebNodesforRemoteCommands

in this post opengeek mentions:
You can take the idea and tailor it for your environment, but in our experience the best practice is to isolate one server instance for the manager (via subdomain configuration or similar) that is separate from your remote web nodes.

Does the above mean the following:
We only have one instance of the MODx manager, that is decoupled from the frontend and writes to the master DB?
The DB is then pushed out to the nodes and they clear their caches accordingly?
Is this correct?

I assume when you save a resource something gets set in the DB to say "clear the freakin cache" next time around? If so then the above approach would work for us? We can easily setup a MODx manager to run on a seperate domain and write to the master DB.

Yeah they look the about same.

I went on the same journey a few weeks back - it seems complicated when you're trying to just get a foot in the door, but it all falls into place, and is actually a simple and effective mechanism.


Yep, a separate manager instance is good - we just have to take control of the system wide caching aspect when using multiple nodes.



When you save a resource on the master DB it triggers a system event 'OnSiteRefresh'…

We listen for the 'OnSiteRefresh' event in our 'SendClearCache plugin' and create a 'clear cache' message for all subscribed/registered node IP addresses.



Have you used system events and plugins before?
Very nice, and easy to do:
http://rtfm.modx.com/display/revolution20/System+Events
And,
http://rtfm.modx.com/display/revolution20/Plugins



Back on the web node(s), we listen for the event 'OnWebPageComplete' in our 'RemoteCommands plugin', and then check to see if we have a message.

If we do have a message we call a Modx Method to clear the cache locally.

Once the message has been consumed by the web node, it is removed (so the web node doesn't repeatedly clear the local cache).

Do you have sticky sessions on your load balancer?

Let me know if you get any test code up and I can help you to debug it.

[ed. note: thenewmanifesto last edited this post 15 years ago.]

Quote from: thenewmanifesto at Oct 04, 2011, 08:54 AM

Yeah they look the about same.
Do you have sticky sessions on your load balancer?

I have no idea. As far as I am aware there are no persist sessions in use on the site. IE fi you traverse from one node to another we use cookies and do not keep session info.

In my mind...this is how I see it working (Correct me as I am probably wrong!!!)

Master Server 1
admin.mydomain.com -> Running the MODx /manager/ that writes to a master DB

Node times X (Web Servers)
mysite.com -> Running an instance of the site (but not manager), and writing to the cache locally.
When this guy sees a change in his DB, he will "refresh" his cache.

In relation to your last post, I understand the concept, but when you say "listen", is this a http request or something that lets the node know to refresh etc? What is the message, a stream....xml?

Another question that relevant:
How does MODx know what to do with a request:
IE go to cache or hit the DB?

I never had to worry about this stuff before Interesting challenge!

You've nailed it I reckon.

Broadcasting/Listening and Event/Observer are just terms that describe the constructed relationship between events and objects in programming. I'm not meaning to confuse the issue…!

http://en.wikipedia.org/wiki/Observer_pattern
Event listening or 'observing' isn't about networks or protocols, its a programming paradigm.


In our case, 'listening/observing' relates to the observation of Modx system events to initiate the cacheclear process, but I think I confusingly used the same term to describe our 'messages'.

The Modx messages themselves can be files, or database rows in the master DB.
I haven't tried file based myself...

When I said 'listening' in the 'message' context, I just meant 'database query to look for messages'.


Sorry if I've confused you further - I'll stop now before I make it worse!

Not at all, thak you for your patience
I'm going to throw a spanner in thwe work now:
Our DB cluster is automatically synced. There is no "master" as such.

So now the senarios would be:
- User x hits node Y after an update to the DB.
- node Y clears its local file cache
- User y hits node Z after the above, but as they all have the same DB he does not flush his cache.

Is this now a problem?
We have access to membase machines, so I guess I could use this a a cache solution, and avoid all of the above as it would essentially be a centralised cache for all nodes?

Here are examples of the plugins we have used (and customized as needed) for load balanced environments.

This does not address MySQL Master/Slave configurations, only separate web server nodes that are load balanced and all connected to the same database, typically sharing an NFS mounted file system with the MODX files except the cache files for each local instance (which are configured to a local path that exist for each web node; this is the local file system cache).

MODX 2.2 does now feature support for MySQL Master/Slave (and other multi-node) configurations, but this is different than what is being described here. Clearing the MODX cache is irrelevant to what database a web server node is connected to, and in the current stable releases, there is no way to specify multiple connections. See here for information on the new features that can be utilized in current MODX 2.2 builds (available as nightlies). MODX documentation for this coming soon, but you can specify the additional configuration settings in the $config_options array which is defined in the config.inc.php file as described in this blog post. This data is preserved between upgrades.

Thanks for this man.

We don't have a master DB as such, we would just have one domain that is basically a cluster of mysql servers....so it's seen as one DB (This is my understanding)

For our needs, I think we could probably set the below to something like 15 minutes:

cache_db_expires
cache_expires

This would ensure all nodes go to the DB for content every 15 minutes?
This will significantly decrease the DB load.
It think it would be acceptable for us to say that changes will not be live for 15 minutes or so.
The other option is memcache, which I have never used. But I understand as this is a centralized source for cache I would not need to get into registering etc, as there would be no local caches maintained.

Be aware that there are still some outstanding issues with using cache_db in all releases of MODX Revo so far. It causes some inconsistencies with the manager views, so if you are using the manager often, I would not recommend using cache_db. Also, setting the cache expiration means that they will be regenerated every fifteen minutes even if they don't need to be. Is this really what you intend? Why have to reload the cache if no data has changed in the manager?

I don't guess I understand what kind of MySQL configuration you are using so I cannot really recommend anything specifically with regards to that, but if you are running a multiple master master/slave configuration, I would proceed with a lot of caution and make sure you connect to only one instance for management activities.