[JENKINS-16342] asynchPeople very slow when using Gravatar & Subversion plugins

https://gist.github.com/4534378 shows https://jenkins.ci.cloudbees.com/job/libraries/asynchPeople/ taking an inordinate amount of time in the callback. Clearly AsynchPeople.data() cannot assume that UserAvatarResolver.resolve is quick. UserGravatarResolver sometimes blocks on an HTTP connection to a web service, though this is cached. However every time it checks Mailer.UserProperty.getAddress, which in the presence of SubversionMailAddressResolverImpl examines every build of every project in every folder in all of Jenkins. This is so inefficient we probably never want to do it, much less synchronously in an HTTP request.

Besides People, the avatar is used in a couple of per-User pages, which is perhaps OK; but shown for every User in the HudsonPrivateSecurityRealm overview, which is definitely not OK.

Originally reported by jglick, imported from: asynchPeople very slow when using Gravatar & Subversion plugins

assignee: jglick
status: Resolved
priority: Critical
component(s): core, gravatar-plugin, subversion-plugin
label(s): 1.480.3-fixed, performance
resolution: Fixed
resolved: 2013-02-03T13:42:58+00:00
votes: 0
watchers: 6
imported: 2025-11-24

Raw content of original issue

https://gist.github.com/4534378 shows https://jenkins.ci.cloudbees.com/job/libraries/asynchPeople/ taking an inordinate amount of time in the callback. Clearly AsynchPeople.data() cannot assume that UserAvatarResolver.resolve is quick. UserGravatarResolver sometimes blocks on an HTTP connection to a web service, though this is cached. However every time it checks Mailer.UserProperty.getAddress, which in the presence of SubversionMailAddressResolverImpl examines every build of every project in every folder in all of Jenkins. This is so inefficient we probably never want to do it, much less synchronously in an HTTP request.

Besides People, the avatar is used in a couple of per-User pages, which is perhaps OK; but shown for every User in the HudsonPrivateSecurityRealm overview, which is definitely not OK.

jglick:

Original comment link

Raw content of original comment:

Unreleased fixes of ~~JENKINS-15440~~ at least avoid the problem when you have no configured rules. But if you have even one, the problem will suddenly pop up again.

scm_issue_link:

Original comment link

Raw content of original comment:

Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/View.java http://jenkins-ci.org/commit/jenkins/c757e65431ad1aec9a3bebe81ac919577e51ac58 Log: ~~JENKINS-16342~~ Improving responsiveness of asynchPeople when Gravatar plugin is in use. This change does not necessarily improve total performance, since the avatar is still computed. But (1) the computation is correctly done in the work thread, not in the HTTP response thread; (2) the computation is done just once for a given User, which could reduce load when many AJAX checks are done.

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/model/View.java
http://jenkins-ci.org/commit/jenkins/c757e65431ad1aec9a3bebe81ac919577e51ac58
Log:
~~JENKINS-16342~~ Improving responsiveness of asynchPeople when Gravatar plugin is in use.
This change does not necessarily improve total performance, since the avatar is still computed.
But (1) the computation is correctly done in the work thread, not in the HTTP response thread;
(2) the computation is done just once for a given User, which could reduce load when many AJAX checks are done.

jglick:

Original comment link

Raw content of original comment:

Some things remain to be done to make UserAvatarResolver consistently quick:

SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way.
UserGravatarResolver should be rewritten to never block the API call waiting on an HTTP response; should initiate these asynchronously.

And until then, or even afterwards in case other plugins will reintroduce similar bugs:

May be better for asynchPeople to list all users in a first pass, then go back and resolve avatars in a second pass.
HudsonPrivateSecurityRealm/index.jelly and similar pages should avoid asking for the avatar synchronously in the HTTP handling thread. Can use ProgressiveRendering or perform the avatar calculation in the URL handler for the <img> rather than when producing the page.

Some things remain to be done to make UserAvatarResolver consistently quick:

SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way.
UserGravatarResolver should be rewritten to never block the API call waiting on an HTTP response; should initiate these asynchronously.

And until then, or even afterwards in case other plugins will reintroduce similar bugs:

May be better for asynchPeople to list all users in a first pass, then go back and resolve avatars in a second pass.
HudsonPrivateSecurityRealm/index.jelly and similar pages should avoid asking for the avatar synchronously in the HTTP handling thread. Can use ProgressiveRendering or perform the avatar calculation in the URL handler for the rather than when producing the page.

dogfood:

Original comment link

Raw content of original comment:

Integrated in jenkins_main_trunk #2191 ~~JENKINS-16342~~ Improving responsiveness of asynchPeople when Gravatar plugin is in use. (Revision c757e65431ad1aec9a3bebe81ac919577e51ac58)

Result = SUCCESS Jesse Glick : c757e65431ad1aec9a3bebe81ac919577e51ac58 Files :

core/src/main/java/hudson/model/View.java
changelog.html

Integrated in jenkins_main_trunk #2191
~~JENKINS-16342~~ Improving responsiveness of asynchPeople when Gravatar plugin is in use. (Revision c757e65)

Result = SUCCESS
Jesse Glick : c757e65431ad1aec9a3bebe81ac919577e51ac58
Files :

core/src/main/java/hudson/model/View.java
changelog.html

jglick:

Original comment link

Raw content of original comment:

Serious enough to potentially merit backport to 1.480.x.

jglick:

Original comment link

Raw content of original comment:

Gravatar plugin could probably take advantage of new resolveFast.

kutzi:

Original comment link

Raw content of original comment:

> SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way.

Absolutely +1 for deleting this - as well as in all other SCM plugin where something analogue is implemented! These MailAddressResolvers are implemented in a so ridiculous inefficient way and their usefulness is IMHO very very limited.

> SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way.

Absolutely +1 for deleting this - as well as in all other SCM plugin where something analogue is implemented!
These MailAddressResolvers are implemented in a so ridiculous inefficient way and their usefulness is IMHO very very limited.

vjuranek:

Original comment link

Raw content of original comment:

+1 to remove MailAddressResolvers or at least make them optional

jglick:

Original comment link
Raw content of original comment:
```
@kutzi, @vjuranek: see JENKINS-16437.
```

@kutzi, @vjuranek: see ~~JENKINS-16437~~.

scm_issue_link:

Original comment link

Raw content of original comment:

Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/View.java http://jenkins-ci.org/commit/jenkins/bd03abbcc0078c2f250c2e3ee2c8d3c4a9d210ca Log: ~~JENKINS-16342~~ Improving responsiveness of asynchPeople when Gravatar plugin is in use. This change does not necessarily improve total performance, since the avatar is still computed. But (1) the computation is correctly done in the work thread, not in the HTTP response thread; (2) the computation is done just once for a given User, which could reduce load when many AJAX checks are done.(cherry picked from commit c757e65431ad1aec9a3bebe81ac919577e51ac58)

Conflicts: changelog.html

Compare: cb6f200...bd03abb

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/model/View.java
http://jenkins-ci.org/commit/jenkins/bd03abbcc0078c2f250c2e3ee2c8d3c4a9d210ca
Log:
~~JENKINS-16342~~ Improving responsiveness of asynchPeople when Gravatar plugin is in use.
This change does not necessarily improve total performance, since the avatar is still computed.
But (1) the computation is correctly done in the work thread, not in the HTTP response thread;
(2) the computation is done just once for a given User, which could reduce load when many AJAX checks are done.(cherry picked from commit c757e65)

Conflicts:
changelog.html

Compare: cb6f200...bd03abb

kutzi:

Original comment link

Raw content of original comment:

Now that ~~JENKINS-15440~~ is fixed, I think this can be closed, too.

jglick:

Original comment link

Raw content of original comment:

@kutzi I think there is still work to be done in making UserGravatarResolver nonblocking (independently of MailAddressResolver) and/or making various UI elements displaying avatars not block rendering on the result. But these things do not need to be tracked in this issue I suppose.

[Original depends_on from Jira: JENKINS-15440]

[Original depends_on from Jira: JENKINS-18118]

[Original depends_on from Jira: JENKINS-16437]

Navigation Menu

Repository navigation

[JENKINS-16342] asynchPeople very slow when using Gravatar & Subversion plugins #13215

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[JENKINS-16342] asynchPeople very slow when using Gravatar & Subversion plugins #13215

Description

Activity

jenkins-infra-bot commented on Jan 14, 2013

jenkins-infra-bot commented on Jan 15, 2013

jenkins-infra-bot commented on Jan 15, 2013

jenkins-infra-bot commented on Jan 15, 2013

jenkins-infra-bot commented on Jan 17, 2013

jenkins-infra-bot commented on Jan 17, 2013

jenkins-infra-bot commented on Jan 17, 2013

jenkins-infra-bot commented on Jan 25, 2013

jenkins-infra-bot commented on Jan 25, 2013

jenkins-infra-bot commented on Jan 25, 2013

jenkins-infra-bot commented on Feb 3, 2013

jenkins-infra-bot commented on Feb 4, 2013

jenkins-infra-bot commented on Nov 24, 2025

jenkins-infra-bot commented on Nov 24, 2025

jenkins-infra-bot commented on Nov 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions