Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-50513

GC overhead caused by PortletRequestUtil.toXML()

    Details

      Description

      Please note this is very hard to reproduce and doesn't occur in every environment. The test case described here was conducted with the customer's data in a similar environment like theirs.

      Description

      Method PortletRequestUtil.toXML() serializes the actual portlet request to XML, which happens indirectely when a web content is displayed. While a user is browsing throught a portal with many pages and with many Web Content Displays, their session is growing ever larger, because method SessionAuthToken.getToken(HttpServletRequest, long, String) is persisting new LIFERAY_SHARED_AUTHENTICATION_TOKEN##PLID##LAYOUT##PORTLETID## = ##RANDOMSTRING## attributes into the session for every unique (plid, portletId) pair.

      When PortletRequestUtil.toXML() gets executed the resulting XML will contain many of the following element as children of application-attributes.

      <attribute>
        <name>LIFERAY_SHARED_AUTHENTICATION_TOKEN##PLID##_LAYOUT_##PORTLETID##</name>
        <value>##RANDOMSTRING##</value>
      </attribute>
      

      Consequently, due to the fact that large strings are allocated frequently, under load, the system is seeing increased GC activity.

      During testing, I captured the output of requestElement.toXMLString() at the end of method toXML(). before.xml and after.xml denotes the contents of the resulting XML respectively for the same use case before and after the fix.

      % ls -hgG /tmp/{before.xml,after.xml}
      -rw-rw-r-- 1  22K okt    1 09:07 /tmp/after.xml
      -rw-rw-r-- 1 110K okt    1 09:07 /tmp/before.xml
      

      Notes for QA

      • Measuring the GC overhead isn't directly possible, because we cannot replay that workload the customer has.
      • I used the customer's data, but you can use a vanilla Liferay with ~10 pages with ~10 Web Content Displays on each
      • After visiting each page, the contents of requestElement.toXMLString() can be observed with a debugger.
      • When the fix is applied the value of requestElement.toXMLString() should be significantly smaller.
      • This is a 6.x only issue, on Master LPS-45558 eliminates the unnecessary XML serialization overhead.

        Attachments

        1. a.xml
          133 kB
        2. after.xml
          109 kB
        3. before.xml
          212 kB

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  4 years, 1 week, 5 days ago

                  Packages

                  Version Package