Hey Aaron, One thing you can do is run one of the file fetches in profile mode on a test server with a replica of the database after clearing cache.
So, say you have a test server and can reproduce it there with that diff after restarting memcached every time. You'll then want to go into the Admin UI -> Settings -> Logging and enable profiling. Then restart Apache (there's a bug where the setting doesn't always take effect -- we think that's fixed in 1.0.6). The diff viewer progressively loads the diffs, so getting the timing for the diff viewer page itself is useless. What you'd now need to do is use the Firebug extension for Firefox to first see which requests it's making and how long they're taking. Once you've chosen one, open that URL in the browser. Now clear memcached again to make sure we're not going to pull any of this from cache. Then tack on ?profiling=1 to that URL and go there. Once this is done, SSH to the server and go to your logs directory. There should be a reviewboard.prof that contains profiling information on the code and also the SQL queries. Go ahead and send me that and I can help figure out where things are going wrong. It is possible that it's just the size of the diffs combined with too much load on the server. All I could do right now is guess, though. However, 20 minutes is just excessive and scary. I certainly haven't seen that myself yet. The possible bottlenecks I can think of are: 1) Fetching the file from the repository 2) Performing the diff between the original file and the patched file 3) Applying syntax highlighting. What file type was it? We haven't tested with files containing a BOM. It's possible something breaks from it. We'd have to test it. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, Apr 2, 2010 at 3:50 PM, Aaron Sherman <a...@ajs.com> wrote: > We have an RB instance with a Perforce back-end. We see some log > entries that suggest VERY long response times for diffs. Now, to be > fair, these are very rare, but they seem to be centered on reviews > that are tied to many-thousand-line diffs. On the Perforce server > logs, we don't see these long times anywere. In fact, every request > from RB is serviced in a few seconds at most. Meanwhile I've seen 20 > minute response times on some requests such as this one: > > 10.xxx.xxx.xxx - - [29/Mar/2010:09:25:16 -0700] "GET /r/138017/diff/ > HTTP/1.0" 200 391661 > > So, what I'm wondering is: > > * Is there a good way to track this sort of thing down? > * If the revision control system isn't seeing this, what's a likely > culprit? > * When does RB talk to the revision control system? > > I did visit these reviews myself, and the first time, it did hang on > loading 2 of the 6 diffed files for me, but I've been unable to > reproduce that since. The two files it hung on were both quite large > and (I have no idea if this is relevant) contained a leading BOM > marker (http://en.wikipedia.org/wiki/Byte_order_mark); would that > cause any problems? > > -- > Want to help the Review Board project? Donate today at > http://www.reviewboard.org/donate/ > Happy user? Let us know at http://www.reviewboard.org/users/ > -~----------~----~----~----~------~----~------~--~--- > To unsubscribe from this group, send email to > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/reviewboard?hl=en > > To unsubscribe, reply using "remove me" as the subject. > -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~----------~----~----~----~------~----~------~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
