Magma + Pier performance

[Keith Hodges]

Following Chris' advice to implement a read strategy, I thought I would 
give it a go.

In the first stages of optimising Magma to serve pier pages.

the figures are pretty bad without a readStrategy. I put a test 
'information' page page 10 levels down the url path, and following a 
rendering of that page we get the last item in the log at:

*401 [14141] Read(100) *'<b>Test Suites:</b> Pier is heavily tested. 
There are more than 1000 ...etc...
*402 [14147] Read(101) *'</td></tr></table>'

That is 101 proxy materialisations in 14.1 seconds. If you add the 10 
seconds that it takes to obtain a MagmaSession (in the non-shared 
WAMagmaSession) then that is a long time to wait for a web page. 
(WAMagmaSharedSession is pre-cached).

not so good!

After carefully  implementing a readStrategy

The final lines of the log now look like this!

*312 [311] Read(3) *a PRDocument
...
...
*367: [335] (7/7/8) PRText-text = '<b>Test Suites:</b> Pier is heavily 
tes...etc...*
 

That is 3 reads, which take ~30-80ms to apply the read strategy and 
~100ms to fetch from magma, each. Since the final read has not actually 
happened at the time of this last log item, I make that roughly 430ms to 
retrieve everything in this test page.

The first read retrieves the whole path skeleton in one hit (not 
entirely necessary)
The second read retrieves the 'environment' document which pier uses as 
its display and style template. The third read retrieves the desired 
document, again in one hit.

In practice it is likely that the 'path skeleton' and the 'environment'  
will remain cached in memory,  so in general use,  100-150ms, to  serve 
a page from Magma to Pier isnt bad going especially as compared to the 
non-optimised results.

Keith

p.s. this is on a 700Mhz Pentium 3 machine with old slow 10G disk drives.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20060921/a1599e0f/attachment.htm