Primary Navigation

Getting the conversation going again

There were some great conversations about the direction of Fusebox in late November, then nothing. I m aware that the holidays are coming up but I d still like

Message 1 of 14
, Dec 10, 2009

0 Attachment

There were some great conversations about the direction of Fusebox in late November, then nothing. I'm aware that the holidays are coming up but I'd still like to encourage some discussion on options.

One issue that seemed to attract some interest was reducing the memory footprint of the Fusebox variable.

As I recall, Sean Corfield said he had some ideas on how this could be done. Sean, if you have some spare time I'd be very interested in hearing these ideas, even if they're not solid as of yet.

Matthew Gersting

This definitely sounds like an interesting place to start. I m curious though, are there any previous discussions or data about this issue? I ve been using

Message 2 of 14
, Dec 15, 2009

0 Attachment

This definitely sounds like an interesting place to start. I'm curious though, are there any previous discussions or data about this issue? I've been using Fusebox for years, but have never really run any serious memory analysis. What info already exists (in an effort to define and diagnose the issue) in this area?

> From: jordanreiter <jordanthecoder@...>
> Subject: [fusebox5] Getting the conversation going again
> To: fusebox5@yahoogroups.com
> Date: Thursday, December 10, 2009, 12:46 PM
> There were some great conversations
> about the direction of Fusebox in late November, then
> nothing. I'm aware that the holidays are coming up but I'd
> still like to encourage some discussion on options.
>
> One issue that seemed to attract some interest was reducing
> the memory footprint of the Fusebox variable.
>
> As I recall, Sean Corfield said he had some ideas on how
> this could be done. Sean, if you have some spare time I'd be
> very interested in hearing these ideas, even if they're not
> solid as of yet.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
> fusebox5-fullfeatured@yahoogroups.com
>
>
>

Mike Ritchie

The main issue in my opinion is that the application.fusebox object stores every verb as individual objects as well, in server memory, even though for

Message 3 of 14
, Dec 15, 2009

0 Attachment

The main issue in my opinion is that the application.fusebox object
stores every verb as individual objects as well, in server memory, even
though for production useage where a parsed file exists those objects
are never required. You can easily have 1000 verb objects in memory when
your application is loaded up. If you have a single site on a single
server that's not a problem, but if you're trying to use Fusebox as a
solution for a hosted service, where each site is in effect a separate
Fusebox application, then this adds up very quickly. I think there would
be an immediate drop in memory footprint if another method of storing
the xml for parsing was considered.

In Fusebox 5.x for PHP, we have 2 different application structures: one
for production mode when no parsing is required, and one where
fusebox.load or fusebox.parse is true. The production mode structure
stores just enough of the application.fusebox structure so that all
public properties can be accessed by the developer or by myFusebox, but
doesn't store any of the globalfuseactions, lexicons or classes, verbs,
or pre/postfuseactions. I've seen the difference between the 'slim'
application.fusebox structure and the the full application.fusebox
structure be as much as 1:3. Now this is only possible because there is
no true application scope stored in memory, so the application.fusebox
structure is rebuilt at the beginning of every request. If fusebox.parse
is true we can just include the file that provides the full serialized
application structure, otherwise the 'slim' file is used instead. In CF
that's not possible, so a different storage method would be necessary.

Anyways, this is all moot until someone steps up to fill Adam and Sean's
shoes. I'd love to volunteer myself, but I'm definitely not talented
enough, nor available enough. It sounds like nothing's ever going to get
done on Fusebox until there's some movement by Teratech to allow the
framework to be relinquished.

Mike
www.fusebuilder.net

Matthew Gersting wrote:

>
> This definitely sounds like an interesting place to start. I'm curious
> though, are there any previous discussions or data about this issue?
> I've been using Fusebox for years, but have never really run any
> serious memory analysis. What info already exists (in an effort to
> define and diagnose the issue) in this area?
>
> --- On Thu, 12/10/09, jordanreiter <jordanthecoder@...
> <mailto:jordanthecoder%40gmail.com>> wrote:
>
> > From: jordanreiter <jordanthecoder@...
> <mailto:jordanthecoder%40gmail.com>>
> > Subject: [fusebox5] Getting the conversation going again
> > To: fusebox5@yahoogroups.com <mailto:fusebox5%40yahoogroups.com>
> > Date: Thursday, December 10, 2009, 12:46 PM
> > There were some great conversations
> > about the direction of Fusebox in late November, then
> > nothing. I'm aware that the holidays are coming up but I'd
> > still like to encourage some discussion on options.
> >
> > One issue that seemed to attract some interest was reducing
> > the memory footprint of the Fusebox variable.
> >
> > As I recall, Sean Corfield said he had some ideas on how
> > this could be done. Sean, if you have some spare time I'd be
> > very interested in hearing these ideas, even if they're not
> > solid as of yet.
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> > fusebox5-fullfeatured@yahoogroups.com
> <mailto:fusebox5-fullfeatured%40yahoogroups.com>
> >
> >
> >
>
>

Barney Boisvert

What version(s) of Fusebox are you using? FB3 had zero shared memory usage for the framework (everything was run per request). FB4 was the first version that

Message 4 of 14
, Dec 15, 2009

0 Attachment

What version(s) of Fusebox are you using? FB3 had zero shared memory
usage for the framework (everything was run per request). FB4 was the
first version that used XML and cached stuff in the application scope
because interpreting XML is too slow. FB5 and then 5.5 expanded that
as new features were added; in particular, the ability to do dynamic
dispatch meant that full-request parse files weren't easily doable in
the same way as in FB4, so there are parse fragments that must be
cached, and a bit more runtime assembly.

I don't want to put words in Sean's mouth, but my impression is that
he was assuming that RAM is cheaper than both CPU and user wait time.
As such people would rather drop a hundred bucks on another GB of RAM
versus upgrading their CPUs and/or having requests average slightly
slower. In general, I'd agree with this compromise, though obviously
it's not necessarily going to be the best one in every situation.

The issue of memory consumption has come up numerous times on the
lists, but never with any substantial action towards detailing the
problem or discussing a solution. I don't recall (though my memory is
far from perfect) any hard numbers detailing memory consumption of a
FB app of a specific size. That'd be the first thing to gather. The
other thing that must be determined is how much memory is acceptable
to use for a FB app of a given size, where size is measured based on
circuit and fuseaction counts. I have no idea what that figure might
be, but comparing it against actual usage will determine whether there
is actually a problem that needs addressing or if it's just people
prematurely optimizing for a problem that doesn't really exist.
Something of interest would be to compare memory usage of apps of
similar size between FB and other frameworks. Not that it's apples to
apples, but it'd provide some context for discussion.

One way of reducing memory (at the expense of framework spinup time)
would be to load the XML once, write out the parse files for
everything (including inlining code for dynamic dispatch), and then
forget all the state of the framework and just run the parse files. I
don't think it's a good solution, but it would certainly meet the need
and is implementable. Sean is the closest to the current version of
the core files, and while he has stepped down from an active
development role, I'm sure he'd be willing to lay out some ideas and
potential approaches for someone to pick up and run with. But he's
also got like a million cats, it's the holidays, and Railo's down and
dirty with some fundamental steps forward, so he's undoubtedly rather
busy.

> This definitely sounds like an interesting place to start. I'm curious though, are there any previous discussions or data about this issue? I've been using Fusebox for years, but have never really run any serious memory analysis. What info already exists (in an effort to define and diagnose the issue) in this area?
>
> --- On Thu, 12/10/09, jordanreiter <jordanthecoder@...> wrote:
>
>> From: jordanreiter <jordanthecoder@...>
>> Subject: [fusebox5] Getting the conversation going again
>> To: fusebox5@yahoogroups.com
>> Date: Thursday, December 10, 2009, 12:46 PM
>> There were some great conversations
>> about the direction of Fusebox in late November, then
>> nothing. I'm aware that the holidays are coming up but I'd
>> still like to encourage some discussion on options.
>>
>> One issue that seemed to attract some interest was reducing
>> the memory footprint of the Fusebox variable.
>>
>> As I recall, Sean Corfield said he had some ideas on how
>> this could be done. Sean, if you have some spare time I'd be
>> very interested in hearing these ideas, even if they're not
>> solid as of yet.
>>

... This isn t really an accurate statement as adding more RAM does not equal more memory CF can use. At best on a Windows 32 bit machine you can push the

Message 5 of 14
, Dec 15, 2009

0 Attachment

Barney Boisvert wrote:

As such people would rather drop a hundred bucks on another GB of
RAM
versus upgrading their CPUs and/or having requests average slightly
slower. In general, I'd agree with this compromise, though obviously
it's not necessarily going to be the best one in every situation.

This isn't really an accurate statement as adding more RAM does not
equal more memory CF can use. At best on a Windows 32 bit machine you
can push the 1.1+ GB memory limit for an instance of CF. On a 64 bit
machine it's a little over 3.2+ GB but that doesn't really equal 3X the
32 bit machine but it's still an upper ceiling. If it were as easy as
buying 16 GB of RAM and CF could use 15 of the 16 GB I would completely
agree but this just isn't the case on the Windows environment.

The issue of memory consumption has come up numerous times on the
lists, but never with any substantial action towards detailing the
problem or discussing a solution. I don't recall (though my memory is
far from perfect) any hard numbers detailing memory consumption of a
FB app of a specific size. That'd be the first thing to gather.

Why? I can tell you w/out any fixed numbers FB 5.1 & 5.5.1 eat up
almost all available memory on a 32 bit Windows machine w/ 1.1+ GB
memory given to the CF instance when you try and load 15 apps w/
several hundred circuits. I know Mike is in the same boat as I am w/
his application. It's a real problem which exists. Also, I don't see
how comparing it to other frameworks memory footprint provides much
benefit. Neither Mike nor I are in a position to rewrite these apps so
even if Mach II uses 1/10 of the memory footprint FB does, switching to
Mach II would be a major investment which I don't think either of us
can make at this time. It's better to fine tune the existing engine
IMO.

One way of reducing memory (at the expense of framework spinup
time)
would be to load the XML once, write out the parse files for
everything (including inlining code for dynamic dispatch), and then
forget all the state of the framework and just run the parse files. I
don't think it's a good solution, but it would certainly meet the need
and is implementable.

I like this line of thinking but can't we try and meet in the middle
(when in prod mode) where the core loads what it needs to parse the
circuit and then releases this memory back rather than storing all the
verbs? I recall Sean saying this would require a re-write of some
major items in the core but I'm not sure why. Sean any chance we can
have a dialog off-line to go over what's going on under the hood so
that we might be able to tackle this issue? I just got our core app
ported from 5.1 to 5.5.1 using the latest stable code and will try and
make some time over the next few months to investigate/work out a
solution. But I definitely don't want to dive in w/out a bit more
understanding of the core 1st.

-Jason

Barney Boisvert

Running multiple instances of CF on a single machine is a trivial exercise. Windows has had support for more than 4GB of RAM, even on 32-bit systems, for

Message 6 of 14
, Dec 15, 2009

0 Attachment

Running multiple instances of CF on a single machine is a trivial
exercise. Windows has had support for more than 4GB of RAM, even on
32-bit systems, for quite some time, so you can easily run a bunch of
CF instances on a single Windows machine and spread your applications
out a bit RAM-wise.

Just to be clear about your example, when you load 15 apps with
several hundred circuits each it eats up almost all of your 1.1GB
allotment. Assuming CF itself consumes ~250MB, that leaves over 50MB
of RAM utilized by each application. Do you have any information
about how much of that is FB versus your application itself (CFC
instances, etc.)? Do those numbers mesh when you only spin up a
single app (you get 1/15th the usage)?

I wasn't alluding to switching from FB to another framework; I was
just wondering if FB was actually a memory hog. Obviously making it
more memory efficient is desirable, but if other frameworks have
similar memory usage profiles, it might be worth examining best
practices for them to see what we might do better from an APPLICATION
development perspective, since I don't hear them complaining about
memory nearly as much as FB developers. That could also be that FB's
footprint has grown dramatically, while Mach-II and MG have always
been users of significant memory.

