Glad to see you are doing some good experimentation to optimize performance, way to go. You're gonna need it with a 700MHz machine. My old machine is a 700Mhz Pentium III. Most of Magma was coded on that, but now I have machine 3X faster (1.3Ghz Pentium-M). I've used that 700 a couple of times since then and.. its a dog.. :)
Reading in the front pier page with some text in it. minimumDepth: 0 takes 45 readGraph operations in: 3408ms minimumDepth: 1 takes 45 readGraph operations in: 4973ms.
I'll be curious if you discover a good "ReadStrategy" strategy. Based on limited testing, my impression is, for best performance, try to retrieve "chunky" objects (like maybe one pier page) in one gulp. I'm not sure what "45 readGraph operations" is but, if that is 45 proxy's materialized, is there any way you can cut it down to <5, ideally 1.
When the user is done with a page, stub it out to save memory and Magma can maintain reasonably small dictionary's.
- Chris
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.
magma@lists.squeakfoundation.org
-
Chris Muller -
Keith Hodges