Loading ...
Sorry, an error occurred while loading the content.

Getting the conversation going again

Expand Messages
  • jordanreiter
    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?

        --- 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.
        >
        >
        >
        > ------------------------------------
        >
        > 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.

            cheers,
            barneyb

            On Tue, Dec 15, 2009 at 12:01 AM, Matthew Gersting
            <mattgersting@...> 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@...> 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.
            >>

            --
            Barney Boisvert
            bboisvert@...
            http://www.barneyb.com/
          • Jason Daiger
            ... 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.

                cheers,
                barneyb

                On Tue, Dec 15, 2009 at 3:26 AM, Jason Daiger
                <jason@...> 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
                >
                >
                >
                >
                >
                >


                --
                Barney Boisvert
                bboisvert@...
                http://www.barneyb.com/
              • jordanreiter
                ... 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 :

                    Free Allocated Memory: 743mb
                    Total Memory Allocated: 1012mb
                    Max Memory Available to JVM: 1012mb

                    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
                    >
                    >
                    >
                    >
                    >
                    >

                    --
                    Barney Boisvert
                    bboisvert@gmail. com
                    http://www.barneyb. com/


                  • Jason Daiger
                    ... 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
                      Message 10 of 14 , Dec 15, 2009
                      • 0 Attachment
                        On Tue, Dec 15, 2009 at 10:51 AM, Jason Daiger
                        <jason@...> wrote:
                        > 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.

                        cheers,
                        barneyb

                        On Tue, Dec 15, 2009 at 10:51 AM, Jason Daiger
                        <jason@...> wrote:
                        >
                        >
                        > 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
                        bboisvert@...
                        http://www.barneyb.com/
                      • Gavin McLelland
                        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.

                          Cheers,
                          --
                          Gavin McLelland
                        • Jason Daiger
                          ... 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
                              Message 14 of 14 , Dec 15, 2009
                              • 0 Attachment
                                On Tue, Dec 15, 2009 at 8:33 AM, jordanreiter <jordanthecoder@...> wrote:
                                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).
                                --
                                Sean A Corfield -- (904) 302-SEAN
                                Railo Technologies US -- http://getrailo.com/
                                An Architect's View -- http://corfield.org/

                                "If you're not annoying somebody, you're not really alive."
                                -- Margaret Atwood
                              Your message has been successfully submitted and would be delivered to recipients shortly.