> This helped out my problem quite a bit... an order of magnitude or > so... went from about 35k ms to 3.5k ms... still about twice what 1.8 > is or 2.0 is w/out any wikitalk. > > Is this inline with what you were expecting?
It's consistent with the boost we saw for the last round of caching I did. Which is to say we seem to do about 10x better with caching than without it. Not that we've gotten 100x better overall: your page was very specifically doing one type of query repeatedly that was resulting in a lot of I/O. I just ran another set of tests that I have to analyze, but honestly I probably won't play with them too much, because the other scenarios that people have identified just mean that I still have more to do. I figure I'll just add caching for the five or so pieces of information the content provider pipeline deals with and see where it gets us. I'm hopeful that it'll be as fast or faster than 1.8, but we'll have to see. The problem is that if the type of caching I'm doing now doesn't work, it could potentially add a *lot* of complexity to do any better. But as always it'll be a case of "profile and fix the slowest thing". One interesting thing that my tests *have* turned up is that FlexWiki 1.8 gets *slower* over time. I.e. the third retrieval of a page generally takes longer than the first. I don't have any solid evidence as to why, but at least I haven't observed the same behavior in 2.0. Of course, it does make performance comparisons tricky at best. :) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flexwiki-users
