Very interesting data indeed! I'm not at all surprised to see that response times are slower on the first hit - there's a fair amount of I/O while the cache is being populated, and 2.0 does more I/O in general than 1.8 due to the rearchitecture.
A couple of things: * Based on these statistics, would you or would you not upgrade the wiki to 2.0? Or is it too early to tell? * If not, where do we need to be before you can? * I'd love to see these rerun under the current code both with and without security disabled. There's a namespace parameter security.disabled that can be set to "true" to turn off the authorization provider, and I think it might make things a fair amount faster, as the security implementation is by its nature fairly heavy-duty. I haven't had a chance to test the effect myself. It'll be very interesting to see what difference the latest code changes make. I expect them to have a fairly significant impact, though. And I think I've got a pretty good profiling story in place now (the RenderDriver tool I wrote plus the free nprof), so if we need to look at what's slowing down a particular page, we're in a good position to do so. I have one more optimization I know I want to make: I'm going to try to speed up the authorization provider by adding per-request caching. My plan is to add a RequestContext class with a static Current property. The web app will need to define a new RequestContext on every request, and then after that the pipeline can use it to cache stuff for the duration of the request. Because the lifetime of this second cache is only one request, we shouldn't have any problems with security context changing on us. And because AuthorizationProvider has to do several fairly expensive computations on every request, this could be a fair savings. That said, my testing shows that dynamically executing WikiTalk is far and away the slowest thing in a typical page execution, so it's not clear that optimizing anything other than that is going to help very much. But hopefully we're at "fast enough" by that time. Because if not, I'm pretty close to out of ideas that don't involve rewriting the WikiTalk engine to not be reflection-based. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flexwiki- > [EMAIL PROTECTED] On Behalf Of David Ornstein > Sent: Tuesday, September 18, 2007 12:00 PM > To: FlexWiki Users Mailing List > Subject: [Flexwiki-users] Very early performance info for //wiki > > As Ive mentioned before, theres a large instance of FlexWiki running > here at Microsoft with over a thousand namespaces and over 20000 > topics. This is a valuable test bed to compare 1.8 versus 2.0 > performance. Ive started this testing and Im getting some early > results. > > I am looking at (1) how long it takes to return a page the first time > and (2) how long it takes for subsequent hits. > > First hit > o 10000 of 20000 pages when hit for the first time are slower in 2.0 > than 1.8 o Of these, on average 2.0 is three times slower o 2500 of > these 10000 are at least twice as slow under 2.0 as under 1.8 o 1600 of > these 10000 are at least three times as slow under 2.0 than 1.8 o 1200 > of these 10000 are at least four times as slow under 2.0 than 1.8 o 130 > of these are more than ten times slower under 2.0 than 1.8 > > Subsequent hits > o 1800 of 20000 pages are slower in 2.0 than 1.8 o Of these, on average > 2.0 is two times slower o 230 of these 1800 are at least twice as slow > under 2.0 as under 1.8 o 125 of these 1800 are at least three times as > slow under 2.0 than 1.8 o 50 of these 1800 are at least four times as > slow under 2.0 than 1.8 o 12 of these are more than five times slower > under 2.0 than 1.8 > > The 2.0 code base I ran against is about a week old, so Im going to be > doing a new run overnight tonight (yes it takes a few hours) to get > Craigs latest perf changes. > > Also, one of the things Im going to do next is probably filter out all > pages that take less than a second on the theory that we dont really > care that much about pages that are several times slower but are still > fast enough > > /David > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