As for storing the verbs, you can avoid doing that if you do a full
generation of all parse files, otherwise you're stuck rereading the
XML every time you get a request to a fuseaction that you don't have a
parse file for. But Sean's the guy for this stuff; he wrote it, and
knows more about the guts than anyone else.

>
>
> Barney Boisvert wrote:
>
> As such people would rather drop a hundred bucks on another GB of RAM
> versus upgrading their CPUs and/or having requests average slightly
> slower. In general, I'd agree with this compromise, though obviously
> it's not necessarily going to be the best one in every situation.
>
> This isn't really an accurate statement as adding more RAM does not equal more memory CF can use. At best on a Windows 32 bit machine you can push the 1.1+ GB memory limit for an instance of CF. On a 64 bit machine it's a little over 3.2+ GB but that doesn't really equal 3X the 32 bit machine but it's still an upper ceiling. If it were as easy as buying 16 GB of RAM and CF could use 15 of the 16 GB I would completely agree but this just isn't the case on the Windows environment.
>
> The issue of memory consumption has come up numerous times on the
> lists, but never with any substantial action towards detailing the
> problem or discussing a solution. I don't recall (though my memory is
> far from perfect) any hard numbers detailing memory consumption of a
> FB app of a specific size. That'd be the first thing to gather.
>
> Why? I can tell you w/out any fixed numbers FB 5.1 & 5.5.1 eat up almost all available memory on a 32 bit Windows machine w/ 1.1+ GB memory given to the CF instance when you try and load 15 apps w/ several hundred circuits. I know Mike is in the same boat as I am w/ his application. It's a real problem which exists. Also, I don't see how comparing it to other frameworks memory footprint provides much benefit. Neither Mike nor I are in a position to rewrite these apps so even if Mach II uses 1/10 of the memory footprint FB does, switching to Mach II would be a major investment which I don't think either of us can make at this time. It's better to fine tune the existing engine IMO.
>
> One way of reducing memory (at the expense of framework spinup time)
> would be to load the XML once, write out the parse files for
> everything (including inlining code for dynamic dispatch), and then
> forget all the state of the framework and just run the parse files. I
> don't think it's a good solution, but it would certainly meet the need
> and is implementable.
>
> I like this line of thinking but can't we try and meet in the middle (when in prod mode) where the core loads what it needs to parse the circuit and then releases this memory back rather than storing all the verbs? I recall Sean saying this would require a re-write of some major items in the core but I'm not sure why. Sean any chance we can have a dialog off-line to go over what's going on under the hood so that we might be able to tackle this issue? I just got our core app ported from 5.1 to 5.5.1 using the latest stable code and will try and make some time over the next few months to investigate/work out a solution. But I definitely don't want to dive in w/out a bit more understanding of the core 1st.
>
> -Jason
>
>
>
>
>
>

... There s a hard limit on memory -- in CF7 and lower at least, not sure about CF8+ -- of around 2GB, maybe less, for a server instance. If you try to set it

Message 7 of 14
, Dec 15, 2009

0 Attachment

> I don't want to put words in Sean's mouth, but my impression is that
> he was assuming that RAM is cheaper than both CPU and user wait time.
> As such people would rather drop a hundred bucks on another GB of RAM
> versus upgrading their CPUs and/or having requests average slightly
> slower.

There's a hard limit on memory -- in CF7 and lower at least, not sure about CF8+ -- of around 2GB, maybe less, for a server instance. If you try to set it higher, the server simply won't start up at all. I know that seems like a lot, but for servers with a lot of activity and apps, the memory can fill up quickly. There are already some memory leak issues here and there, so every little bit helps.

> Sean is the closest to the current version of
> the core files, and while he has stepped down from an active
> development role, I'm sure he'd be willing to lay out some ideas and
> potential approaches for someone to pick up and run with.

I believe he mentioned in an earlier discussion that he actually had some ideas in this direction, but we never got around to having a good discussion on them, which is why I started this thread.

Jeffrey Roberson

Does this only affect Windows? I m just asking as I have about 25 Fusebox 4.1 - Fusebox 5.5 applications running on the same Linux Red Hat ES Box / Coldfusion

Message 8 of 14
, Dec 15, 2009

0 Attachment

Does this only affect Windows?

I'm just asking as I have about 25 Fusebox 4.1 - Fusebox 5.5 applications running on the same Linux Red Hat ES Box / Coldfusion 8.1 the server also runs MYSQL and CPANEL. The server has 4 GIG of Ram with 1 GIG set for the JVM.

5 of the 25 sites have hundreds of circuits/files and have very heavily traffic. It's the peak part of the day and I am sitting at :

Just curious since everything we do is Fusebox and I have never run into this. Or is this more on Shared Hosts? My server is a dedicated box.

Jeff

On Dec 15, 2009, at 8:44 AM, Barney Boisvert wrote:

Running multiple instances of CF on a single machine is a trivial
exercise. Windows has had support for more than 4GB of RAM, even on
32-bit systems, for quite some time, so you can easily run a bunch of
CF instances on a single Windows machine and spread your applications
out a bit RAM-wise.

Just to be clear about your example, when you load 15 apps with
several hundred circuits each it eats up almost all of your 1.1GB
allotment. Assuming CF itself consumes ~250MB, that leaves over 50MB
of RAM utilized by each application. Do you have any information
about how much of that is FB versus your application itself (CFC
instances, etc.)? Do those numbers mesh when you only spin up a
single app (you get 1/15th the usage)?

I wasn't alluding to switching from FB to another framework; I was
just wondering if FB was actually a memory hog. Obviously making it
more memory efficient is desirable, but if other frameworks have
similar memory usage profiles, it might be worth examining best
practices for them to see what we might do better from an APPLICATION
development perspective, since I don't hear them complaining about
memory nearly as much as FB developers. That could also be that FB's
footprint has grown dramatically, while Mach-II and MG have always
been users of significant memory.

As for storing the verbs, you can avoid doing that if you do a full
generation of all parse files, otherwise you're stuck rereading the
XML every time you get a request to a fuseaction that you don't have a
parse file for. But Sean's the guy for this stuff; he wrote it, and
knows more about the guts than anyone else.

cheers,
barneyb

On Tue, Dec 15, 2009 at 3:26 AM, Jason Daiger
<jason@attendeeinter active.com> wrote:
>
>
> Barney Boisvert wrote:
>
> As such people would rather drop a hundred bucks on another GB of RAM
> versus upgrading their CPUs and/or having requests average slightly
> slower. In general, I'd agree with this compromise, though obviously
> it's not necessarily going to be the best one in every situation.
>
> This isn't really an accurate statement as adding more RAM does not equal more memory CF can use. At best on a Windows 32 bit machine you can push the 1.1+ GB memory limit for an instance of CF. On a 64 bit machine it's a little over 3.2+ GB but that doesn't really equal 3X the 32 bit machine but it's still an upper ceiling. If it were as easy as buying 16 GB of RAM and CF could use 15 of the 16 GB I would completely agree but this just isn't the case on the Windows environment.
>
> The issue of memory consumption has come up numerous times on the
> lists, but never with any substantial action towards detailing the
> problem or discussing a solution. I don't recall (though my memory is
> far from perfect) any hard numbers detailing memory consumption of a
> FB app of a specific size. That'd be the first thing to gather.
>
> Why? I can tell you w/out any fixed numbers FB 5.1 & 5.5.1 eat up almost all available memory on a 32 bit Windows machine w/ 1.1+ GB memory given to the CF instance when you try and load 15 apps w/ several hundred circuits. I know Mike is in the same boat as I am w/ his application. It's a real problem which exists. Also, I don't see how comparing it to other frameworks memory footprint provides much benefit. Neither Mike nor I are in a position to rewrite these apps so even if Mach II uses 1/10 of the memory footprint FB does, switching to Mach II would be a major investment which I don't think either of us can make at this time. It's better to fine tune the existing engine IMO.
>
> One way of reducing memory (at the expense of framework spinup time)
> would be to load the XML once, write out the parse files for
> everything (including inlining code for dynamic dispatch), and then
> forget all the state of the framework and just run the parse files. I
> don't think it's a good solution, but it would certainly meet the need
> and is implementable.
>
> I like this line of thinking but can't we try and meet in the middle (when in prod mode) where the core loads what it needs to parse the circuit and then releases this memory back rather than storing all the verbs? I recall Sean saying this would require a re-write of some major items in the core but I'm not sure why. Sean any chance we can have a dialog off-line to go over what's going on under the hood so that we might be able to tackle this issue? I just got our core app ported from 5.1 to 5.5.1 using the latest stable code and will try and make some time over the next few months to investigate/ work out a solution. But I definitely don't want to dive in w/out a bit more understanding of the core 1st.
>
> -Jason
>
>
>
>
>
>

... True. We are currently run 3 instances on each of our production servers and have spread the site load across these instances. ... A few years ago I

Message 9 of 14
, Dec 15, 2009

0 Attachment

Barney Boisvert wrote:

Running multiple instances of CF on a single machine is a trivial
exercise. Windows has had support for more than 4GB of RAM, even on
32-bit systems, for quite some time, so you can easily run a bunch of
CF instances on a single Windows machine and spread your applications
out a bit RAM-wise.

True. We are currently run 3 instances on each of our production
servers and have spread the site load across these instances.

Just to be clear about your example, when you load 15 apps with
several hundred circuits each it eats up almost all of your 1.1GB
allotment. Assuming CF itself consumes ~250MB, that leaves over 50MB
of RAM utilized by each application. Do you have any information
about how much of that is FB versus your application itself (CFC
instances, etc.)? Do those numbers mesh when you only spin up a
single app (you get 1/15th the usage)?

A few years ago I worked extensive w/ Charlie Arehart and the guys at
Integral on our issue and during that process we stripped out almost
all variables in application scope from my application. I'd say we are
probably less than 5 MB of application scope per site. Even that might
be a stretch to be honest. The rest is FB. Integral examined the raw
dump from the server and found 1,000's of do verb structures in
memory. And that's when it hit me that it was a server issue or an
application issue but a Fusebox issue. So yes, I have to assume given
rough numbers that FB was taking roughly 45MB per site. Do they mesh,
in general yes, but I've been (and continue to be) a little skeptical
of the memory #'s shown in the CF 8 Monitor.

As for storing the verbs, you can avoid doing that if you do a full
generation of all parse files, otherwise you're stuck rereading the
XML every time you get a request to a fuseaction that you don't have a
parse file for. But Sean's the guy for this stuff; he wrote it, and
knows more about the guts than anyone else.

I'm fairly certain this is not a correct statement but Sean could
correct me if I'm wrong. From my investigation into the core, FB still
stores the memory map of the application in memory (i.e. all the do
verbs) even if the parsed files exist.

But I'll put this out to the community. I'm willing to contract w/ an
individual and pay them (in real US dollars and not Amazon Wish List
items) to address this memory issue. The caveat is that the end
product must go back to the community and the person would need
to be 'blessed' by community (primarily Sean but certainly other active
members, such as Barney or even some of the other framework authors).

-Jason

Barney Boisvert

On Tue, Dec 15, 2009 at 10:51 AM, Jason Daiger ... Let me preface this by saying that I m NOT interested in the lead developer position for the Fusebox

> But I'll put this out to the community. I'm willing to contract w/ an
> individual and pay them to address this memory issue. The caveat
> is that the end product must go back to the community and the
> person would need to be 'blessed' by community.

Let me preface this by saying that I'm NOT interested in the "lead
developer" position for the Fusebox framework. Reread that. Thanks.

I'd be interested in having a go at streamlining the framework's
memory profile. I agree that it's rather bloated, and it seems that
there is lots of room for improvements. I also happen to be in a spot
where I have a bunch of free time coming up and have a need for some
extra cash. :) I'd much rather do something of benefit to a lot of
people (myself included), even with all the extra stuff that entails.

I would also have a couple stipulations:

1) the code would live in a branch in SVN (or in a separate
repository), not the trunk.

2) the community will contribute some real-world FB apps (I'd be happy
to sign NDAs or whatever) to do testing with. Ideally they'd be
things that I can actually run, but I'd be happy to chip in time to
replace database and third-party access with mocks so they can be
executed in a "dummy" fashion (since what we care about is just the
Fusebox itself). I assume Jason would be willing to contribute an app
or three, and I have a couple I can use (20-50 circuit size) as well,
but I'd want to get at least two other authors' projects, including
XML-centric, convention-centric, and CFC-centric samples. This has
happened in the past from the community to Adobe for testing
ColdFusion, so there is precedence.

3) failure is an option, and at various levels. Obviously a vast
reduction of memory usage, increase in performance, and no backwards
compatibility changes would be ideal. It seems to me that little
tweaks to the FB language itself are probably worth significant memory
savings, but that's not my decision. This is the major reason for not
wanting to do trunk development, as someone else needs to weigh this
type of situation if it were to arise.

4) I'm only touching the CFML core files, and I'll be doing
development on ColdFusion 8 and Railo 3.1 on Linux (CentOS/RedHat). I
will ensure CF9-on-Windows compatibility (as a OS spot check and to
ensure CF9 didn't break anything), but that's it. Another reason I
don't want the trunk.

If this were to yield fruit, I'd be more than happy to assist in
packaging a formal release (platform testing, compatibilty assurances,
etc.), but that's a different task, and one that brings in a whole
suite of potential political issues.

>
>
> Barney Boisvert wrote:
>
>
>
> Running multiple instances of CF on a single machine is a trivial
> exercise. Windows has had support for more than 4GB of RAM, even on
> 32-bit systems, for quite some time, so you can easily run a bunch of
> CF instances on a single Windows machine and spread your applications
> out a bit RAM-wise.
>
> True. We are currently run 3 instances on each of our production servers and have spread the site load across these instances.
>
> Just to be clear about your example, when you load 15 apps with
> several hundred circuits each it eats up almost all of your 1.1GB
> allotment. Assuming CF itself consumes ~250MB, that leaves over 50MB
> of RAM utilized by each application. Do you have any information
> about how much of that is FB versus your application itself (CFC
> instances, etc.)? Do those numbers mesh when you only spin up a
> single app (you get 1/15th the usage)?
>
> A few years ago I worked extensive w/ Charlie Arehart and the guys at Integral on our issue and during that process we stripped out almost all variables in application scope from my application. I'd say we are probably less than 5 MB of application scope per site. Even that might be a stretch to be honest. The rest is FB. Integral examined the raw dump from the server and found 1,000's of do verb structures in memory. And that's when it hit me that it was a server issue or an application issue but a Fusebox issue. So yes, I have to assume given rough numbers that FB was taking roughly 45MB per site. Do they mesh, in general yes, but I've been (and continue to be) a little skeptical of the memory #'s shown in the CF 8 Monitor.
>
> As for storing the verbs, you can avoid doing that if you do a full
> generation of all parse files, otherwise you're stuck rereading the
> XML every time you get a request to a fuseaction that you don't have a
> parse file for. But Sean's the guy for this stuff; he wrote it, and
> knows more about the guts than anyone else.
>
> I'm fairly certain this is not a correct statement but Sean could correct me if I'm wrong. From my investigation into the core, FB still stores the memory map of the application in memory (i.e. all the do verbs) even if the parsed files exist.
>
> But I'll put this out to the community. I'm willing to contract w/ an individual and pay them (in real US dollars and not Amazon Wish List items) to address this memory issue. The caveat is that the end product must go back to the community and the person would need to be 'blessed' by community (primarily Sean but certainly other active members, such as Barney or even some of the other framework authors).
>
> -Jason
>

ColdFusion is bloated and Fusebox may be as well but as Barney states: RAM is cheaper than both CPU and user wait time RAM is the best place to store objects

Message 11 of 14
, Dec 15, 2009

0 Attachment

ColdFusion is bloated and Fusebox may be as well but as Barney states: "RAM is cheaper than both CPU and user wait time"

RAM is the best place to store objects for price/performance. It is also cheaper than developer time.

I really hope I am wrong on this, but whoever takes on the task of reducing memory consumption of the current core may only be able to squeeze a bit more juice out out of it, but IMHO its not worth the effort at this point. At best you may be able to drop a few percent in memory consumption in ColdFusion.

If your starting to see performance issues with Fusebox then your probably hitting the limitations wall of having a standard ColdFusion (out of the box) deployment on Windows (or the OS of your choice). Only so much can be done at the code level in ColdFusion since a standard ColdFusion install is not in itself optimized to a run high performance hosted web application.

One thing the JVM can do really well is scale. If your deployment does not require Windows, you need to start looking at custom deployment options that will have the most efficient impact on your application performance.

... No worries. We have a fixed goal and should stick to that goal. No more, no less ... I can definitely assist on this front. ... We have to work on you

Message 12 of 14
, Dec 15, 2009

0 Attachment

Barney Boisvert wrote:

Let me preface this by saying that I'm NOT interested in the "lead
developer" position for the Fusebox framework. Reread that. Thanks.

No worries. We have a fixed goal and should stick to that goal. No
more, no less

2) the community will contribute some real-world FB apps (I'd be
happy
to sign NDAs or whatever) to do testing with.

I can definitely assist on this front.

3) failure is an option, and at various levels.

We have to work on you sales tactics. ;) Contact me off list
(jason@...) to discuss the next steps.

-Jason

Jason Daiger

... RAM is not a magical elixir though. ... It s definitely worth it to someone, namely me, which is why I m willing to pay to have it done. For me, a 50%

Message 13 of 14
, Dec 15, 2009

0 Attachment

Gavin McLelland wrote:

RAM
is the best place to store objects for price/performance. It is also
cheaper than developer time.

RAM is not a magical elixir though.

I really hope I am wrong on this, but whoever takes on the task
of reducing memory consumption of the current core may only be able to
squeeze a bit more juice out out of it, but IMHO its not worth the
effort at this point. At best you may be able to drop a few percent in
memory consumption in ColdFusion.

It's definitely worth it to someone, namely me, which is why I'm
willing to pay to have it done. For me, a 50% reduction in memory
could mean the difference between maintain 3 possibly 4 servers vs 2.
The additional license fees and monthly hosting and maintenance costs
alone add up very quickly and that's before you put staff time into the
equation.

If your starting to see performance issues with Fusebox
then your probably hitting the limitations wall of having a
standard ColdFusion (out of the box) deployment on Windows (or the OS
of your choice).

Sorry but I don't believe I'm hitting that wall yet. When I do, then
I'll consider my next step which is moving off of Windows as the server
environment.

-Jason

Sean Corfield

... That s a Windows limitation with Java. It is not a limitation of Java on *nix nor of ColdFusion itself. ... Yeah, I m kinda swamped. Part of the problem is

There's a hard limit on memory -- in CF7 and lower at least, not sure about CF8+ -- of around 2GB, maybe less, for a server instance. If you try to set it higher, the server simply won't start up at all.

That's a Windows limitation with Java. It is not a limitation of Java on *nix nor of ColdFusion itself.

I believe he mentioned in an earlier discussion that he actually had some ideas in this direction, but we never got around to having a good discussion on them, which is why I started this thread.

Yeah, I'm kinda swamped.

Part of the problem is that Fusebox doesn't know what mode it is in until it has read the fusebox.xml file. So it has to read that file - but that file alone isn't a big memory hog, even with fully realized objects for everything - except the circuits themselves. My first plan of attack for resolving memory issues would be to make circuit parsing "lazy" so that a circuit is only loaded / parsed if the requested parsed file doesn't exist (or it is in development mode).

That would allow an application to be fully generated and put into production mode and never load any of the in-memory objects, unless someone requests an unknown fuseaction (and even then it would only load one circuit).

The next part - which would benefit folks in development mode too since it would not only reduce memory usage but also make parsing faster I think... - would be to effectively "denormalize" the verb object(s) so there is just one methods-only object for handling verbs and the actually data of each verb is parsed to a simple struct instead of a full CFC. That would use a lot less memory (but make the framework code bigger / more complex).