Thanks for the detailed information. I had originally thought this was an
issue browser-side with too much content in the DOM, but it's load times of
fragments.
I have a patch up for review (http://reviews.review-board.org/r/757/) that
you can test. I'll be testing it a bit more and then
Great, thanks! I will test as soon as I can.
It's probable we may still have some lesser perf issues remaining even
with this fix because it's a common enough use case here for folks to
create comments on many, many different lines of codes in the same
review. This should I hope bring the load
I'm trying to use instructions in documentation for grabbing a nightly
(yes I know my fix won't be ready till later :) but I cannot get it to
work. Any suggestions?
Here is relavent debug output from easy_install:
$ sudo easy_install -v -n -f http://www.review-board.org/downloads/nightlies/
The problem is the -f flag. You just want to pass the filename. -f expects
an html page that it can scan links from.
You'll also need to make sure you grab the latest Djblets.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. -
Results for question #2:
I installed FireBug and setup the console to show logging. I then
brought up one of the reviews that has been a problem for us and
showed hundreds of HTTPS GET requests for diff comments, each taking
about ~200-300 milliseconds. It took ~6 minutes to fully load the
page.
Results for question #3:
I createed a reviewrequest with just one review with many comments and
it does not have the same performance issues. Additionally, in FireBug
the review is only showing one HTTPS GET request. In this test all the
comments and the review itself was made by just one user
More info regarding question #3:
The performance problem is reproducable by creating comments on
multiple different line numbers of the diff. Each line diff comment
results in a seperate HTTPS GET request when the page is loaded. These
are what the GET requests look like (in FireBug):
Firebug's
I was able to roll back to Alpha1 but ReviewBoard displayed the same
problem... an unresponsive/seriously slow GUI for reviews with 150+
comments. I also upgrade to Alpha4 with the same results.
Our company cannot use ReviewBoard with this serious performance
handicap.
We've been very happy
Thank you for your reply. The slowness is:
1. page load takes several minutes (the more comments, the longer it
takes)
2. typing a comment is very slow on reviews with many comments.
3. Scrolling on the review page is painful when many reviews
Developers are speculating its due to a huge DOM and
Perhaps we need to paginate the reviews page in addition to the diff?
-David
On Fri, Mar 6, 2009 at 2:03 PM, mary ciaom...@gmail.com wrote:
Thank you for your reply. The slowness is:
1. page load takes several minutes (the more comments, the longer it
takes)
2. typing a comment is very
Yes, I mean comments not reviews.
I'm seeing the same issues on Alpha4 on my test server. It seems to me
that the loading of the diff fragments across all the comments is
causing our problems - loading such a review sometimes crashes the
browser (i've seen this on firefox mostly) and in IE the
We'd have to decide what we're doing to fix this first. Depending on what
that is, it could take a few days to implement, or longer. We can make it a
priority for beta 1 (the next release), and of course you'd be able to just
upgrade to a nightly once it's in.
Short-term, I'd just advise
When you hit this problem with large numbers of comments, how many reviews
are they usually spread across? Solving the problem of large numbers of
comments across multiple reviews is very different from large numbers of
comments on one review.
Christian
--
Christian Hammond -
Thank-you for making this a priority! I'll keep an eye out for the fix
and grab immediately.
Breaking up the reviews into smaller pieces is not a use case that is
going down well here, but it is known. thanks again!
On Mar 6, 2:54 pm, Christian Hammond chip...@chipx86.com wrote:
We'd have to
A couple more questions. I'm playing around with a couple possible fixes,
but need to find out more where the bottleneck is. Clearly it's
browser-side, but the question is whether it's the fact that there's a lot
in the DOM or whether the rendering is the slow part.
1) Is the page still slow once
answers inline below...
On Mar 6, 3:52 pm, Christian Hammond chip...@chipx86.com wrote:
A couple more questions. I'm playing around with a couple possible fixes,
but need to find out more where the bottleneck is. Clearly it's
browser-side, but the question is whether it's the fact that
Thanks for the quick response. I'll be interested in seeing the results.
I'm working on code now that should address these issues (though some
further decisions will be made based on #2 and #3).
Essentially, we're looking at expanding/collapsing reviews based on the
following logic:
For each
Hi,
Since upgrading to Alpha2 many of our users have been reporting
seriously slow response times sporadically on the review pages. This
is making the GUI nearly unusable for some users. One page
specifically is the popup Review comment box. This does not appear to
be network related and so I
Thanks for the information, I will try it on my test server (and yes,
I will keep in mind DB changes for future).
I've also been having a hard time reproducing the issues that many are
reporting but I will continue to try and gather information. The
problems are being reported using both IE7 and
19 matches
Mail list logo
