Re: Rolling back to Alpha1

[Christian Hammond]

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. - http://www.vmware.com


On Tue, Mar 10, 2009 at 5:04 PM, mary  wrote:

>
> 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/
> ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg
>
> Searching for ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg
> Reading http://www.review-board.org/downloads/nightlies/
> ...
> Found link:
> http://www.review-board.org/downloads/nightlies/ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg
> Found link:
> http://www.review-board.org/downloads/nightlies/ReviewBoard-1.0alpha5.dev_20090310-py2.5.egg
> Found link:
> http://www.review-board.org/downloads/nightlies/django_evolution-0.0.0.tar.gz
> Reading
> http://pypi.python.org/simple/ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg/
> Reading
> http://pypi.python.org/simple/ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg/
> Couldn't find index page for 'ReviewBoard-1.0alpha5.dev_20090310-
> py2.4.egg' (maybe misspelled?)
> Scanning index of all packages (this may take a while)
> Reading http://pypi.python.org/simple/
> No local packages or download links found for
> ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg
> error: Could not find suitable distribution for Requirement.parse
> ('ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg')
>
> 
>
> I've tried various names to get the nightlies but nothing works. If I
> specify jsut "ReviewBoard" it only gets the latest released Alpha4:
>
>
>
> sudo easy_install -v -n -f
> http://www.review-board.org/downloads/nightlies/
> ReviewBoard
> Searching for ReviewBoard
> Best match: ReviewBoard 1.0alpha4
> Processing ReviewBoard-1.0alpha4-py2.4.egg
> ReviewBoard 1.0alpha4 is already the active version in easy-
> install.pth
> Installing rb-site script to /usr/bin
>
> Using /usr/lib/python2.4/site-packages/ReviewBoard-1.0alpha4-py2.4.egg
> Processing dependencies for ReviewBoard
> Finished processing dependencies for ReviewBoard
>
> 
>
> I suspect I'm just doing something stupid, I'm not very familiar with
> Python, easy install, etc.
>
> Thanks!
>
>
> On Mar 10, 4:11 pm, mary  wrote:
> > 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 time down a lot though.
> >
> > On Mar 10, 2:46 pm, Christian Hammond  wrote:
> >
> >
> >
> > > 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 committing it, so
> it
> > > should be in tonight's or tomorrow's nightly. This batches together the
> > > loads, so if you only have a total of, say, 5 files with comments on
> them,
> > > it'll only do 5 HTTP GETs, instead of the 150+ or whatever it's
> currently
> > > doing. Should lighten the load considerably on the client side and
> server
> > > side.
> >
> > > Christian
> >
> > > --
> > > Christian Hammond - chip...@chipx86.com
> > > Review Board -http://www.review-board.org
> > > VMware, Inc. -http://www.vmware.com
> >
> > > On Mon, Mar 9, 2009 at 11:28 AM, mary  wrote:
> >
> > > > 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 log limit has been reached. %S entries not shown.
> > > > Preferences
> > > > GET
> > > >
> https://reviewboard/r/3043/reviews/5911/fragment/diff-comment/9742/?1...
> >
> > > > 304 Not Modified
> > > >180ms   jquery-11.min.js (line 19)
> > > > GET
> > > >
> https://reviewboard/r/3043/reviews/5961/fragment/diff-comment/9789/?1...
> >
> > > > 304 Not Modified
> > > >48msjquery-11.min.js (line 19)
> > > > GET
> > > >
> https://reviewboard/r/3043/reviews/5964/fragment/diff-comment/9792/?1...
> >
> > > > I think I have probably provided enough information to show the
> > > > problem now.
> >
> > > > On 

Re: Rolling back to Alpha1

[mary]

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/
ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg

Searching for ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg
Reading http://www.review-board.org/downloads/nightlies/
...
Found link: 
http://www.review-board.org/downloads/nightlies/ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg
Found link: 
http://www.review-board.org/downloads/nightlies/ReviewBoard-1.0alpha5.dev_20090310-py2.5.egg
Found link: 
http://www.review-board.org/downloads/nightlies/django_evolution-0.0.0.tar.gz
Reading 
http://pypi.python.org/simple/ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg/
Reading 
http://pypi.python.org/simple/ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg/
Couldn't find index page for 'ReviewBoard-1.0alpha5.dev_20090310-
py2.4.egg' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
No local packages or download links found for
ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg
error: Could not find suitable distribution for Requirement.parse
('ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg')



I've tried various names to get the nightlies but nothing works. If I
specify jsut "ReviewBoard" it only gets the latest released Alpha4:



sudo easy_install -v -n -f http://www.review-board.org/downloads/nightlies/
ReviewBoard
Searching for ReviewBoard
Best match: ReviewBoard 1.0alpha4
Processing ReviewBoard-1.0alpha4-py2.4.egg
ReviewBoard 1.0alpha4 is already the active version in easy-
install.pth
Installing rb-site script to /usr/bin

Using /usr/lib/python2.4/site-packages/ReviewBoard-1.0alpha4-py2.4.egg
Processing dependencies for ReviewBoard
Finished processing dependencies for ReviewBoard



I suspect I'm just doing something stupid, I'm not very familiar with
Python, easy install, etc.

Thanks!


On Mar 10, 4:11 pm, mary  wrote:
> 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 time down a lot though.
>
> On Mar 10, 2:46 pm, Christian Hammond  wrote:
>
>
>
> > 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 committing it, so it
> > should be in tonight's or tomorrow's nightly. This batches together the
> > loads, so if you only have a total of, say, 5 files with comments on them,
> > it'll only do 5 HTTP GETs, instead of the 150+ or whatever it's currently
> > doing. Should lighten the load considerably on the client side and server
> > side.
>
> > Christian
>
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board -http://www.review-board.org
> > VMware, Inc. -http://www.vmware.com
>
> > On Mon, Mar 9, 2009 at 11:28 AM, mary  wrote:
>
> > > 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 log limit has been reached. %S entries not shown.
> > > Preferences
> > > GET
> > >https://reviewboard/r/3043/reviews/5911/fragment/diff-comment/9742/?1...
>
> > > 304 Not Modified
> > >                180ms   jquery-11.min.js (line 19)
> > > GET
> > >https://reviewboard/r/3043/reviews/5961/fragment/diff-comment/9789/?1...
>
> > > 304 Not Modified
> > >                48ms    jquery-11.min.js (line 19)
> > > GET
> > >https://reviewboard/r/3043/reviews/5964/fragment/diff-comment/9792/?1...
>
> > > I think I have probably provided enough information to show the
> > > problem now.
>
> > > On Mar 9, 11:00 am, mary  wrote:
> > > > 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 (myself.)
>
> > > > I will try some additional tests to provide additional information
> > > > unless you have enough information, let me know.
>
> > > > Thanks!
>
> > > > On Mar 9, 10:11 am, mary  wrote:
>
> > > > > Results for question #2:
> > > > > I installed FireBug and setup the console to show logging. I then
> > > > > brought up

Re: Rolling back to Alpha1

[mary]

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 time down a lot though.

On Mar 10, 2:46 pm, Christian Hammond  wrote:
> 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 committing it, so it
> should be in tonight's or tomorrow's nightly. This batches together the
> loads, so if you only have a total of, say, 5 files with comments on them,
> it'll only do 5 HTTP GETs, instead of the 150+ or whatever it's currently
> doing. Should lighten the load considerably on the client side and server
> side.
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.review-board.org
> VMware, Inc. -http://www.vmware.com
>
>
>
> On Mon, Mar 9, 2009 at 11:28 AM, mary  wrote:
>
> > 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 log limit has been reached. %S entries not shown.
> > Preferences
> > GET
> >https://reviewboard/r/3043/reviews/5911/fragment/diff-comment/9742/?1...
>
> > 304 Not Modified
> >                180ms   jquery-11.min.js (line 19)
> > GET
> >https://reviewboard/r/3043/reviews/5961/fragment/diff-comment/9789/?1...
>
> > 304 Not Modified
> >                48ms    jquery-11.min.js (line 19)
> > GET
> >https://reviewboard/r/3043/reviews/5964/fragment/diff-comment/9792/?1...
>
> > I think I have probably provided enough information to show the
> > problem now.
>
> > On Mar 9, 11:00 am, mary  wrote:
> > > 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 (myself.)
>
> > > I will try some additional tests to provide additional information
> > > unless you have enough information, let me know.
>
> > > Thanks!
>
> > > On Mar 9, 10:11 am, mary  wrote:
>
> > > > 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.
>
> > > > I then set the $("review.body").hide() and refreshed the page, and it
> > > > still took almost 3 minutes to load. The same HTTPS GET requests were
> > > > being displayed, but this time they only took ~90milliseconds and were
> > > > showing "304 Not Modified".
>
> > > > This is my first use of FireBug so please advise if you'd like more or
> > > > different information.
>
> > > > On Mar 6, 4:49 pm, Christian Hammond  wrote:
>
> > > > > 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 review:
> > > > >     If the user has a pending reply to this review, expand it.
> > > > >     Else if the user has replied to the review, and there's no
> > further
> > > > > activity on the review, collapse it.
> > > > >     Else If the review is newer than the latest change description,
> > AND it's
> > > > > the latest review from that user, expand it.
> > > > >     Else if there's activity on the review since the latest change
> > > > > description and since the last time the user viewed the page, expand
> > it.
> > > > >     Else, collapse it.
>
> > > > > Users can of course manually expand a review.
>
> > > > > This should keep the number of visible reviews quite low. Hopefully
> > it'll be
> > > > > the set of reviews that the user actually wants to see. The review
> > contents
> > > > > won't be loaded in unless the user does expand the review, so the
> > page
> > > > > should load a lot faster.
>
> > > > > This doesn't solve the issue of one single review with many hundreds
> > of
> > > > > comments, but I'm hoping that's not a common case, and that would
> > have to be
> > > > > solved differently.
>
> > > > > The the above logic seems broken to someone, ple

