Mr. Forta, In other words, does the caching sytem that CF uses perform a cache per fusebox or a cache for each fuseaction? Thank you, and greatly in your debt. Don Sparks ------Original Message------ From: "Jeremy Allen" <[EMAIL PROTECTED]> To: CF-Talk <[EMAIL PROTECTED]> Sent: October 20, 2000 9:00:47 PM GMT Subject: RE: fusebox style: too much disk access? Peter that was more of a theoretical guess than an actual statement but I will reenforce it. My assumptions based on how C compilers work. There is a preprocessing phase for a individual page call. Step one, preprocess any individual CF template include any files into the template do anything else (syntax checking after the inclusion, before the inclusion) there are to many things to talk about so ill just stick to including files. After "pre processing" you now have a template to be interpreted. The next phase since we all know that CF "compiles" templates to PCode is to turn that template into PCode. So one Section of my site may have 10 fuses which is really just 10 seperate Compilations (10 different file configurations) Again most of this is theory if anyone actually knows I would love to hear it, im just taking some guesses here. At this point I can only state guesses since I am not entirely certain. Dave? Allaire people? Anyone care to comment on how this works. My guess is say you have 30 different combinations to CF that is just 30 different PCode compilations not so many to leave in memory. If it parses a template and finds it has changed or has a different combination of CFINCLUDES I imagine it just compiles a newer version. This is memory intensive but is what gives lightning fast runtimes even for fusebox stuff... Its a really good question actually Peter and one I have wanted someone to comment on every time I have mentioned this. BTW I realize the actual CFENGINE is much more complex I am just grossly simplfying it for my example. If that is not how it works I dont see how Fusebox and any application using a lot of CFINCLUDES can get away with working in an effecient manner. It somehow has to be translating the pages to PCode or using some method of caching or combinations thereof. Anyways someone enlighten us :) Jeremy Allen [EMAIL PROTECTED] -----Original Message----- From: Peter Theobald [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 4:47 PM To: CF-Talk Subject: Re: fusebox style: too much disk access? That's the best possible case for cacheing. If everyone is acessing the same file you can bet it will be in cache and will serve out quickly. Did I understand Jeremy Allen correctly that the CF server will compile the entire page to P-Code *with any included files* and cache it. How does it track the myriad of combinations when all of the <cfinclude>s are dynamic (inside CFIFs) and different files are included depending on the input and data? At 11:44 AM 10/20/00 -0400, Donald Sparks wrote: >Okay, I'm not concerned with cfincludes and those related issues. I am concerned with the handling of multiple requests on the index or "fusebox" page (i.e.) a single page. For example say I have 1,000 users on my site. If they are all accessing index.cfm as opposed to 20 to 30 different .cfm pages. How does this affect caching and does it produce any other problems. > >Thank you, >Don Sparks >not quite at the 32nd chamber of fusebox. > >----- Original Message ----- >From: "Steve Nelson" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Thursday, October 19, 2000 3:23 PM >Subject: Re: fusebox style: too much disk access? > > >> Don't be confused by what Nat is saying, a single "fuseaction" in a >> Fusebox application may only hit 5-8 files. It's really not that big a >> deal. >> >> Steve >> >> Nat Papovich wrote: >> > >> > A simple test of included files suggests that CF's internal file access >> > functions were pratically built with a cfinclude-heavy architecture in >mind. >> > Accessing dozens of files for a single page request is very quick. Out >of >> > 100 included files, you might notice a 10 ms increase than if you had >all >> > the code on the same page. Now that 10 ms performance hit gives you a >> > scalable, intelligible architecture. If you have any experience with >really >> > large sites, you know that the only safe way to scale a project is to >break >> > it into small "minute modules". >> > >> > All this is without mentioning CF's ability to cache templates >> > automatically. Accessing a file from RAM is basically instantaneous. >> > >> > If code scalability, readability, longevity, and understandability is >> > important now or will be important later, you need to adopt a structured >> > application methodology like Fusebox. >> > >> > Nat Papovich >> > ICQ 32676414 >> > "I'm for truth no matter who tells it." >> > -Malcolm X, 1965 >> > >> > -----Original Message----- >> > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]] >> > Sent: Thursday, October 19, 2000 1:00 PM >> > To: CF-Talk >> > Subject: fusebox style: too much disk access? >> > >> > I was reading on the fusebox concept of putting minute modules into >separate >> > files and the question is: wouldn't that slow the site by having to >access >> > too many different disk files to load one page? >> > >> > Cyrill >> > > > > >--------------------------------------------------------------------------- --------------------- >Archives: http://www.mail-archive.com/[email protected]/ >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] --------------------------------------------------------------------------- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 x204 Fax 1.212.545.0938 ---------------------------------------------------------------------------- -------------------- Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] ------------------------------------------------------------------------------------------------ Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] ------------------------------------------------------------------------------------------------ Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
