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: cfcdev@cfczone.org
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] <mailto:[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]
<mailto:[EMAIL PROTECTED]> ] On Behalf Of Nando
Sent: Sunday, February 04, 2007 10:07 AM
To: cfcdev@cfczone.org
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/cfcdev@cfczone.org
--
<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/cfcdev@cfczone.org
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/cfcdev@cfczone.org
--
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/cfcdev@cfczone.org
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/cfcdev@cfczone.org
