From: Alex B. <en...@tu...> - 2001-08-03 16:34:55
|
> Hi Alex, > >>> Hmm. What about POST parameters and sessions? So if a >>> resultpage for sess1 >>> is diferent from one of sess2 because it depends on userdata >>> AND post data. >> >> Well, the idea being that you don't want to cache pages that are session >> specific, or post specific. You could end up with a _huge_ set of cache >> files :) > > Hmm, that's right. But what is with the areas of a sessioned page that are > "static" navigation etc. that depends not on session/post data? I guess the > per module cache applies here? Module "navigation_bar" (static, cached), > module "signup_process" (dynamic, !cached) ? Am I right? Exactly: for things like that, you'd cache the module output, not the page output. I think people will end up caching module output more than "entire" page output - it's more useful. >> This isn't intended for form pages, session specific stuff, etc, as the > files are stored > in the filesystem, unencrypted. > Indeed, would be a HUGE security risk. > > Ok, I got it now :-) > >> This cache has nothing to do with zend's caching - it only caches page >> output - so if you have cached bc php, you'll see even _more_ of a >> performance jump. Zend cache does the actual bytecode... Actually >> - andi, do >> you have performance numbers for r2 on a zend cache-enabled box? >> I'd love to >> see 'em :) > There is a benchmark utility shipped with Zcache. I just run the standard > page of current bc cvs through it. And yeees, I am very surprised. > My average performance boost of my projects (with or without db access) is > around 200%, for bc... > > HARR HARR HARR MORE POWER! (see second mail) heheheheh cool! >> So there isn't really anything like "turn it off" because it isn't "on" >> unless you specifically request it :) > Very fine :-) > > So for a big sime on your face, read the post about "Zend Cache". k :) _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |