I'm curious how this is handled in some cases. A single application would have a smaller memory footprint on the server, but I've always placed site specific variables in the application scope, keeping sessions much smaller and reducing overall memory overhead. Yes, reinitializing applications can be a bear sometimes, but the savings in memory overhead in high traffic apps is worth the hardship.
Steve 'Cutter' Blades Adobe Certified Expert Advanced Macromedia ColdFusion MX 7 Developer ____________ http://blog.cutterscrossing.com Co-Author "Learning Ext JS 3.2" Packt Publishing 2010 https://www.packtpub.com/learning-ext-js-3-2-for-building-dynamic-desktop-style-user-interfaces/book "The best way to predict the future is to help create it" On 2/22/2011 1:30 PM, Brian Meloche wrote: > I'm late to the thread, but like Eric and Sean have indicated, having all > domains under the same application name is the way to go. We've got a > big multi-tenant application here (several hundred thousand lines of > code) designed that way and it works great. Reinitializing an application is > quick and easy (taking servers out of the farm before doing it, of course) - > seconds, not minutes, and that is for all domains at a time, not for each > one at a time. That's all because of how it's designed. > > I was hoping to speak on the same subject at CFObjective, but Sean got > picked to speak over me. :-( > > On Tue, Feb 22, 2011 at 1:01 PM, Matt Robertson<websitema...@gmail.com>wrote: > >> Even though my own CMS can handle multiple sites running off of a >> single installation, I don't run it that way. The points brought up >> about clients wanting individual customizations and portability fit my >> situation. I understand if you are offering software-as-a-service >> things change, but for me this turned out to be enough of a headache >> that I reverted to separate installs and have never regretted it. If >> a customer wants an upgrade, they pay me an hour or two individually >> to make that happen. If they want a specific feature that I don't >> want to fold into the overall codebase, I can do it - and earn the >> money for doing it - without worrying about consequences on 40 other >> web sites on the server. But thats a business decision and not >> coding. Mentioned just as food for thought. >> >> For sites for my own company, where presently we have about 36 up and >> running and will be at around 60 when we are done, we *do* share a >> single codebase. There are no special mappings. Each site has an >> Application.cfm that looks like this: >> >> request.appName="AR_060110_1033"; >> request.rootFolder="ARDotCom/"; >> request.FQDN="www.mysiteAR.com"; >> >> <cfinclude template="../common/Application_common.cfm"> >> >> The common file has some server vars too: >> >> server.BaseRoot="C:/foo/bar/sites/"; >> server.dsn= etc. etc. blah blah >> >> And thats enough - along with more code in the common >> "Application.cfm" - to set up absolute and relative paths to the files >> I have located in the common-use folder. Every site has its own >> independent application scope. >> >> I've opted to set the app name manually so I can reset session and app >> vars if need be... a rare occurrence but its nice to have the option >> available. >> >> The root of this web site is a root folder in a discrete IIS web site >> and, since CF has no trouble recursing back up beyond a web root >> insofar as physical paths go, the /common/ folder is not accessible >> from the web, but it is from CF. Very simple to set up. >> >> -- >> --m@Robertson-- >> Janitor, The Robertson Team >> mysecretbase.com >> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342487 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
