Thanks for that Matt! I've been looking for something like that for a while
now!
That gives me some interesting ideas, thanks you! :oD
Mark
On 2/6/07, Matthew Drayer <[EMAIL PROTECTED]> wrote:
Hi Mark,
With this nifty code snippet I scored from, I think, Brandon Purcell's
blog...I'll see if I can dig up the original link reference
<!--- These variables handle the available RAM calculation, which we are
now using to manage objects resident in the server scope --->
<cfset variables.runtime = createObject("java","java.lang.Runtime
").getRuntime()>
<cfset variables.freeMemory = variables.runtime.freeMemory() / 1024 /
1024>
<cfset variables.totalMemory = variables.runtime.totalMemory() / 1024 /
1024>
<cfset variables.percentFreeAllocated = round((variables.freeMemory /
variables.totalMemory) * 100)>
Matt
Matthew Drayer
Development Manager
HCPro, Inc.
Marblehead MA
[EMAIL PROTECTED]
------------------------------
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Mark
Mandel
*Sent:* Sunday, February 04, 2007 5:01 PM
*To:* [email protected]
*Subject:* Re: [CFCDEV] How many objects is too many?
Matthew,
How are you keeping track of the % ram available on the server?
Mark
On 2/5/07, Matthew Drayer < [EMAIL PROTECTED]> wrote:
>
> Hi there,
>
> Our enterprise app is comprised of two major tiers -- a business layer
> and a service layer. The SL entities represent our core systems, and the BL
> entities represent business concepts such as customers and items, and
> there's a controller for each layer. When objects are needed they are
> instantiated by the controller and cached into persistent memory (ie, lazy
> load). To keep RAM utilization to a minimum, we load data into the objects
> only as needed, too. Every get() method has a corresponding load() method
> which is in charge of requesting data from the service layer. So, the
> objects get "heavier" as they stick around, but it means less overhead in
> terms of instantiation.
>
> BL entities are destroyed by the BL controller upon completion of any
> add(), edit(), or remove() transaction. We also have a scheduled task which
> runs on the side -- it manages a TTL value for the entities based on a
> datetime value embedded in each entity upon instantiation as well as %
> available RAM on the server. The less RAM available, the shorter the TTL.
> This way no one slips through the cracks and we don't max out the memory.
>
> On average we have about 6000 object instances in RAM at any given time
> representing customers, items, categories, etc. If we didn't run a model
> like this we'd probably have a dozen machines in production in order to
> support all of our sites, instead of just one.
>
> I also recommend if you are thinking about exposing your model as a web
> service, that you create a lightweight "listener" CFC to function as a
> middle man between clients and the model. Give it one method called
> something like "processRequest" and have it collect/pass the actual method
> name and data container(s) to a persistent controller object for processing.
>
> Matt
>
> Matthew Drayer
> Development Manager
> HCPro, Inc.
> Marblehead MA
> [EMAIL PROTECTED]
>
> -----Original Message-----
> *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *
> Nando
> *Sent:* Sunday, February 04, 2007 10:07 AM
> *To:* [email protected]
> *Subject:* Re: [CFCDEV] How many objects is too many?
>
> Jaime,
>
> My line of thinking here is pretty simple, but i think it's in line with
> best practice in CF.
>
> If you simply need to display the data to the user (probably as a list),
> use cfquery, a ColdFusion query object. If your users need to work with the
> data, then go with business objects, DAO's, etc.
>
> The simple fact of the matter is that a user will not be able to edit
> 1000's of entities at the same time. I see the usefulness of an object most
> clearly when you need to both maintain state and manipulate the data, during
> an editing operation for instance. And i don't see the possibility of
> needing to instantiate hundreds of objects in one go unless you're working
> with data, specifically a list of records.
>
> As far as your service layer goes, well, you're probably going to
> instantiate that and cache it in application scope, using lazy loading
> wherever possible. Practically, if you've got 100's of objects in your
> service layer, i'm pretty sure they won't all be needed on the first page
> load.
>
> Another possible way of minimizing the overhead of object creation is to
> represent the data packets only as an array of structs if you're more
> comfortable with that rather than a query object, and populating a full
> blown business object as necessary from the array of structs.
>
> Translating that to the world of transfer, at it's current level, means
> to me that transfer isn't well suited to display lists, for instance. Better
> to use your own gateway for that and return a query object, possibly caching
> it with your own mechanism if needed. Or use the new "Transfer Query
> Language" feature Mark is working on instead of your own gateway.
>
> I'm sure your use cases are more complex than i've represented them here
> talking about lists and edit operations, but as far as i know, this is the
> general approach to use in CF for performance reasons.
>
> Jaime Metcher wrote:
>
> Hi,
>
> When you're modelling your application, how much attention do you pay to
> minimizing the number of objects instantiated? Obviously CF has a higher
> object creation overhead than some other languages. OTOH, the gist of much
> OO practice (and many patterns) is to create lots of fine grained objects.
> I often read that a typical noob error is creating too few objects with too
> many responsibilities.
>
> So, how often do you find yourself thinking "well, in Java or Smalltalk
> I'd do xyz, but in CF I'd better not because I'd end up with too many
> objects"? Which is another way of asking to what extent we need to modify
> existing OO practices to allow for CF's limitations.
>
> A couple of points of reference:
> 1. This post was prompted by a discussion with Mark Mandel on the
> transferdev list. I'd spotted an issue purely because of the massive
> slowdown that occurred when 700 objects were inadvertently created. That
> issue has been resolved, but it left me wondering, if I can't instantiate
> 700 objects how many can I create? 10? 50? This has huge implications for
> how we architect our apps.
>
> 2. I have a Dolphin Smalltalk image that, from a fresh install, reports
> instantiating 160,000 objects. Obviously with an object system this slick
> you don't worry much about throwing in a few hundred more. Given that CF's
> comfort zone is probably a couple of orders of magnitude lower, maybe a lot
> of the standard advice on OO design just doesn't apply to CF?
>
> Any thoughts appreciated.
> Jaime Metcher
>
> You are subscribed to cfcdev. To unsubscribe, please follow the
> instructions at http://www.cfczone.org/listserv.cfm
>
> CFCDev is supported by:
> Katapult Media, Inc.
> We are cool code geeks looking for fun projects to rock!
> www.katapultmedia.com
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
> --
>
> <http://aria-media.com/>
> Aria Media Sagl
> CP 234
> 6934 Bioggio
> Switzerland
> www.aria-media.com <http://aria-media.com/>
>
>
>
> You are subscribed to cfcdev. To unsubscribe, please follow the
> instructions at http://www.cfczone.org/listserv.cfm
>
> CFCDev is supported by:
> Katapult Media, Inc.
> We are cool code geeks looking for fun projects to rock!
> www.katapultmedia.com
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
> You are subscribed to cfcdev. To unsubscribe, please follow the
> instructions at http://www.cfczone.org/listserv.cfm
>
> CFCDev is supported by:
> Katapult Media, Inc.
> We are cool code geeks looking for fun projects to rock!
> www.katapultmedia.com
>
> An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
>
>
>
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
