Hi Brian, Thanks for getting back to me on this, its clarified a few queries i had with how mach 2 goes about certain tasks.
The lazy loading you say was introduced in v1.9 definitely sounds like it will be of use. Although we have 48 different modules, there are only a handful that deal with core application functionality (and thus take the majority of load - shopping cart, product searching, order placement etc), so from what your saying, if this means that if the modules gradually reload, then i think this would help us massively! We do have some quite large separate modules that aren't used by many clients, and thus don't suffer a great deal of requests, which i am sure of, will be adding quite a lot of overhead to every application reload we do - given that mach 2 will reload EVERYTHING at once!!! We're going to trial out v1.9 to see how it runs, hopefully it'll be just what we need :) However, if not then at least there is always the server clustering option we could try out. Kind Regards, Bill On Thursday, July 11, 2013 1:41:13 PM UTC+1, Brian Klaas wrote: > > Hi Bill - > > Every time a Mach-II app starts up, or gets restarted, it has to do a lot > of processing. Every config.xml file has to be parsed -- that includes > environment configs and logging configs and so on. Events in your > config.xml files have to be written out to temporary CFCs so they can be > executed rapidly on subsequent requests. If you're using ColdSpring to > autowire your components, the whole ColdSpring startup cycle has to occur. > And don't forget that when a CFC is reloaded in any environment (using > Mach-II or not), ColdFusion is creating Java class files for every single > function in those CFCs. All of this takes time -- a lot of time -- and that > time grows as your app grows in size. > > Mach-II doesn't cache any files as part of this process. It doesn't know > that this CFC has changed but this CFC has not. The expectation is that the > whole application is going to be reloaded when you say "reload the app." > > You can, however, reload individual modules or Mach-II components > (listeners, plugins, filters) via the Dashboard. This is extremely helpful > if your application is very modularized and there are no dependencies > between your core app and the modules (that is, you don't use ColdSpring to > autowire components at the top level of your app that are then inherited > and used in the modules). You can reload modules as needed and as long as > the module startup process isn't very intensive, then you should see > minimal performance impact on your servers. > > We have a couple of fairly large Mach-II apps with not quite as many > modules as yours (about 20). Some of these modules are quite complex with > quite a bit of code in them. We use ColdSpring to autowire our components > (both within Mach-II and separately in the model itself). > > We reached a point a while back where we couldn't just say "Reload the > app" in production without it bringing the server down. We had to switch to > restarting our servers. We run our apps in a cluster so that results in > little to no disruption to our customers, but it's what had to happen. > > When the Mach-II app is starting up, requests to the app are going to get > queued because the app hasn't yet started. This will result in the same > kind of pile-up with any Web application as it starts: requests get queued > by the application server while the application starts up and then people > get impatient and they click links again and again which sends more > requests which also get queued and eventually the application server can't > keep up and usually runs out of threads or memory or both. > > Mach-II 1.9 introduced an option to lazy load modules (so that all the > module startup work only happens when the module is first requested), which > may help in your situation. We're still using 1.8.1, so I don't know how > much better things get with lazy loading of modules because I have no real > production experience with that. > > I'm not aware of anyone who has modified the Dashboard to look at multiple > applications on the same server. The Dashboard is designed to be loaded > into a single Mach-II app and manipulate that app and that app only. I > don't think it can be modified to look at multiple applications at once, > but maybe Peter or Matt (who designed the Dashboard) can chime in and > correct me. > > You should also check your JVM settings and make sure that you have > allocated a decent amount of RAM to the CF instance on each server. We > operate at about 4GB of RAM per instance. You may simply be running out of > RAM while the CF app server chugs away during the Mach-II app startup. > Running low on RAM means swapping to disk and that's always slow on a > server. You also want to set your min/max JVM heap size values in the JVM > config to be the same so that resources aren't spent expanding the heap > space in the JVM on application startup. (This too can result in > significant startup slowdowns.) > > I'm sorry I don't have better news for you on this front. You're probably > just at the point that full server reloads are the only option given the > size of your application. > > brian > > > On Wednesday, July 10, 2013 9:59:57 AM UTC-4, Bill Young wrote: >> >> Apologies in advance - this ones quite a long post! >> >> In summary: >> We are running a production server hosting quite a large mach 2 >> application - 48 modules and counting... >> >> For each client we have, a separate instance of the application is >> created. We are currently sitting at just over 100 clients. >> >> Recently, we've been encountering a few problems when reloading >> applications, sometimes a few at a time. >> >> After the reloading of multiple applications, most notably at times when >> the servers under heavy load, we have experienced massive server slow >> downs, some of which have resulted in the server becoming totally >> unresponsive to the extent where a reboot has been required... >> >> >> I have a few questions on the topic: >> >> 1. To what extent does Mach 2 cache files? - i always believe this was >> everything within config & model folders. does this extend further? - >> filters/plugins etc >> >> 2. When we issue the command to reload the application, what exactly goes >> on behind the scenes with mach 2? - is it selective in what it caches? e.g. >> only caches files that have been modified? >> >> 3. After calling the reload_app command in the url (and thus >> setting MACHII_CONFIG_MODE=1), will the first mach-2 event call have to >> wait for EVERYTHING to be cached? or just that module? >> >> 4. Again, after a reload-app call, if multiple users were to hit the same >> mach2 event at once, can anyone think of any issues this might cause? >> >> 5. I've been trying to get my head around mach-2 dashboard for a little >> while now and looks to have many useful tools (many very relevant!!!), but >> it looks to only be able to handle 1 application at a time..i.e. you have >> to log into the dashboard inside each application... does anyone know of >> any extensions, or ways of modifying the dashboard to handle multiple >> applications running on the server? so you could swap i and out of >> different applicaitons to reload modules quicker? >> >> >> >> Basically, i'm trying to find out if anyone else has experienced similar >> issues when reloading large, high traffic applications, and if there are >> any simple solutions to increasing the speed of reloads. However, more >> importantly, we just need to keep server slow downs (and sometimes crashes) >> to a minimum!!! >> >> The reloads have only recently started becoming a problem as the number >> of mach 2 modules and core components of the system utilising mach 2 have >> grown, hence why i'm inclined to think the caching aspect of mach 2 may be >> playing some role here in our issues. Then again, it may be unrelated >> and/or just down to heavy server load....hopefully some more information >> may shed some light! >> >> >> >> Either way, any clarification/advice/help/information is greatly >> appreciated!! >> >> Many Thanks, >> Bill >> >> >> -- -- For more options and to unsubscribe, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en Git & Wiki: https://github.com/Mach-II/Mach-II-Framework --- You received this message because you are subscribed to the Google Groups "Mach-II for CFML" group. To unsubscribe from this group and stop receiving emails from it, send an email to mach-ii-for-coldfusion+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
