XSP Precaching

[Jörg Walter <jw...@garni.ch>]

Hi!

I have a working, minimal intrusive and documented patch to add preloading of 
compiled XSP pages. It appends one line to the XSP perl code, a subroutine 
call to tell XSP.pm the true mtime of the page, and it adds that sub to 
XSP.pm, which simply enters the given value as $cache->{$key}{mtime}. 
Everything else is encapsulated in a separate module. See attached diff and 
module. It doesn't change any behaviour, not even when preloading is used - 
modified files are still reparsed.
It greatly improves XSP response time on more complex pages. Some of my test 
pages take 10 seconds on a mildly loaded 300MHz K6 to eval(), plus 5 seconds 
to parse XML->perl. (This is my devel server, don't laugh :-) Afterwards, 
there is just 1sec execution time, the other two are cut to zero.

The diff also fixes (or rather, unifies) caching behaviour for 
XSP-after-$something. Before, an XSP page generated out of 
pnotes('xml_string') was cached in-memory unconditionally, while those from 
pnotes('dom_tree') were never cached in-memory. With this patch, both types 
are now left in-memory as long as the source XML file doesn't change. This is 
in line with XSP-as-first-step, as we have recently seen on axkit-users 
(XIncludes are not consulted for XSP cache expiry). This does change axkit 
behaviour, yet makes it more consistent and predictable.

What do you think of both patches?

-- 
CU
   Joerg

Re: XSP Precaching

[Kip Hampton <kh...@totalcinema.com>]

Jörg Walter wrote:
> Am Tuesday, 23. September 2003 09:39, schrieb Matt Sergeant:
>>Is there any value in making the pre-load module a separate module on
>>CPAN?
> 
> Given that Preload.pm essentially only is 10 lines + docs, probably not...
> 
+1 to putting it in the core dist.

-kip

Re: XSP Precaching

[Jörg Walter <jw...@garni.ch>]

Am Tuesday, 23. September 2003 09:39, schrieb Matt Sergeant:
> Ah yes, now I see why.
>
> In that case I'm +1.
>
> Is there any value in making the pre-load module a separate module on
> CPAN?

Given that Preload.pm essentially only is 10 lines + docs, probably not...

-- 
CU
   Joerg

Re: XSP Precaching

[Matt Sergeant <ma...@sergeant.org>]

On 23 Sep 2003, at 8:23, Jörg Walter wrote:

> Am Monday, 22. September 2003 23:48, schrieb Matt Sergeant:
>> On 22 Sep 2003, at 12:05, Jörg Walter wrote:
>>> I have a working, minimal intrusive and documented patch to add
>>> preloading of
>>> compiled XSP pages.
>>
>> Interesting. Is there no way to automate this better - such as
>> providing a path to XSP's you want pre-compiled, and then have them
>> compiled automatically at server startup? That would seem more 
>> sensible
>> to me. But maybe the design of XSP.pm isn't clean enough to support 
>> it?
>
> Well, it would mean to duplicate a full AxKit environment at run time.
> ConfigReader, $r, possibly the cache including a correct key, loaded 
> taglibs
> and everything - would be a bit of work, and error-prone, IMHO.
> The current way, you get an error message when a loaded module is 
> missing -
> what you saw is exactly what you get. When parsing at startup time, you
> probably only notice a taglib was missing after you executed a code 
> path
> using that missing taglib - and sometimes even that wouldn't be 
> obvious.

Ah yes, now I see why.

In that case I'm +1.

Is there any value in making the pre-load module a separate module on 
CPAN?

Matt.

Re: XSP Precaching

[Jörg Walter <jw...@garni.ch>]

Am Monday, 22. September 2003 23:48, schrieb Matt Sergeant:
> On 22 Sep 2003, at 12:05, Jörg Walter wrote:
> > I have a working, minimal intrusive and documented patch to add
> > preloading of
> > compiled XSP pages.
>
> Interesting. Is there no way to automate this better - such as
> providing a path to XSP's you want pre-compiled, and then have them
> compiled automatically at server startup? That would seem more sensible
> to me. But maybe the design of XSP.pm isn't clean enough to support it?

Well, it would mean to duplicate a full AxKit environment at run time. 
ConfigReader, $r, possibly the cache including a correct key, loaded taglibs 
and everything - would be a bit of work, and error-prone, IMHO.
The current way, you get an error message when a loaded module is missing - 
what you saw is exactly what you get. When parsing at startup time, you 
probably only notice a taglib was missing after you executed a code path 
using that missing taglib - and sometimes even that wouldn't be obvious.

-- 
CU
   Joerg

Re: XSP Precaching

[Matt Sergeant <ma...@sergeant.org>]

On 22 Sep 2003, at 12:05, Jörg Walter wrote:

> I have a working, minimal intrusive and documented patch to add 
> preloading of
> compiled XSP pages.

Interesting. Is there no way to automate this better - such as 
providing a path to XSP's you want pre-compiled, and then have them 
compiled automatically at server startup? That would seem more sensible 
to me. But maybe the design of XSP.pm isn't clean enough to support it?