yahoo-eng-team team mailing list archive

[Jay Jahns <jjahns@xxxxxxxxxx>]

I've added Keystone, in case this is keystone-related.

Basically, if the API is v2.0, then we support pagination on the
Identity => Projects page, which can help with performance.

If the API is v3, we don't perform any pagination. Essentially, if
someone has hundreds of projects, then this page is completely unusable,
making it pointless to even use the Identity dashboards if > 100 records
exist for any section.

There has to be better controls over pagination here. It is unnecessary
load on the node running Horizon.

** Also affects: keystone
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1720416

Title:
  Ui Performance in Ocata when viewing Identity tabs is horrible

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (keystone):
  New

Bug description:
  Hello,

  The Identity dashboard, responsible for showing Domains, Users,
  Groups, Projects, and Roles, suffers terribly when viewing items like
  Projects.

  Our private production runs about 435 projects, and slightly more than
  350 users.

  For example, to view all projects, the UI takes about 18-20 seconds to
  properly render. The API call to view projects: openstack project
  list, takes about 2 seconds.

  It seems like rendering this data in Angular is the culprit, but I
  have not been able to pinpoint anywhere to indicate it.

  We are using UWSGI and HTTP-Socket mode. I have a haproxy load
  balancer in front of this node, and I observed the same if not worse
  performance with using Nginx or Apache on the same node proxying the
  UWSGI.

  This is my uwsgi load at idle:
  https://gist.github.com/jjahns/79bc336c447a5718afff2edcf0f3bd83

  This is my uwsgi load when the projects tab is being pulled:
  https://gist.github.com/jjahns/abac52381e7eb77f86ab92ed55b86e28

  The render time here was approximately 18 seconds. Only one CPU core
  was used, despite all of these processes, and it was pinned at 100% as
  well.

  We've tried Apache with the same results. We've also tried using
  Nginx, and no yielded benefit.

  If this is a configuration problem, then someone should explain how to
  correct.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1720416/+subscriptions