> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flexwiki- > [EMAIL PROTECTED] On Behalf Of Craig Andera > Sent: Tuesday, September 18, 2007 10:22 AM > To: 'FlexWiki Users Mailing List' > Subject: Re: [Flexwiki-users] Very early performance info for //wiki > > 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?
I wouldn't do it yet. Having pages that are ten times slower is just beyond reasonable. While it's a small percentage of the corpus, for the people that use those pages it would be pretty unworkable. The 2...n pages are better than I expected (given the lack of a general caching system) but still are too slow in some cases. > * If not, where do we need to be before you can? I think I need to do a bit more of this measurement before answering. I want to trim out the quick pages (less than e.g., 1 second regardless of how much slower they are as a percentage). Also, I want to get the latest 2.0 code. Then, of course, will come the hard part of looking at the biggest problem pages (which may well number hundreds) and figuring out what's actually going on. > * 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. I'll try to look at that, though each test is fairly onerous for me since there are 1000 namespaces. Would you be able to tell the difference in performance in a meaningful way by just looking at a hundred pages? > 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. That's great. Have you thought about (and would it be easy) to start to drive some perf tests in the regression suite? > 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 sounds like a very promising approach. > 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. I don't think reflection is the issue. With WikiTalk under 1.8 the first render can take a while, but after that it's typically cached. [insert perennial discussion here] > > -----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 I've mentioned before, there's 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. I've started this testing and I'm 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 I'm going to > be > > doing a new run overnight tonight (yes it takes a few hours) to get > > Craig's latest perf changes. > > > > Also, one of the things I'm going to do next is probably filter out > all > > pages that take less than a second on the theory that we don't' > 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 ------------------------------------------------------------------------- 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
