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.