binarycloud-general

[binarycloud-general] page and module output caching

[Alex B. <en...@tu...>]

hi all,

I'm nearly done with a version of the Page class that can cache page output.
If I have time today, I'm going to extend that to support caching of
individual module output as well.

This is going to require a lot of testing to verify that the right material
is presented in all circumstances, but I'm seeing nice performance gains on
crappy debug-laden code already. (And, it's cool) :)

Right now, I'm generating page cache ids with:
    -Request URI (that includes the get string)
    -A defined variable name (from the page definition)
    -The value of that variable.

Cache Ids are an MD5 of that string. I think that works pretty well for
pages, I'm trying to decide what I want to enable for modules.

If anyone has suggestions for "caching parameters" they'd like incorporated,
please let me know asap as I'm writing the code today...

I'll check it in as soon as I've cleaned up some of the more ick debug
things I have floating around in it.

PEAR Cache is elegant, easy to use, fast as hell, and after some stupid
include path problems, working perfectly. I'm quite happy with the import
scheme, as well.

If you're building modules, I encourage you to take the time to look in
binarycloud/ext/pear/ - and make use :)

best,

_alex


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

RE: [binarycloud-general] page and module output caching

[Andreas A. <a.a...@th...>]

Hi Alex,

> Right now, I'm generating page cache ids with:
>     -Request URI (that includes the get string)
>     -A defined variable name (from the page definition)
>     -The value of that variable.

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.
But the script is the same, e.g. bc/user/htdocs/userinfo.php.
I'm not sure if it is neccessary to consider that. Currently I'm very
satisfied with Zend Cache but It is great and important to have a free
alternative in bc. But I hope this can be switched off !?

> I'll check it in as soon as I've cleaned up some of the more ick debug
> things I have floating around in it.
Ah cool. BTW: The chache example bc/user/htdocs/cache.php is missing in CVS
but included in Makefile.

_andi

Re: [binarycloud-general] page and module output caching

[Alex B. <en...@tu...>]

> Hi Alex,
> 
>> Right now, I'm generating page cache ids with:
>>     -Request URI (that includes the get string)
>>     -A defined variable name (from the page definition)
>>     -The value of that variable.
> 
> 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 :)

I'm thinking more for, say, a large tree of html documents generated from
xml with xsl: you want to do the "render" once and then be able to serve it
out to 8million people, etc. This isn't intended for form pages, session
specific stuff, etc, as the files are stored in the filesystem, unencrypted.
(me = security freak :)

> But the script is the same, e.g. bc/user/htdocs/userinfo.php.
> I'm not sure if it is neccessary to consider that. Currently I'm very
> satisfied with Zend Cache but It is great and important to have a free
> alternative in bc. But I hope this can be switched off !?

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

Also, note that you have to _explicitly_ request a page be cached, not the
reverse. (this will be the same for modules)

So there isn't really anything like "turn it off" because it isn't "on"
unless you specifically request it :)

>> I'll check it in as soon as I've cleaned up some of the more ick debug
>> things I have floating around in it.
> Ah cool. BTW: The chache example bc/user/htdocs/cache.php is missing in CVS
> but included in Makefile.

Really?

Oh!, crap. I know what that is. I'll do a synch right now.. danke :)

_alex


> _andi
> 
> 
> 
> _______________________________________________
> binarycloud-general mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-general
> 


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

RE: [binarycloud-general] page and module output caching

[Andreas A. <a.a...@th...>]

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?

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

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

andi

Re: [binarycloud-general] page and module output caching

[Alex B. <en...@tu...>]

> 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