Details

      Description

      We are noticing that the portal admin interface is starting to get very slow.
      It apparently has to do with the amount of "portal objects" in the database.
      The portal seems to create a dashboard for each user so if there are 10000 users
      there are also at least that many portal objects.

      In my tests I noticed that the database access takes about half of the time and
      the method refresh() in PortalObjectManagerBean is also very slow.
      This part is the slow part in that method (the iterator is probably the culprit, there
      seems to be some "custom" implementation for it).

      ===
      Collection portals = getSelectedObject().getChildren(PortalObject.PORTAL_MASK);
      ArrayList portalList = new ArrayList(portals.size() + 1);
      for (Iterator iterator = portals.iterator(); iterator.hasNext()

      { PortalObject o = (PortalObject)iterator.next(); SelectItem item = new SelectItem(o.getName()); portalList.add(item); }

      portalList.add(new SelectItem("", "no selection"));
      portalItems = (SelectItem[])portalList.toArray(new SelectItem[portalList.size()]);
      ===

      This of course loops through all the "portal" type objects including all the user's
      dashboards.
      An easy optimization would be to discard the dashboard object looping when using the admin
      interface because the dashboards are naturally not needed there (maybe a new type of
      mask or something?).

      Other problems that would be good to check is the iterator (eg. hasNext() and getting the next
      object), and also why is there generated such a huge amount of SQL SELECTs (at least one per portal object).

      (The following assumes that I can add attachments to this issue)

      I have attached a zip file that can be extracted into a freshly installed (ie. extracted zip) portal installation
      (the AS bundled version of 2.6.5) The zip contains the "server" folder so extract it at the root of the
      portal installation and overwrite all files.

      After the portal is started you can go to the timing report page at:
      http://localhost:8080/test/jamon/jamonadmin.jsp
      There you can reset the counters, access a page in the admin console, and click refresh.
      After that you can sort the results by eg. the "total" column to see where time is spent.
      Currently it logs the sql-statements and the refresh method in PortlaObjectManagerBean.
      The timings for PortlaObjectManagerBean are split in three different parts with "*refresh"
      being the time for the whole method, "*portals" the time for iterating through the portals
      and "*pages" the time for looping through the pages.

      Now at this stage everything is OK and the response times are good.
      I have included a servlet that generates 10000 dashboards. Go to
      http://localhost:8080/test/create
      and wait (it takes a while, the console printsthe progress.)
      Load this page only once.

      After the dashboards have been created you can again test the admin console and
      check the JAmon report page for results.

      I have also included some screenshots from my testruns.
      The first (jamon1.gif) is from a newly installed instance listing the portals in the
      admin console.
      The second (jamon2.gif) is the same portal list after the dashboards have been created.
      The third (jamon3.gif) is after clicking "portlet instances" page. Notice how here is
      generated 40000 sql selects.

      Note that the included java db is quite fast at these selects. A mysql installation usually takes
      about 10 seconds for 10000 selects of this type.

        Gliffy Diagrams

          Attachments

          1. jamon1.gif
            jamon1.gif
            39 kB
          2. jamon2.gif
            jamon2.gif
            44 kB
          3. jamon3.gif
            jamon3.gif
            44 kB
          4. server.zip
            465 kB

            Issue Links

              Activity

                People

                • Assignee:
                  claprun Chris Laprun
                  Reporter:
                  frontline2 front line
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: