Hello,

I've been looking into information on the same subject.  I currently have 6-8 
webservers (depending on the mood of the servers) all running ColdFusion and 
IIS.  They all connect to a single WebLogic server via ISAPI mappings and 
forwards.  I'd like to streamline this down to a few clustered WebLogic servers 
running ColdFusion (probably two instances on each box) being accessed by plain 
IIS servers (with a load balancer in between the web and the application layer 
as well as in front of the web servers like figure 2 at 
http://www.macromedia.com/devnet/coldfusion/j2ee/articles/balancing_j2ee.html). 
 I don't quite have the money for it yet, but its almost here..... Anyway - 
I've been looking for information on the pros and cons.  Particularly since my 
sites typically use some ColdFusion or java on each page - does that mean that 
it still makes sense to separate the IIS functionality?

Lisa

 -----Original Message-----
From:   [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]  On Behalf Of John Beynon
Sent:   Saturday, January 21, 2006 6:31 AM
To:     [email protected]
Subject:        Re: [CFCDev] Load balancing and clustering with enterprise

sadly, once you start talking enterprise stuff there's a lack of
decent documentation since it's a good earner for consultants :)

I have had much success with mulitple servers load balanced with
windows load balancing and two cf instances on each box...if money
isn't a problem then you go down the hardware route (like
macromedia.com) and have a number of forward facing webservers talking
to remote load balanced CF servers via a hardware load balancer.

Once you start thinknig about sites with their own JVMs then server
resources are premium - eg I run each instance with 1gb max memory on
4gb ram servers - I could stretch to a third instance if required but
prefer to leave 2gb memory for the OS. It all depends on the
requirements really and security each requires on the server....

best thing is just ask here if you have any more questions,

john.

On 1/21/06, Kirk Brogdon <[EMAIL PROTECTED]> wrote:
> Could someone suggest a good source on load balancing, server clustering and
> using MX 7 enterprise (books, lists, classes)?
>
> We currently run MX 6.1 (server edition) on 2 production web servers (not
> clustered - one is for Internet sites and the other is for Intranet sites)
> and also on a development box.  From what I have had read about enterprise,
> I could install it on a completly seperate server and create multiple
> instances for each site so that I could isolate my sites to run in their own
> jvm.  I have a lot of questions and I'm not sure where the best place is to
> ask them.  I have downloaded the administration documentation from
> Macrodobie.
>
> I know this isn't a cfc question but many of you are more familiar with what
> lists are out there.
>
> Thanks for anything,
>
> Kirk
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Barney Boisvert
> Sent: Friday, January 20, 2006 4:29 PM
> To: [email protected]
> Subject: Re: [CFCDev] Expense of Operations?
>
>
> A method call is more expensive than a variable reference, but the
> encapsulation the method provides is worth it in almost all scenarios.
>  It's very unlikely that this would grow to a bottleneck since the
> more such operations you have, the more other stuff you're doing in
> the request (most likely).  Only careful load testing will indicate if
> there's a problem, but I'd say you're safe to assume there won't be.
>
> A few request scoped objects is all you'll need in most cases.  Most
> of your objects (including all those you listed in your email) should
> be instantiated into the application and/or session scopes for
> peristance across requests.  That'll speed things up because of
> massively reduced instantiation overhead, and let you do stuff like
> caching.
>
> The number of lines of code in an object will affect instantiation of
> the CFC's FIRST instance (when it's read from disk), but not after
> that.  The number of methods will affect instantiation of all
> instances (but exceedingly little).  Again, until careful load testing
> has illustrated an explicit issue, don't even consider it to be a
> potential issue.
>
> The first and last items are saving you a couple ms tops, per request,
> but the middle item could well be saving you hundreds of ms per
> request.
>
> cheers,
> barneyb
>
> On 1/20/06, Peter Bell <[EMAIL PROTECTED]> wrote:
> >
> > Hello All,
> >
> > Does anyone have any kind of information on the relative expense
> (processing
> > wise) of different operations? For example, assuming a user object has
> been
> > instantiated, how much more processing does it take to getUserFirstName()
> > (assuming it is just a "return THIS.FirstName") versus just using dot
> > notation against the THIS scoped variable for the object?
> >
> > If you have a few hundred such operations as page of processing a page
> > request, would the choice have any substantive affect on application
> > performance?
> >
> > I know there are guides on CF best practices for performance (avoid
> > evaluate, use list compare instead of multiple string comparisons, etc.)
> but
> > I can't find a good guide to the relative cost of OO operations in CF that
> > would help to ensure a design would have a decent shot at being
> performant.
> >
> > Also, while I know it is extremely broad, in general what range of number
> of
> > request scoped objects mught you instantiate in a common page request for
> a
> > "well architected app"? I'm assuming that it would be common for a
> > sophisticated page request to instantiate 10-50 objects between the
> > controller, facades, domain objects, compositional objects and the DAL. Is
> > that a fair heuristic?
> >
> > Finally, does the physical size of an object (the number of lines of code
> > across all of the methods) have any substantive effect on initialization
> > performance (does the entire object get loaded into memory or are the
> > methods loaded into memory one at a time? For example, if you have an
> object
> > with 20 methods each with 500 lines of code where any given page request
> may
> > call only one or two of the methods, would you consider abstracting some
> of
> > the methods into separate objects to cut down on object instantion time?
> >
> > I want to clarify, I'm not trying to shave page processing from 45 to
> 18ms,
> > I'm just trying to make sure that pages with minimal db and file system
> > access don't end up taking 300-400ms.
> >
> > Any thoughts much appreciated!
> >
> > Best Wishes,
> > Peter
>
> --
> Barney Boisvert
> [EMAIL PROTECTED]
> 360.319.6145
> http://www.barneyb.com/
>
> Got Gmail? I have 100 invites.
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to 
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the 
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at 
> www.mail-archive.com/[email protected]
>
>
>


--
<a 
href="http://spreadfirefox.com/community/?q=affiliates&amp;id=734&amp;t=1";>Get
Firefox!</a>


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to 
[email protected] with the words 'unsubscribe cfcdev' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]




----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to 
[email protected] with the words 'unsubscribe cfcdev' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]


Reply via email to