Re: Rolling back to Alpha1

[Christian Hammond]

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 committing it, so it
should be in tonight's or tomorrow's nightly. This batches together the
loads, so if you only have a total of, say, 5 files with comments on them,
it'll only do 5 HTTP GETs, instead of the 150+ or whatever it's currently
doing. Should lighten the load considerably on the client side and server
side.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Mon, Mar 9, 2009 at 11:28 AM, mary  wrote:

>
> 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 log limit has been reached. %S entries not shown.
> Preferences
> GET
> https://reviewboard/r/3043/reviews/5911/fragment/diff-comment/9742/?1234569592
>
> 304 Not Modified
>180ms   jquery-11.min.js (line 19)
> GET
> https://reviewboard/r/3043/reviews/5961/fragment/diff-comment/9789/?1234569592
>
> 304 Not Modified
>48msjquery-11.min.js (line 19)
> GET
> https://reviewboard/r/3043/reviews/5964/fragment/diff-comment/9792/?1234569592
>
>
> I think I have probably provided enough information to show the
> problem now.
>
>
> On Mar 9, 11:00 am, mary  wrote:
> > 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 (myself.)
> >
> > I will try some additional tests to provide additional information
> > unless you have enough information, let me know.
> >
> > Thanks!
> >
> > On Mar 9, 10:11 am, mary  wrote:
> >
> >
> >
> > > 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.
> >
> > > I then set the $("review.body").hide() and refreshed the page, and it
> > > still took almost 3 minutes to load. The same HTTPS GET requests were
> > > being displayed, but this time they only took ~90milliseconds and were
> > > showing "304 Not Modified".
> >
> > > This is my first use of FireBug so please advise if you'd like more or
> > > different information.
> >
> > > On Mar 6, 4:49 pm, Christian Hammond  wrote:
> >
> > > > 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 review:
> > > > If the user has a pending reply to this review, expand it.
> > > > Else if the user has replied to the review, and there's no
> further
> > > > activity on the review, collapse it.
> > > > Else If the review is newer than the latest change description,
> AND it's
> > > > the latest review from that user, expand it.
> > > > Else if there's activity on the review since the latest change
> > > > description and since the last time the user viewed the page, expand
> it.
> > > > Else, collapse it.
> >
> > > > Users can of course manually expand a review.
> >
> > > > This should keep the number of visible reviews quite low. Hopefully
> it'll be
> > > > the set of reviews that the user actually wants to see. The review
> contents
> > > > won't be loaded in unless the user does expand the review, so the
> page
> > > > should load a lot faster.
> >
> > > > This doesn't solve the issue of one single review with many hundreds
> of
> > > > comments, but I'm hoping that's not a common case, and that would
> have to be
> > > > solved differently.
> >
> > > > The the above logic seems broken to someone, please let me know!
> >
> > > > Christian
> >
> > > > --
> > > > Christian Hammond - chip...@chipx86.com
> > > > Review Board -http://www.review-board.org
> > > > VMware, Inc. -http://www.vmware.com
> >
> > > > On Fri, Mar 6, 2009 at 4:37 PM, mary  wrote:
> >
> > > > > answers inline below...
> >
> > > > > On Mar 6, 3:52 pm, Christian Hammond  wrote:
> > > > > > A couple more questions. I'm playing around with a couple
> possible fixes,
> > > > > > but need to find out more where the bo

Re: Rolling back to Alpha1

[mary]

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 log limit has been reached. %S entries not shown.
Preferences
GET 
https://reviewboard/r/3043/reviews/5911/fragment/diff-comment/9742/?1234569592

304 Not Modified
180ms   jquery-11.min.js (line 19)
GET 
https://reviewboard/r/3043/reviews/5961/fragment/diff-comment/9789/?1234569592

304 Not Modified
48msjquery-11.min.js (line 19)
GET 
https://reviewboard/r/3043/reviews/5964/fragment/diff-comment/9792/?1234569592


I think I have probably provided enough information to show the
problem now.


On Mar 9, 11:00 am, mary  wrote:
> 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 (myself.)
>
> I will try some additional tests to provide additional information
> unless you have enough information, let me know.
>
> Thanks!
>
> On Mar 9, 10:11 am, mary  wrote:
>
>
>
> > 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.
>
> > I then set the $("review.body").hide() and refreshed the page, and it
> > still took almost 3 minutes to load. The same HTTPS GET requests were
> > being displayed, but this time they only took ~90milliseconds and were
> > showing "304 Not Modified".
>
> > This is my first use of FireBug so please advise if you'd like more or
> > different information.
>
> > On Mar 6, 4:49 pm, Christian Hammond  wrote:
>
> > > 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 review:
> > >     If the user has a pending reply to this review, expand it.
> > >     Else if the user has replied to the review, and there's no further
> > > activity on the review, collapse it.
> > >     Else If the review is newer than the latest change description, AND 
> > > it's
> > > the latest review from that user, expand it.
> > >     Else if there's activity on the review since the latest change
> > > description and since the last time the user viewed the page, expand it.
> > >     Else, collapse it.
>
> > > Users can of course manually expand a review.
>
> > > This should keep the number of visible reviews quite low. Hopefully it'll 
> > > be
> > > the set of reviews that the user actually wants to see. The review 
> > > contents
> > > won't be loaded in unless the user does expand the review, so the page
> > > should load a lot faster.
>
> > > This doesn't solve the issue of one single review with many hundreds of
> > > comments, but I'm hoping that's not a common case, and that would have to 
> > > be
> > > solved differently.
>
> > > The the above logic seems broken to someone, please let me know!
>
> > > Christian
>
> > > --
> > > Christian Hammond - chip...@chipx86.com
> > > Review Board -http://www.review-board.org
> > > VMware, Inc. -http://www.vmware.com
>
> > > On Fri, Mar 6, 2009 at 4:37 PM, mary  wrote:
>
> > > > answers inline below...
>
> > > > On Mar 6, 3:52 pm, Christian Hammond  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 there's a
> > > > lot
> > > > > in the DOM or whether the rendering is the slow part.
>
> > > > > 1) Is the page still slow once it fully loads?
>
> > > > Yes, the comment boxes that are used to write comments are slow even
> > > > after the page is fully loaded. It doesn't make sense to me, but this
> > > > is the behavior being seen by most everyone. (This is only the case
> > > > for reviews with many comments.)
>
> > > > In addition to this, some folks are also complaining that the page
> > > > cannot be used until the page is fully loaded - this has not been my
> > > > experience but I wanted to pass it along too.
>
> > > > Also, we are seeing these issues on reviews that have 10-20 different
> > > > file diffs. Now that I mention this I will try to repro with just one
> > > > file diff to see if that makes a difference or not.
>
> > > > And finally, the CPU gets pe

Re: Rolling back to Alpha1

[mary]

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 (myself.)

I will try some additional tests to provide additional information
unless you have enough information, let me know.

Thanks!

On Mar 9, 10:11 am, mary  wrote:
> 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.
>
> I then set the $("review.body").hide() and refreshed the page, and it
> still took almost 3 minutes to load. The same HTTPS GET requests were
> being displayed, but this time they only took ~90milliseconds and were
> showing "304 Not Modified".
>
> This is my first use of FireBug so please advise if you'd like more or
> different information.
>
> On Mar 6, 4:49 pm, Christian Hammond  wrote:
>
>
>
> > 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 review:
> >     If the user has a pending reply to this review, expand it.
> >     Else if the user has replied to the review, and there's no further
> > activity on the review, collapse it.
> >     Else If the review is newer than the latest change description, AND it's
> > the latest review from that user, expand it.
> >     Else if there's activity on the review since the latest change
> > description and since the last time the user viewed the page, expand it.
> >     Else, collapse it.
>
> > Users can of course manually expand a review.
>
> > This should keep the number of visible reviews quite low. Hopefully it'll be
> > the set of reviews that the user actually wants to see. The review contents
> > won't be loaded in unless the user does expand the review, so the page
> > should load a lot faster.
>
> > This doesn't solve the issue of one single review with many hundreds of
> > comments, but I'm hoping that's not a common case, and that would have to be
> > solved differently.
>
> > The the above logic seems broken to someone, please let me know!
>
> > Christian
>
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board -http://www.review-board.org
> > VMware, Inc. -http://www.vmware.com
>
> > On Fri, Mar 6, 2009 at 4:37 PM, mary  wrote:
>
> > > answers inline below...
>
> > > On Mar 6, 3:52 pm, Christian Hammond  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 there's a
> > > lot
> > > > in the DOM or whether the rendering is the slow part.
>
> > > > 1) Is the page still slow once it fully loads?
>
> > > Yes, the comment boxes that are used to write comments are slow even
> > > after the page is fully loaded. It doesn't make sense to me, but this
> > > is the behavior being seen by most everyone. (This is only the case
> > > for reviews with many comments.)
>
> > > In addition to this, some folks are also complaining that the page
> > > cannot be used until the page is fully loaded - this has not been my
> > > experience but I wanted to pass it along too.
>
> > > Also, we are seeing these issues on reviews that have 10-20 different
> > > file diffs. Now that I mention this I will try to repro with just one
> > > file diff to see if that makes a difference or not.
>
> > > And finally, the CPU gets pegged when these pages are loading.
>
> > > > 2) Can you install the Firebug extension for Firefox and, in the 
> > > > console,
> > > > type the following:
>
> > > >     $(".review .body").hide()
>
> > > I will get back to you on this question.
>
> > > > And see if the page is now faster to interact with? (All the reviews 
> > > > will
> > > be
> > > > hidden until you reload, so this is clearly not a fix by itself, but 
> > > > will
> > > > tell us whether the bottleneck is the DOM or the rendering).
>
> > > > 3) Are these comments spread across many reviews? Or does a single 
> > > > review
> > > > usually have enough comments to cause problems by itself?
>
> > > Yes, the comments are spread across many reviews.
> > > I will try to reproduce using a single review to provide more insight
> > > and get back to you.
>
> > > > Christian
>
> > > > --
> > > > Christian Hammond - chip...@chipx86.com
> > > > Review Board -http://www.review-board.org
> > > > VMware, Inc. -http://www.vmware.com
>
> > > > On Fri, Mar 6, 2009 at 3:10 PM, mary

Re: Rolling back to Alpha1

[mary]

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.

I then set the $("review.body").hide() and refreshed the page, and it
still took almost 3 minutes to load. The same HTTPS GET requests were
being displayed, but this time they only took ~90milliseconds and were
showing "304 Not Modified".

This is my first use of FireBug so please advise if you'd like more or
different information.


On Mar 6, 4:49 pm, Christian Hammond  wrote:
> 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 review:
>     If the user has a pending reply to this review, expand it.
>     Else if the user has replied to the review, and there's no further
> activity on the review, collapse it.
>     Else If the review is newer than the latest change description, AND it's
> the latest review from that user, expand it.
>     Else if there's activity on the review since the latest change
> description and since the last time the user viewed the page, expand it.
>     Else, collapse it.
>
> Users can of course manually expand a review.
>
> This should keep the number of visible reviews quite low. Hopefully it'll be
> the set of reviews that the user actually wants to see. The review contents
> won't be loaded in unless the user does expand the review, so the page
> should load a lot faster.
>
> This doesn't solve the issue of one single review with many hundreds of
> comments, but I'm hoping that's not a common case, and that would have to be
> solved differently.
>
> The the above logic seems broken to someone, please let me know!
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.review-board.org
> VMware, Inc. -http://www.vmware.com
>
>
>
> On Fri, Mar 6, 2009 at 4:37 PM, mary  wrote:
>
> > answers inline below...
>
> > On Mar 6, 3:52 pm, Christian Hammond  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 there's a
> > lot
> > > in the DOM or whether the rendering is the slow part.
>
> > > 1) Is the page still slow once it fully loads?
>
> > Yes, the comment boxes that are used to write comments are slow even
> > after the page is fully loaded. It doesn't make sense to me, but this
> > is the behavior being seen by most everyone. (This is only the case
> > for reviews with many comments.)
>
> > In addition to this, some folks are also complaining that the page
> > cannot be used until the page is fully loaded - this has not been my
> > experience but I wanted to pass it along too.
>
> > Also, we are seeing these issues on reviews that have 10-20 different
> > file diffs. Now that I mention this I will try to repro with just one
> > file diff to see if that makes a difference or not.
>
> > And finally, the CPU gets pegged when these pages are loading.
>
> > > 2) Can you install the Firebug extension for Firefox and, in the console,
> > > type the following:
>
> > >     $(".review .body").hide()
>
> > I will get back to you on this question.
>
> > > And see if the page is now faster to interact with? (All the reviews will
> > be
> > > hidden until you reload, so this is clearly not a fix by itself, but will
> > > tell us whether the bottleneck is the DOM or the rendering).
>
> > > 3) Are these comments spread across many reviews? Or does a single review
> > > usually have enough comments to cause problems by itself?
>
> > Yes, the comments are spread across many reviews.
> > I will try to reproduce using a single review to provide more insight
> > and get back to you.
>
> > > Christian
>
> > > --
> > > Christian Hammond - chip...@chipx86.com
> > > Review Board -http://www.review-board.org
> > > VMware, Inc. -http://www.vmware.com
>
> > > On Fri, Mar 6, 2009 at 3:10 PM, mary  wrote:
>
> > > > 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  wrote:
> > > > > 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 ju

Re: Rolling back to Alpha1

[Christian Hammond]

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 review:
If the user has a pending reply to this review, expand it.
Else if the user has replied to the review, and there's no further
activity on the review, collapse it.
Else If the review is newer than the latest change description, AND it's
the latest review from that user, expand it.
Else if there's activity on the review since the latest change
description and since the last time the user viewed the page, expand it.
Else, collapse it.

Users can of course manually expand a review.

This should keep the number of visible reviews quite low. Hopefully it'll be
the set of reviews that the user actually wants to see. The review contents
won't be loaded in unless the user does expand the review, so the page
should load a lot faster.

This doesn't solve the issue of one single review with many hundreds of
comments, but I'm hoping that's not a common case, and that would have to be
solved differently.

The the above logic seems broken to someone, please let me know!

Christian


-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Fri, Mar 6, 2009 at 4:37 PM, mary  wrote:

>
> answers inline below...
>
> On Mar 6, 3:52 pm, Christian Hammond  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 there's a
> lot
> > in the DOM or whether the rendering is the slow part.
> >
> > 1) Is the page still slow once it fully loads?
> >
> Yes, the comment boxes that are used to write comments are slow even
> after the page is fully loaded. It doesn't make sense to me, but this
> is the behavior being seen by most everyone. (This is only the case
> for reviews with many comments.)
>
> In addition to this, some folks are also complaining that the page
> cannot be used until the page is fully loaded - this has not been my
> experience but I wanted to pass it along too.
>
> Also, we are seeing these issues on reviews that have 10-20 different
> file diffs. Now that I mention this I will try to repro with just one
> file diff to see if that makes a difference or not.
>
> And finally, the CPU gets pegged when these pages are loading.
>
> > 2) Can you install the Firebug extension for Firefox and, in the console,
> > type the following:
> >
> > $(".review .body").hide()
> >
> I will get back to you on this question.
>
> > And see if the page is now faster to interact with? (All the reviews will
> be
> > hidden until you reload, so this is clearly not a fix by itself, but will
> > tell us whether the bottleneck is the DOM or the rendering).
> >
> > 3) Are these comments spread across many reviews? Or does a single review
> > usually have enough comments to cause problems by itself?
>
> Yes, the comments are spread across many reviews.
> I will try to reproduce using a single review to provide more insight
> and get back to you.
>
> >
> > Christian
> >
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board -http://www.review-board.org
> > VMware, Inc. -http://www.vmware.com
> >
> > On Fri, Mar 6, 2009 at 3:10 PM, mary  wrote:
> >
> > > 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  wrote:
> > > > 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 splitting up the changes more, if
> possible.
> > > > Having smaller things to review should mean fewer comments.
> >
> > > > Christian
> >
> > > > --
> > > > Christian Hammond - chip...@chipx86.com
> > > > Review Board -http://www.review-board.org
> > > > VMware, Inc. -http://www.vmware.com
> >
> > > > On Fri, Mar 6, 2009 at 2:51 PM, mary  wrote:
> >
> > > > > 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 page often
> > > > > shows a script error popup box part way through the load.
> >
> > > > > Changing the page 

