I've looked through the OpenBD/GAE code and run some tests in my local development environment, and I don't see any place where calls are routinely made to memcache/datastore when loading cfm pages or cfc files (the file cache is stored in local memory--not memcache--so setting "trusted cache" should have no effect). Some thoughts:
- Is it possible to get additional information via AppStats about where the memcache/datastore calls are coming from? Can it provide a full or partial stacktrace when these occur? I wonder if it's something "below" the OpenBD code within the GAE APIs that's making these calls, such as session scope access. - Is is possible that the FW/1 framework is doing something (invoking some CFML code) that's causing these memcache/datatore reads? Can you try some code that's not using FW/1 and see if you get the same results? Vince On Wed, Jun 2, 2010 at 12:36 PM, Edward Smith <[email protected]>wrote: > I turned on AppStats to try to get a sense of how to optimize my > prototype application, and I'm seeing something problematic. > > It appears that OpenBD is doing a memcache/datastore get for each cfm > or cfc in the execution stack. > > I guess I understand why that might be happening, but its a serious > performance issue in that each "file" takes minimum 30-40ms. > > In any typical CF application of any appreciable complexity, you're > going to have a dozen or two (or more) files in the stack. It appears > to do this for a cfc's full inheritance stack as well, so if you've > got a couple CFCs that have, maybe, 2 parent layers of inheritance, to > load those 2 cfcs, you're actually doing 6 of these memcache/datastore > loads at 40ms each. > > I've turned on "trusted cache" and it still seems to do this for every > request. I've also turned off debugging, etc. > > So, my FW/1 App that calls a single controller method, a single view, > and a single layout, and a few service CFC's (that put and get a > single CFC to the datastore) takes about 1200ms which is mostly the > memcache/datastore accesses for the actual .cfm files. > > So, my basic question is this: > > Is it possible to prevent this behavior, or at least to mitigate it > through some configuration? Or is this just totally inherent in the > way OpenBD (or any other CF engine) works? > > Could I 'pre-compile' stuff so that this doesn't happen? > > If not, this is going to dictate an interesting application > development strategy: put everything in the application.cfc. > > -- > Open BlueDragon Public Mailing List > http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon > mailing list - http://groups.google.com/group/openbd?hl=en > > !! save a network - please trim replies before posting !! -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon mailing list - http://groups.google.com/group/openbd?hl=en !! save a network - please trim replies before posting !!
