New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: Submitted
Owner:
Closed: Feb 8
Cc:
Components:



Sign in to add a comment
link

Issue 10380: Utilize project index to render change list on GWT UI

Reported by david.os...@gmail.com, Jan 24 Project Member

Issue description

Affected Version: 2.16

Secondary index is much faster and consume much less resources
and thus should be used to render change list screen, like it is
currently the case on PG UI (on both 2.16 and master).

PG UI:
<host>/projects/?n=26&S=0&query=state%3Aactive%20OR%20state%3Aread-only

GWT UI:
<host>/projects/?m=&n=26&type=ALL&d
 

Comment 1 by luca.mil...@gmail.com, Jan 24

Project Member
Cc: luca.mil...@gmail.com
Just tested on GerritHub.io right now:

(Projects with Lucene index) => 0.502 seconds
time curl 'https://review.gerrithub.io/projects/?n=26&S=0&query=state%3Aactive%20OR%20state%3Aread-only'

(Projects with stream-based listing) => 0.416 seconds
time curl 'https://review.gerrithub.io/projects/?m=&n=26&type=ALL&d'

Actually, it seems that the list with the fixed stream-based navigation of the projects is slightly faster than the Lucene-based implementation.

I do not believe this is an issue anymore in v2.16

Comment 2 by david.os...@gmail.com, Jan 25

Project Member
Status: WontFix (was: New)
Setting to WontFix as for Luca's comment.

Comment 3 by luca.mil...@gmail.com, Jan 27

Project Member
I checked also the memory allocation and it is not an issue when limits are specified.
When listing without limits, both query (Lucene-based) and list (Stream-based) are causing again JVM heap explosion.

That is a different issue though because query results are limited (by default to 500 entries) while listing are unlimited (by default returns *all entries*).

Raising a follow-up issue to introduce a limit on the listing.

Comment 4 by david.os...@gmail.com, Jan 27

Project Member
Yes, enforcing limit on listing make sense.

Comment 5 by luca.mil...@gmail.com, Jan 27

Project Member
Created a followup  Issue 10390  on the introduction of a listLimit range global capability

Comment 6 by luca.mil...@gmail.com, Jan 31

Project Member
Status: Accepted (was: WontFix)
I have been talking face-to-face with Patrick and, actually, there is a different use-case where the Lucene implementation is superior: "give me the 100th page"

With the current list implementation, it will blow your JVM heap, with Lucene, it won't.

Comment 7 by luca.mil...@gmail.com, Jan 31

Project Member
Owner: luca.mil...@gmail.com

Comment 8 by luca.mil...@gmail.com, Jan 31

Project Member
While the GWT UI is going away, there is the same problem in other places, like the GerritApi and the SSH commands.

Rather than chaning the GWT UI, we can use the Lucene index inside the ListProjects and get the benefits on GWT, GerritApi and SSH commands in one go.

The fix on GWT UI would benefit only 2.16, the fix on the ListProjects would benefit 2.16 and master also.

Comment 9 Deleted

Comment 10 by luca.mil...@gmail.com, Feb 1

Project Member
Status: Started (was: Accepted)
Started working on the reimplementation of the Project list based on Lucene.
See the WIP change:
https://gerrit-review.googlesource.com/c/gerrit/+/212559

Comment 11 by luca.mil...@gmail.com, Feb 1

Project Member
Components: -GWT Backend

Comment 12 by david.pu...@gmail.com, Feb 8

Labels: FixedIn-2.16.5
Status: Submitted (was: Started)

Sign in to add a comment