Re: Rolling back to Alpha1

[mary]

answers inline below...

On Mar 6, 3:52 pm, Christian Hammond  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 there's a lot
> in the DOM or whether the rendering is the slow part.
>
> 1) Is the page still slow once it fully loads?
>
Yes, the comment boxes that are used to write comments are slow even
after the page is fully loaded. It doesn't make sense to me, but this
is the behavior being seen by most everyone. (This is only the case
for reviews with many comments.)

In addition to this, some folks are also complaining that the page
cannot be used until the page is fully loaded - this has not been my
experience but I wanted to pass it along too.

Also, we are seeing these issues on reviews that have 10-20 different
file diffs. Now that I mention this I will try to repro with just one
file diff to see if that makes a difference or not.

And finally, the CPU gets pegged when these pages are loading.

> 2) Can you install the Firebug extension for Firefox and, in the console,
> type the following:
>
>     $(".review .body").hide()
>
I will get back to you on this question.

> And see if the page is now faster to interact with? (All the reviews will be
> hidden until you reload, so this is clearly not a fix by itself, but will
> tell us whether the bottleneck is the DOM or the rendering).
>
> 3) Are these comments spread across many reviews? Or does a single review
> usually have enough comments to cause problems by itself?

Yes, the comments are spread across many reviews.
I will try to reproduce using a single review to provide more insight
and get back to you.

>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.review-board.org
> VMware, Inc. -http://www.vmware.com
>
> On Fri, Mar 6, 2009 at 3:10 PM, mary  wrote:
>
> > 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  wrote:
> > > 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 splitting up the changes more, if possible.
> > > Having smaller things to review should mean fewer comments.
>
> > > Christian
>
> > > --
> > > Christian Hammond - chip...@chipx86.com
> > > Review Board -http://www.review-board.org
> > > VMware, Inc. -http://www.vmware.com
>
> > > On Fri, Mar 6, 2009 at 2:51 PM, mary  wrote:
>
> > > > 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 page often
> > > > shows a script error popup box part way through the load.
>
> > > > Changing the page size would help us so much, can you give any
> > > > indication of a time frame for such a change?
>
> > > > We'd benefit from the other suggestions as well, but jsut getting
> > > > something workable for medium-to-large reviews is our immediate
> > > > concern.
>
> > > > Thanks!
>
> > > > On Mar 6, 2:39 pm, Christian Hammond  wrote:
> > > > > I think we should. The thing is that the newest review request is at
> > the
> > > > > bottom, so it's kinda weird.
>
> > > > > Another thing we should look into is auto-collapsing old reviews
> > (such as
> > > > > reviews made before the last update to the review request), allowing
> > them
> > > > to
> > > > > expand again. This would fetch the collapsed items from the server
> > > > > dynamically.
>
> > > > > Scalability of the review request page is certainly something we
> > should
> > > > > tackle for 1.0.
>
> > > > > As far as using Alpha 2 vs. Alpha 4, if you use Alpha 4 the page
> > should
> > > > load
> > > > > pretty fast, with the diff fragments loading dynamically after. Even
> > with
> > > > > 150+ comments (do you mean actual comments or reviews, btw?) it
> > shouldn't
> > > > > take forever in alpha 4 to display those. Just might take a while for
> > > > those
> > > > > diff fragments ot finish loading across all comments.
>
> > > > > Christian
>
> > > > > --
> > > > > Christian Hammond - chip...@chipx86.com
> > > > > Review Board -http://www.review-board.org
> > > > > VMware, Inc. -http://www.vmware.com
>
> > > > > On Fri, Mar 6, 2009 at 2:06 PM, David Trowbridge 
> > > > wrote:
>
> > > > > > Perhaps we need to paginate the reviews page in addition to the
> > diff?
>
> > > > >

Re: Rolling back to Alpha1

[Christian Hammond]

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 it fully loads?

2) Can you install the Firebug extension for Firefox and, in the console,
type the following:

$(".review .body").hide()

And see if the page is now faster to interact with? (All the reviews will be
hidden until you reload, so this is clearly not a fix by itself, but will
tell us whether the bottleneck is the DOM or the rendering).

3) Are these comments spread across many reviews? Or does a single review
usually have enough comments to cause problems by itself?

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Fri, Mar 6, 2009 at 3:10 PM, mary  wrote:

>
> 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  wrote:
> > 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 splitting up the changes more, if possible.
> > Having smaller things to review should mean fewer comments.
> >
> > Christian
> >
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board -http://www.review-board.org
> > VMware, Inc. -http://www.vmware.com
> >
> > On Fri, Mar 6, 2009 at 2:51 PM, mary  wrote:
> >
> > > 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 page often
> > > shows a script error popup box part way through the load.
> >
> > > Changing the page size would help us so much, can you give any
> > > indication of a time frame for such a change?
> >
> > > We'd benefit from the other suggestions as well, but jsut getting
> > > something workable for medium-to-large reviews is our immediate
> > > concern.
> >
> > > Thanks!
> >
> > > On Mar 6, 2:39 pm, Christian Hammond  wrote:
> > > > I think we should. The thing is that the newest review request is at
> the
> > > > bottom, so it's kinda weird.
> >
> > > > Another thing we should look into is auto-collapsing old reviews
> (such as
> > > > reviews made before the last update to the review request), allowing
> them
> > > to
> > > > expand again. This would fetch the collapsed items from the server
> > > > dynamically.
> >
> > > > Scalability of the review request page is certainly something we
> should
> > > > tackle for 1.0.
> >
> > > > As far as using Alpha 2 vs. Alpha 4, if you use Alpha 4 the page
> should
> > > load
> > > > pretty fast, with the diff fragments loading dynamically after. Even
> with
> > > > 150+ comments (do you mean actual comments or reviews, btw?) it
> shouldn't
> > > > take forever in alpha 4 to display those. Just might take a while for
> > > those
> > > > diff fragments ot finish loading across all comments.
> >
> > > > Christian
> >
> > > > --
> > > > Christian Hammond - chip...@chipx86.com
> > > > Review Board -http://www.review-board.org
> > > > VMware, Inc. -http://www.vmware.com
> >
> > > > On Fri, Mar 6, 2009 at 2:06 PM, David Trowbridge  >
> > > wrote:
> >
> > > > > Perhaps we need to paginate the reviews page in addition to the
> diff?
> >
> > > > > -David
> >
> > > > > On Fri, Mar 6, 2009 at 2:03 PM, mary  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 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 say that
> > > > > > performance benchmarks seem relative to the document size,
> > > complexity,
> > > > > > and browser type (Safari works best, then FireFox, then IE.)
> >
> > > > > > Can we change the paging size the ReviewBoard uses? That would
> help
> > > us
> > > > > > most likely.
> >
> > > > > > Further details:
> > > > > > yes, we're using memcache. 4G ram.
> >
> > > > > > We've been running Alpha2 the past couple weeks. But it seems
> > > Alpha1-4
> > > > > > also have same issues.
> >
> > > > > > On Mar 6, 1:42 pm, Christian Hammond 
> wrote:
> > > > > >> It's important to find out what's causing the slowd

Re: Rolling back to Alpha1

[mary]

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  wrote:
> 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 splitting up the changes more, if possible.
> Having smaller things to review should mean fewer comments.
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.review-board.org
> VMware, Inc. -http://www.vmware.com
>
> On Fri, Mar 6, 2009 at 2:51 PM, mary  wrote:
>
> > 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 page often
> > shows a script error popup box part way through the load.
>
> > Changing the page size would help us so much, can you give any
> > indication of a time frame for such a change?
>
> > We'd benefit from the other suggestions as well, but jsut getting
> > something workable for medium-to-large reviews is our immediate
> > concern.
>
> > Thanks!
>
> > On Mar 6, 2:39 pm, Christian Hammond  wrote:
> > > I think we should. The thing is that the newest review request is at the
> > > bottom, so it's kinda weird.
>
> > > Another thing we should look into is auto-collapsing old reviews (such as
> > > reviews made before the last update to the review request), allowing them
> > to
> > > expand again. This would fetch the collapsed items from the server
> > > dynamically.
>
> > > Scalability of the review request page is certainly something we should
> > > tackle for 1.0.
>
> > > As far as using Alpha 2 vs. Alpha 4, if you use Alpha 4 the page should
> > load
> > > pretty fast, with the diff fragments loading dynamically after. Even with
> > > 150+ comments (do you mean actual comments or reviews, btw?) it shouldn't
> > > take forever in alpha 4 to display those. Just might take a while for
> > those
> > > diff fragments ot finish loading across all comments.
>
> > > Christian
>
> > > --
> > > Christian Hammond - chip...@chipx86.com
> > > Review Board -http://www.review-board.org
> > > VMware, Inc. -http://www.vmware.com
>
> > > On Fri, Mar 6, 2009 at 2:06 PM, David Trowbridge 
> > wrote:
>
> > > > Perhaps we need to paginate the reviews page in addition to the diff?
>
> > > > -David
>
> > > > On Fri, Mar 6, 2009 at 2:03 PM, mary  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 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 say that
> > > > > performance benchmarks seem relative to the document size,
> > complexity,
> > > > > and browser type (Safari works best, then FireFox, then IE.)
>
> > > > > Can we change the paging size the ReviewBoard uses? That would help
> > us
> > > > > most likely.
>
> > > > > Further details:
> > > > > yes, we're using memcache. 4G ram.
>
> > > > > We've been running Alpha2 the past couple weeks. But it seems
> > Alpha1-4
> > > > > also have same issues.
>
> > > > > On Mar 6, 1:42 pm, Christian Hammond  wrote:
> > > > >> It's important to find out what's causing the slowdown. What part is
> > > > being
> > > > >> slow? The page itself, or the progressive diffs inside of it? Alpha
> > 1
> > > > >> doesn't have progressive diffs so it will be slower than alpha 4 in
> > this
> > > > >> regard.
>
> > > > >> We have some large review requests like this at VMware too, and
> > haven't
> > > > seen
> > > > >> this slowdown.
>
> > > > >> Are you using memcached on the server?
>
> > > > >> How much ram do you have on the server?
>
> > > > >> Christian
>
> > > > >> --
> > > > >> Christian Hammond - chip...@chipx86.com
> > > > >> Review Board -http://www.review-board.org
> > > > >> VMware, Inc. -http://www.vmware.com
>
> > > > >> On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:
>
> > > > >> > 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 with ReviewBoard up until now. Is anyone
> > looking
> > > > >> > into this perf issue?
>
> > > > >> > We're g

Re: Rolling back to Alpha1

[Christian Hammond]

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 - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Fri, Mar 6, 2009 at 2:54 PM, Christian Hammond wrote:

> 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 splitting up the changes more, if possible.
> Having smaller things to review should mean fewer comments.
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.review-board.org
> VMware, Inc. - http://www.vmware.com
>
>
> On Fri, Mar 6, 2009 at 2:51 PM, mary  wrote:
>
>>
>> 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 page often
>> shows a script error popup box part way through the load.
>>
>> Changing the page size would help us so much, can you give any
>> indication of a time frame for such a change?
>>
>> We'd benefit from the other suggestions as well, but jsut getting
>> something workable for medium-to-large reviews is our immediate
>> concern.
>>
>> Thanks!
>>
>> On Mar 6, 2:39 pm, Christian Hammond  wrote:
>> > I think we should. The thing is that the newest review request is at the
>> > bottom, so it's kinda weird.
>> >
>> > Another thing we should look into is auto-collapsing old reviews (such
>> as
>> > reviews made before the last update to the review request), allowing
>> them to
>> > expand again. This would fetch the collapsed items from the server
>> > dynamically.
>> >
>> > Scalability of the review request page is certainly something we should
>> > tackle for 1.0.
>> >
>> > As far as using Alpha 2 vs. Alpha 4, if you use Alpha 4 the page should
>> load
>> > pretty fast, with the diff fragments loading dynamically after. Even
>> with
>> > 150+ comments (do you mean actual comments or reviews, btw?) it
>> shouldn't
>> > take forever in alpha 4 to display those. Just might take a while for
>> those
>> > diff fragments ot finish loading across all comments.
>> >
>> > Christian
>> >
>> > --
>> > Christian Hammond - chip...@chipx86.com
>> > Review Board -http://www.review-board.org
>> > VMware, Inc. -http://www.vmware.com
>> >
>> > On Fri, Mar 6, 2009 at 2:06 PM, David Trowbridge 
>> wrote:
>> >
>> > > Perhaps we need to paginate the reviews page in addition to the diff?
>> >
>> > > -David
>> >
>> > > On Fri, Mar 6, 2009 at 2:03 PM, mary  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 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 say that
>> > > > performance benchmarks seem relative to the document size,
>> complexity,
>> > > > and browser type (Safari works best, then FireFox, then IE.)
>> >
>> > > > Can we change the paging size the ReviewBoard uses? That would help
>> us
>> > > > most likely.
>> >
>> > > > Further details:
>> > > > yes, we're using memcache. 4G ram.
>> >
>> > > > We've been running Alpha2 the past couple weeks. But it seems
>> Alpha1-4
>> > > > also have same issues.
>> >
>> > > > On Mar 6, 1:42 pm, Christian Hammond  wrote:
>> > > >> It's important to find out what's causing the slowdown. What part
>> is
>> > > being
>> > > >> slow? The page itself, or the progressive diffs inside of it? Alpha
>> 1
>> > > >> doesn't have progressive diffs so it will be slower than alpha 4 in
>> this
>> > > >> regard.
>> >
>> > > >> We have some large review requests like this at VMware too, and
>> haven't
>> > > seen
>> > > >> this slowdown.
>> >
>> > > >> Are you using memcached on the server?
>> >
>> > > >> How much ram do you have on the server?
>> >
>> > > >> Christian
>> >
>> > > >> --
>> > > >> Christian Hammond - chip...@chipx86.com
>> > > >> Review Board -http://www.review-board.org
>> > > >> VMware, Inc. -http://www.vmware.com
>> >
>> > > >> On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:
>> >
>> > > >> > 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 seriou

Re: Rolling back to Alpha1

[Christian Hammond]

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 splitting up the changes more, if possible.
Having smaller things to review should mean fewer comments.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Fri, Mar 6, 2009 at 2:51 PM, mary  wrote:

>
> 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 page often
> shows a script error popup box part way through the load.
>
> Changing the page size would help us so much, can you give any
> indication of a time frame for such a change?
>
> We'd benefit from the other suggestions as well, but jsut getting
> something workable for medium-to-large reviews is our immediate
> concern.
>
> Thanks!
>
> On Mar 6, 2:39 pm, Christian Hammond  wrote:
> > I think we should. The thing is that the newest review request is at the
> > bottom, so it's kinda weird.
> >
> > Another thing we should look into is auto-collapsing old reviews (such as
> > reviews made before the last update to the review request), allowing them
> to
> > expand again. This would fetch the collapsed items from the server
> > dynamically.
> >
> > Scalability of the review request page is certainly something we should
> > tackle for 1.0.
> >
> > As far as using Alpha 2 vs. Alpha 4, if you use Alpha 4 the page should
> load
> > pretty fast, with the diff fragments loading dynamically after. Even with
> > 150+ comments (do you mean actual comments or reviews, btw?) it shouldn't
> > take forever in alpha 4 to display those. Just might take a while for
> those
> > diff fragments ot finish loading across all comments.
> >
> > Christian
> >
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board -http://www.review-board.org
> > VMware, Inc. -http://www.vmware.com
> >
> > On Fri, Mar 6, 2009 at 2:06 PM, David Trowbridge 
> wrote:
> >
> > > Perhaps we need to paginate the reviews page in addition to the diff?
> >
> > > -David
> >
> > > On Fri, Mar 6, 2009 at 2:03 PM, mary  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 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 say that
> > > > performance benchmarks seem relative to the document size,
> complexity,
> > > > and browser type (Safari works best, then FireFox, then IE.)
> >
> > > > Can we change the paging size the ReviewBoard uses? That would help
> us
> > > > most likely.
> >
> > > > Further details:
> > > > yes, we're using memcache. 4G ram.
> >
> > > > We've been running Alpha2 the past couple weeks. But it seems
> Alpha1-4
> > > > also have same issues.
> >
> > > > On Mar 6, 1:42 pm, Christian Hammond  wrote:
> > > >> It's important to find out what's causing the slowdown. What part is
> > > being
> > > >> slow? The page itself, or the progressive diffs inside of it? Alpha
> 1
> > > >> doesn't have progressive diffs so it will be slower than alpha 4 in
> this
> > > >> regard.
> >
> > > >> We have some large review requests like this at VMware too, and
> haven't
> > > seen
> > > >> this slowdown.
> >
> > > >> Are you using memcached on the server?
> >
> > > >> How much ram do you have on the server?
> >
> > > >> Christian
> >
> > > >> --
> > > >> Christian Hammond - chip...@chipx86.com
> > > >> Review Board -http://www.review-board.org
> > > >> VMware, Inc. -http://www.vmware.com
> >
> > > >> On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:
> >
> > > >> > 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 with ReviewBoard up until now. Is anyone
> looking
> > > >> > into this perf issue?
> >
> > > >> > We're going to have to move back to using  CodeStriker
> soon if
> > > >> > this isn't addressed.
> >
> > > >> > On Feb 24, 1:54 pm, mary  wrote:
> > > >> > > 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 wil

Re: Rolling back to Alpha1

[mary]

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 page often
shows a script error popup box part way through the load.

Changing the page size would help us so much, can you give any
indication of a time frame for such a change?

We'd benefit from the other suggestions as well, but jsut getting
something workable for medium-to-large reviews is our immediate
concern.

Thanks!

On Mar 6, 2:39 pm, Christian Hammond  wrote:
> I think we should. The thing is that the newest review request is at the
> bottom, so it's kinda weird.
>
> Another thing we should look into is auto-collapsing old reviews (such as
> reviews made before the last update to the review request), allowing them to
> expand again. This would fetch the collapsed items from the server
> dynamically.
>
> Scalability of the review request page is certainly something we should
> tackle for 1.0.
>
> As far as using Alpha 2 vs. Alpha 4, if you use Alpha 4 the page should load
> pretty fast, with the diff fragments loading dynamically after. Even with
> 150+ comments (do you mean actual comments or reviews, btw?) it shouldn't
> take forever in alpha 4 to display those. Just might take a while for those
> diff fragments ot finish loading across all comments.
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.review-board.org
> VMware, Inc. -http://www.vmware.com
>
> On Fri, Mar 6, 2009 at 2:06 PM, David Trowbridge  wrote:
>
> > Perhaps we need to paginate the reviews page in addition to the diff?
>
> > -David
>
> > On Fri, Mar 6, 2009 at 2:03 PM, mary  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 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 say that
> > > performance benchmarks seem relative to the document size, complexity,
> > > and browser type (Safari works best, then FireFox, then IE.)
>
> > > Can we change the paging size the ReviewBoard uses? That would help us
> > > most likely.
>
> > > Further details:
> > > yes, we're using memcache. 4G ram.
>
> > > We've been running Alpha2 the past couple weeks. But it seems Alpha1-4
> > > also have same issues.
>
> > > On Mar 6, 1:42 pm, Christian Hammond  wrote:
> > >> It's important to find out what's causing the slowdown. What part is
> > being
> > >> slow? The page itself, or the progressive diffs inside of it? Alpha 1
> > >> doesn't have progressive diffs so it will be slower than alpha 4 in this
> > >> regard.
>
> > >> We have some large review requests like this at VMware too, and haven't
> > seen
> > >> this slowdown.
>
> > >> Are you using memcached on the server?
>
> > >> How much ram do you have on the server?
>
> > >> Christian
>
> > >> --
> > >> Christian Hammond - chip...@chipx86.com
> > >> Review Board -http://www.review-board.org
> > >> VMware, Inc. -http://www.vmware.com
>
> > >> On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:
>
> > >> > 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 with ReviewBoard up until now. Is anyone looking
> > >> > into this perf issue?
>
> > >> > We're going to have to move back to using  CodeStriker soon if
> > >> > this isn't addressed.
>
> > >> > On Feb 24, 1:54 pm, mary  wrote:
> > >> > > 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 Firefox 3 (both from
> > >> > > Windows and Linux). Everyone is reporting that using Firefox is
> > >> > > definitely better than IE7 though, but still very slow. I have
> > >> > > reported one bug #906 which I thought was the full issue, but others
> > >> > > are reporting the slowness even on reviews with a small diff and
> > very
> > >> > > few total reviews.
> > >> >http://code.google.com/p/reviewboard/issues/detail?id=906
>
> > >> > > It's been reported numerous times that when users open up the review
> > >> > > comment pop up box and start to type their comments, the characters
> > >> > > typed take forever to show up in the comment field GUI. This is new
> > >> > > for us, no one reported this prior to recent

Re: Rolling back to Alpha1

[Christian Hammond]

I think we should. The thing is that the newest review request is at the
bottom, so it's kinda weird.

Another thing we should look into is auto-collapsing old reviews (such as
reviews made before the last update to the review request), allowing them to
expand again. This would fetch the collapsed items from the server
dynamically.

Scalability of the review request page is certainly something we should
tackle for 1.0.

As far as using Alpha 2 vs. Alpha 4, if you use Alpha 4 the page should load
pretty fast, with the diff fragments loading dynamically after. Even with
150+ comments (do you mean actual comments or reviews, btw?) it shouldn't
take forever in alpha 4 to display those. Just might take a while for those
diff fragments ot finish loading across all comments.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Fri, Mar 6, 2009 at 2:06 PM, David Trowbridge  wrote:

>
> Perhaps we need to paginate the reviews page in addition to the diff?
>
> -David
>
> On Fri, Mar 6, 2009 at 2:03 PM, mary  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 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 say that
> > performance benchmarks seem relative to the document size, complexity,
> > and browser type (Safari works best, then FireFox, then IE.)
> >
> > Can we change the paging size the ReviewBoard uses? That would help us
> > most likely.
> >
> > Further details:
> > yes, we're using memcache. 4G ram.
> >
> > We've been running Alpha2 the past couple weeks. But it seems Alpha1-4
> > also have same issues.
> >
> >
> > On Mar 6, 1:42 pm, Christian Hammond  wrote:
> >> It's important to find out what's causing the slowdown. What part is
> being
> >> slow? The page itself, or the progressive diffs inside of it? Alpha 1
> >> doesn't have progressive diffs so it will be slower than alpha 4 in this
> >> regard.
> >>
> >> We have some large review requests like this at VMware too, and haven't
> seen
> >> this slowdown.
> >>
> >> Are you using memcached on the server?
> >>
> >> How much ram do you have on the server?
> >>
> >> Christian
> >>
> >> --
> >> Christian Hammond - chip...@chipx86.com
> >> Review Board -http://www.review-board.org
> >> VMware, Inc. -http://www.vmware.com
> >>
> >>
> >>
> >> On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:
> >>
> >> > 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 with ReviewBoard up until now. Is anyone looking
> >> > into this perf issue?
> >>
> >> > We're going to have to move back to using  CodeStriker soon if
> >> > this isn't addressed.
> >>
> >> > On Feb 24, 1:54 pm, mary  wrote:
> >> > > 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 Firefox 3 (both from
> >> > > Windows and Linux). Everyone is reporting that using Firefox is
> >> > > definitely better than IE7 though, but still very slow. I have
> >> > > reported one bug #906 which I thought was the full issue, but others
> >> > > are reporting the slowness even on reviews with a small diff and
> very
> >> > > few total reviews.
> >> >http://code.google.com/p/reviewboard/issues/detail?id=906
> >>
> >> > > It's been reported numerous times that when users open up the review
> >> > > comment pop up box and start to type their comments, the characters
> >> > > typed take forever to show up in the comment field GUI. This is new
> >> > > for us, no one reported this prior to recent alpha upgrades (I think
> >> > > limited to alpha2, although i'm not certain of this.)
> >>
> >> > > On Feb 24, 1:39 pm, Christian Hammond  wrote:
> >>
> >> > > > In theory, you should be able to just install the  1.0alpha1 eggs
> of
> >> > both
> >> > > > Review Board and Djblets. This is completely untested and
> unsupported,
> >> > > > though. Note that in the future, you'll have a harder time with
> this.
> >> > There
> >> > > > were no database schema changes between alpha 1 and 4 (to my
> >> > knowledge), but
> >> > > > there may be between 4 and some other version.
> >>
> >> > > > I'm going to be committing a fix for interdiffs within a day or
> two.
> >> > You
> >> > > > could wait until then and upgrade to the nightly (which will be
> safe
> >> > enou

Re: Rolling back to Alpha1

[David Trowbridge]

Perhaps we need to paginate the reviews page in addition to the diff?

-David

On Fri, Mar 6, 2009 at 2:03 PM, mary  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 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 say that
> performance benchmarks seem relative to the document size, complexity,
> and browser type (Safari works best, then FireFox, then IE.)
>
> Can we change the paging size the ReviewBoard uses? That would help us
> most likely.
>
> Further details:
> yes, we're using memcache. 4G ram.
>
> We've been running Alpha2 the past couple weeks. But it seems Alpha1-4
> also have same issues.
>
>
> On Mar 6, 1:42 pm, Christian Hammond  wrote:
>> It's important to find out what's causing the slowdown. What part is being
>> slow? The page itself, or the progressive diffs inside of it? Alpha 1
>> doesn't have progressive diffs so it will be slower than alpha 4 in this
>> regard.
>>
>> We have some large review requests like this at VMware too, and haven't seen
>> this slowdown.
>>
>> Are you using memcached on the server?
>>
>> How much ram do you have on the server?
>>
>> Christian
>>
>> --
>> Christian Hammond - chip...@chipx86.com
>> Review Board -http://www.review-board.org
>> VMware, Inc. -http://www.vmware.com
>>
>>
>>
>> On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:
>>
>> > 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 with ReviewBoard up until now. Is anyone looking
>> > into this perf issue?
>>
>> > We're going to have to move back to using  CodeStriker soon if
>> > this isn't addressed.
>>
>> > On Feb 24, 1:54 pm, mary  wrote:
>> > > 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 Firefox 3 (both from
>> > > Windows and Linux). Everyone is reporting that using Firefox is
>> > > definitely better than IE7 though, but still very slow. I have
>> > > reported one bug #906 which I thought was the full issue, but others
>> > > are reporting the slowness even on reviews with a small diff and very
>> > > few total reviews.
>> >http://code.google.com/p/reviewboard/issues/detail?id=906
>>
>> > > It's been reported numerous times that when users open up the review
>> > > comment pop up box and start to type their comments, the characters
>> > > typed take forever to show up in the comment field GUI. This is new
>> > > for us, no one reported this prior to recent alpha upgrades (I think
>> > > limited to alpha2, although i'm not certain of this.)
>>
>> > > On Feb 24, 1:39 pm, Christian Hammond  wrote:
>>
>> > > > In theory, you should be able to just install the  1.0alpha1 eggs of
>> > both
>> > > > Review Board and Djblets. This is completely untested and unsupported,
>> > > > though. Note that in the future, you'll have a harder time with this.
>> > There
>> > > > were no database schema changes between alpha 1 and 4 (to my
>> > knowledge), but
>> > > > there may be between 4 and some other version.
>>
>> > > > I'm going to be committing a fix for interdiffs within a day or two.
>> > You
>> > > > could wait until then and upgrade to the nightly (which will be safe
>> > enough
>> > > > for use, as not much has changed since alpha 4).
>>
>> > > > I don't know what this slow popup dialog issue is. I've heard one other
>> > > > person mention this but I can't reproduce it. The only way it'll get
>> > fixed,
>> > > > though, is if we can gather some debug info and figure out what's
>> > causing
>> > > > it. Can you tell me what versions of what browsers on what platforms
>> > they're
>> > > > using?
>>
>> > > > Christian
>>
>> > > > --
>> > > > Christian Hammond - chip...@chipx86.com
>> > > > Review Board -http://www.review-board.org
>> > > > VMware, Inc. -http://www.vmware.com
>>
>> > > > On Tue, Feb 24, 2009 at 1:31 PM, mary  wrote:
>>
>> > > > > 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 would like to roll back to Alpha 1 to see
>> > > > > if that fixes the issue.
>>
>> > > > > How do I roll back to a previous Alpha release? Can I specif

Re: Rolling back to Alpha1

[mary]

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 say that
performance benchmarks seem relative to the document size, complexity,
and browser type (Safari works best, then FireFox, then IE.)

Can we change the paging size the ReviewBoard uses? That would help us
most likely.

Further details:
yes, we're using memcache. 4G ram.

We've been running Alpha2 the past couple weeks. But it seems Alpha1-4
also have same issues.


On Mar 6, 1:42 pm, Christian Hammond  wrote:
> It's important to find out what's causing the slowdown. What part is being
> slow? The page itself, or the progressive diffs inside of it? Alpha 1
> doesn't have progressive diffs so it will be slower than alpha 4 in this
> regard.
>
> We have some large review requests like this at VMware too, and haven't seen
> this slowdown.
>
> Are you using memcached on the server?
>
> How much ram do you have on the server?
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.review-board.org
> VMware, Inc. -http://www.vmware.com
>
>
>
> On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:
>
> > 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 with ReviewBoard up until now. Is anyone looking
> > into this perf issue?
>
> > We're going to have to move back to using  CodeStriker soon if
> > this isn't addressed.
>
> > On Feb 24, 1:54 pm, mary  wrote:
> > > 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 Firefox 3 (both from
> > > Windows and Linux). Everyone is reporting that using Firefox is
> > > definitely better than IE7 though, but still very slow. I have
> > > reported one bug #906 which I thought was the full issue, but others
> > > are reporting the slowness even on reviews with a small diff and very
> > > few total reviews.
> >http://code.google.com/p/reviewboard/issues/detail?id=906
>
> > > It's been reported numerous times that when users open up the review
> > > comment pop up box and start to type their comments, the characters
> > > typed take forever to show up in the comment field GUI. This is new
> > > for us, no one reported this prior to recent alpha upgrades (I think
> > > limited to alpha2, although i'm not certain of this.)
>
> > > On Feb 24, 1:39 pm, Christian Hammond  wrote:
>
> > > > In theory, you should be able to just install the  1.0alpha1 eggs of
> > both
> > > > Review Board and Djblets. This is completely untested and unsupported,
> > > > though. Note that in the future, you'll have a harder time with this.
> > There
> > > > were no database schema changes between alpha 1 and 4 (to my
> > knowledge), but
> > > > there may be between 4 and some other version.
>
> > > > I'm going to be committing a fix for interdiffs within a day or two.
> > You
> > > > could wait until then and upgrade to the nightly (which will be safe
> > enough
> > > > for use, as not much has changed since alpha 4).
>
> > > > I don't know what this slow popup dialog issue is. I've heard one other
> > > > person mention this but I can't reproduce it. The only way it'll get
> > fixed,
> > > > though, is if we can gather some debug info and figure out what's
> > causing
> > > > it. Can you tell me what versions of what browsers on what platforms
> > they're
> > > > using?
>
> > > > Christian
>
> > > > --
> > > > Christian Hammond - chip...@chipx86.com
> > > > Review Board -http://www.review-board.org
> > > > VMware, Inc. -http://www.vmware.com
>
> > > > On Tue, Feb 24, 2009 at 1:31 PM, mary  wrote:
>
> > > > > 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 would like to roll back to Alpha 1 to see
> > > > > if that fixes the issue.
>
> > > > > How do I roll back to a previous Alpha release? Can I specify an
> > alpha
> > > > > version on install and just reinstall? It's not clear how to do this
> > > > > from the docs.
>
> > > > > Also, any estimate on when Alpha 5 will be ready? (We don't want to
> > > > > upgrade to Alpha4 because of bug reported w/ viewing 

Re: Rolling back to Alpha1

[Christian Hammond]

It's important to find out what's causing the slowdown. What part is being
slow? The page itself, or the progressive diffs inside of it? Alpha 1
doesn't have progressive diffs so it will be slower than alpha 4 in this
regard.

We have some large review requests like this at VMware too, and haven't seen
this slowdown.

Are you using memcached on the server?

How much ram do you have on the server?

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Fri, Mar 6, 2009 at 10:53 AM, mary  wrote:

>
> 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 with ReviewBoard up until now. Is anyone looking
> into this perf issue?
>
> We're going to have to move back to using  CodeStriker soon if
> this isn't addressed.
>
> On Feb 24, 1:54 pm, mary  wrote:
> > 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 Firefox 3 (both from
> > Windows and Linux). Everyone is reporting that using Firefox is
> > definitely better than IE7 though, but still very slow. I have
> > reported one bug #906 which I thought was the full issue, but others
> > are reporting the slowness even on reviews with a small diff and very
> > few total reviews.
> http://code.google.com/p/reviewboard/issues/detail?id=906
> >
> > It's been reported numerous times that when users open up the review
> > comment pop up box and start to type their comments, the characters
> > typed take forever to show up in the comment field GUI. This is new
> > for us, no one reported this prior to recent alpha upgrades (I think
> > limited to alpha2, although i'm not certain of this.)
> >
> > On Feb 24, 1:39 pm, Christian Hammond  wrote:
> >
> >
> >
> > > In theory, you should be able to just install the  1.0alpha1 eggs of
> both
> > > Review Board and Djblets. This is completely untested and unsupported,
> > > though. Note that in the future, you'll have a harder time with this.
> There
> > > were no database schema changes between alpha 1 and 4 (to my
> knowledge), but
> > > there may be between 4 and some other version.
> >
> > > I'm going to be committing a fix for interdiffs within a day or two.
> You
> > > could wait until then and upgrade to the nightly (which will be safe
> enough
> > > for use, as not much has changed since alpha 4).
> >
> > > I don't know what this slow popup dialog issue is. I've heard one other
> > > person mention this but I can't reproduce it. The only way it'll get
> fixed,
> > > though, is if we can gather some debug info and figure out what's
> causing
> > > it. Can you tell me what versions of what browsers on what platforms
> they're
> > > using?
> >
> > > Christian
> >
> > > --
> > > Christian Hammond - chip...@chipx86.com
> > > Review Board -http://www.review-board.org
> > > VMware, Inc. -http://www.vmware.com
> >
> > > On Tue, Feb 24, 2009 at 1:31 PM, mary  wrote:
> >
> > > > 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 would like to roll back to Alpha 1 to see
> > > > if that fixes the issue.
> >
> > > > How do I roll back to a previous Alpha release? Can I specify an
> alpha
> > > > version on install and just reinstall? It's not clear how to do this
> > > > from the docs.
> >
> > > > Also, any estimate on when Alpha 5 will be ready? (We don't want to
> > > > upgrade to Alpha4 because of bug reported w/ viewing diffs of
> > > > revisions, which we already have problems with.)
> >
> > > > Thanks!
> > > > Mary- Hide quoted text -
> >
> > - Show quoted text -
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: Rolling back to Alpha1

[mary]

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 with ReviewBoard up until now. Is anyone looking
into this perf issue?

We're going to have to move back to using  CodeStriker soon if
this isn't addressed.

On Feb 24, 1:54 pm, mary  wrote:
> 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 Firefox 3 (both from
> Windows and Linux). Everyone is reporting that using Firefox is
> definitely better than IE7 though, but still very slow. I have
> reported one bug #906 which I thought was the full issue, but others
> are reporting the slowness even on reviews with a small diff and very
> few total reviews.http://code.google.com/p/reviewboard/issues/detail?id=906
>
> It's been reported numerous times that when users open up the review
> comment pop up box and start to type their comments, the characters
> typed take forever to show up in the comment field GUI. This is new
> for us, no one reported this prior to recent alpha upgrades (I think
> limited to alpha2, although i'm not certain of this.)
>
> On Feb 24, 1:39 pm, Christian Hammond  wrote:
>
>
>
> > In theory, you should be able to just install the  1.0alpha1 eggs of both
> > Review Board and Djblets. This is completely untested and unsupported,
> > though. Note that in the future, you'll have a harder time with this. There
> > were no database schema changes between alpha 1 and 4 (to my knowledge), but
> > there may be between 4 and some other version.
>
> > I'm going to be committing a fix for interdiffs within a day or two. You
> > could wait until then and upgrade to the nightly (which will be safe enough
> > for use, as not much has changed since alpha 4).
>
> > I don't know what this slow popup dialog issue is. I've heard one other
> > person mention this but I can't reproduce it. The only way it'll get fixed,
> > though, is if we can gather some debug info and figure out what's causing
> > it. Can you tell me what versions of what browsers on what platforms they're
> > using?
>
> > Christian
>
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board -http://www.review-board.org
> > VMware, Inc. -http://www.vmware.com
>
> > On Tue, Feb 24, 2009 at 1:31 PM, mary  wrote:
>
> > > 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 would like to roll back to Alpha 1 to see
> > > if that fixes the issue.
>
> > > How do I roll back to a previous Alpha release? Can I specify an alpha
> > > version on install and just reinstall? It's not clear how to do this
> > > from the docs.
>
> > > Also, any estimate on when Alpha 5 will be ready? (We don't want to
> > > upgrade to Alpha4 because of bug reported w/ viewing diffs of
> > > revisions, which we already have problems with.)
>
> > > Thanks!
> > > Mary- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: Rolling back to Alpha1

[mary]

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 Firefox 3 (both from
Windows and Linux). Everyone is reporting that using Firefox is
definitely better than IE7 though, but still very slow. I have
reported one bug #906 which I thought was the full issue, but others
are reporting the slowness even on reviews with a small diff and very
few total reviews.
http://code.google.com/p/reviewboard/issues/detail?id=906

It's been reported numerous times that when users open up the review
comment pop up box and start to type their comments, the characters
typed take forever to show up in the comment field GUI. This is new
for us, no one reported this prior to recent alpha upgrades (I think
limited to alpha2, although i'm not certain of this.)



On Feb 24, 1:39 pm, Christian Hammond  wrote:
> In theory, you should be able to just install the  1.0alpha1 eggs of both
> Review Board and Djblets. This is completely untested and unsupported,
> though. Note that in the future, you'll have a harder time with this. There
> were no database schema changes between alpha 1 and 4 (to my knowledge), but
> there may be between 4 and some other version.
>
> I'm going to be committing a fix for interdiffs within a day or two. You
> could wait until then and upgrade to the nightly (which will be safe enough
> for use, as not much has changed since alpha 4).
>
> I don't know what this slow popup dialog issue is. I've heard one other
> person mention this but I can't reproduce it. The only way it'll get fixed,
> though, is if we can gather some debug info and figure out what's causing
> it. Can you tell me what versions of what browsers on what platforms they're
> using?
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.review-board.org
> VMware, Inc. -http://www.vmware.com
>
> On Tue, Feb 24, 2009 at 1:31 PM, mary  wrote:
>
> > 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 would like to roll back to Alpha 1 to see
> > if that fixes the issue.
>
> > How do I roll back to a previous Alpha release? Can I specify an alpha
> > version on install and just reinstall? It's not clear how to do this
> > from the docs.
>
> > Also, any estimate on when Alpha 5 will be ready? (We don't want to
> > upgrade to Alpha4 because of bug reported w/ viewing diffs of
> > revisions, which we already have problems with.)
>
> > Thanks!
> > Mary
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: Rolling back to Alpha1

[Christian Hammond]

In theory, you should be able to just install the  1.0alpha1 eggs of both
Review Board and Djblets. This is completely untested and unsupported,
though. Note that in the future, you'll have a harder time with this. There
were no database schema changes between alpha 1 and 4 (to my knowledge), but
there may be between 4 and some other version.

I'm going to be committing a fix for interdiffs within a day or two. You
could wait until then and upgrade to the nightly (which will be safe enough
for use, as not much has changed since alpha 4).

I don't know what this slow popup dialog issue is. I've heard one other
person mention this but I can't reproduce it. The only way it'll get fixed,
though, is if we can gather some debug info and figure out what's causing
it. Can you tell me what versions of what browsers on what platforms they're
using?

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Tue, Feb 24, 2009 at 1:31 PM, mary  wrote:

>
> 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 would like to roll back to Alpha 1 to see
> if that fixes the issue.
>
> How do I roll back to a previous Alpha release? Can I specify an alpha
> version on install and just reinstall? It's not clear how to do this
> from the docs.
>
> Also, any estimate on when Alpha 5 will be ready? (We don't want to
> upgrade to Alpha4 because of bug reported w/ viewing diffs of
> revisions, which we already have problems with.)
>
> Thanks!
> Mary
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
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
-~--~~~~--~~--~--~---

Rolling back to Alpha1

[mary]

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 would like to roll back to Alpha 1 to see
if that fixes the issue.

How do I roll back to a previous Alpha release? Can I specify an alpha
version on install and just reinstall? It's not clear how to do this
from the docs.

Also, any estimate on when Alpha 5 will be ready? (We don't want to
upgrade to Alpha4 because of bug reported w/ viewing diffs of
revisions, which we already have problems with.)

Thanks!
Mary
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
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
-~--~~~~--~~--~--~---