GUI project pulldown list slowdown on large number of projects

[DagSonsteboSB]

ISSUE TYPE

• Improvement Request

COMPONENT NAME

• ACS GUI

CLOUDSTACK VERSION

• Reproduced on ACS 4.11.2

CONFIGURATION

• ACS 4.11.2
• Problem is environment agnostic

OS / ENVIRONMENT

• ACS management on CentOS7

SUMMARY

• When number of projects is large (thousands) and there's a lot of tags in use (hundreds) then the ACS GUI pulldown menu slows down drastically to the point it sometimes fails to show the project list
• Initial code investigation shows this could be down to:
  ** Code looks up all projects - active and inactive
  ** Then runs multiple loops against tags
  ** As a result processing is carried out with inactive projects included
• Code investigation shows this procedure could be made more efficient by only processing active project thereby cutting down on tag lookup processing time.

STEPS TO REPRODUCE

• Create thousands of projects, leave a handful active, the rest inactive
• Tag the projects with 10-20 tags each
• Use project pulldown menu in CloudStack GUI

EXPECTED RESULTS

• Relatively quick pulldown menu population

ACTUAL RESULTS

• Pulldown menu population can take 10-20 seconds to populate and will sometimes not populate at all (assuming due to timeout somewhere)

[JnSchl]

Hi, we encounter the same behavior but with less projects (in the small three-digit range). Also non root users are affected by the longer loading times if only their projects are listed.

[voteforpresident]

We are experiencing the same issue on the Cloudstack Version 4.11.2.

[ustcweizhou]

We had similar issue on listing vms if vms have several tags.
We fixed it by recreating view without resource tag, and get resource tags by a query in server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java.

         // update tag information
-        long tag_id = userVm.getTagId();
-        if (tag_id > 0 && !userVmResponse.containTag(tag_id)) {
-            ResourceTagJoinVO vtag = ApiDBUtils.findResourceTagViewById(tag_id);
-            if (vtag != null) {
-                userVmResponse.addTag(ApiDBUtils.newResourceTagResponse(vtag, false));
-            }
+        List<ResourceTagJoinVO> tags = ApiDBUtils.listResourceTagViewByResourceUUID(userVm.getUuid(), ResourceObjectT
+ype.UserVm);
+        for (ResourceTagJoinVO vtag : tags) {
+            userVmResponse.addTag(ApiDBUtils.newResourceTagResponse(vtag, false));
         }

@@ -406,14 +404,6 @@ public class UserVmJoinDaoImpl extends GenericDaoBase<UserVmJoinVO, Long> implem
             userVmData.addNic(nicResponse);
         }

-        long tag_id = uvo.getTagId();
-        if (tag_id > 0 && !userVmData.containTag(tag_id)) {
-            ResourceTagJoinVO vtag = ApiDBUtils.findResourceTagViewById(tag_id);
-            if (vtag != null) {
-                userVmData.addTag(ApiDBUtils.newResourceTagResponse(vtag, false));
-            }
-        }
-

it would be better to remove resource tags from all views because it leads to too many records in views.

[yadvr]

@ustcweizhou can you send a PR to master?

[ustcweizhou]

@rhtyd will do

[svenvogel]

@ustcweizhou we encounter the same problem. If you find some time maybe you can send a PR to the master.

[ustcweizhou]

@svenvogel @rhtyd @DagSonsteboSB
PR has been created for this issue: #3306

We have similar issue while listing vms, I will create another pull request when #3306 is merged because it requires db change as well.

[yadvr]

Ping @anuragaw