tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-1929) High contention in method InternalComponentResourcesImpl.postRenderCleanup() and NamedSet.getValues()
Date Sat, 12 May 2012 07:31:50 GMT

    [ https://issues.apache.org/jira/browse/TAP5-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273877#comment-13273877
] 

Hudson commented on TAP5-1929:
------------------------------

Integrated in tapestry-5.3-freestyle #27 (See [https://builds.apache.org/job/tapestry-5.3-freestyle/27/])
    TAP5-1929: Performance improvements
Rework page loading and lazily initialization inside InternalComponentResourcesImpl to avoid
some synchronization hotspots (Revision 1337454)

     Result = FAILURE
hlship : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1337454
Files : 
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/ComponentResources.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/structure/ComponentPageElementImpl.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/structure/InternalComponentResourcesImpl.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/structure/Page.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/structure/PageImpl.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/structure/PageResetListener.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/structure/StructureMessages.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/transform/InjectComponentWorker.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/transform/ParameterConduit.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/transform/ParameterWorker.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/internal/util/NamedSet.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/runtime/PageLifecycleAdapter.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/runtime/PageLifecycleCallbackHub.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/java/org/apache/tapestry5/runtime/PageLifecycleListener.java
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/main/resources/org/apache/tapestry5/internal/structure/StructureStrings.properties
* /tapestry/tapestry5/branches/5.3/tapestry-core/src/test/java/org/apache/tapestry5/internal/structure/PageImplTest.java

                
> High contention in method InternalComponentResourcesImpl.postRenderCleanup() and NamedSet.getValues()
> -----------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1929
>                 URL: https://issues.apache.org/jira/browse/TAP5-1929
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.3.3, 5.4
>            Reporter: Howard M. Lewis Ship
>            Assignee: Howard M. Lewis Ship
>              Labels: performance, synchonized
>
> From the mailing list:
>     we want to rollout a Tapestry app very shortly, but we struggle with
>     load testing issues. We are currently load testing on one Tomcat 6.0.32:
>     - 500 worker threads, tapestry.production-mode=true
>     - Intel(R) Xeon(R) CPU X7460  @ 2.66GHz
>     - OpenJDK Runtime Environment (IcedTea6 1.7.10)
>     (rhel-1.20.b17.el5-x86_64) OpenJDK 64-Bit Server VM (build 14.0-b16,
>     mixed mode))
>     and 2 loadrunner test clients.
>     After ramping up the concurrent requests (about 5min) we reach the
>     maximum at about 450req/sec and get server busy errors. We see a high
>     thread contention on InternalComponentResourcesImpl.postRenderCleanup
>     currently with the Loop component, as there 10 Loop on the Index page.
>     Is there a workaround possible without removing the Loop component from
>     the page to increase the throughput? The thread dumps series looks like
>     this: 1 thread locks 0x00000000e3858990 and over 400 threads are
>     waiting. This lock is persistent over a thread dumps series. I guess the
>     private synchronized Map<String, Object> getRenderVariables(boolean
>     create) call hits us.
>     "http-9080-188" daemon prio=10 tid=0x000000004d463000 nid=0x382a
>     runnable [0x0000000055b2f000]
>       java.lang.Thread.State: RUNNABLE
>        at
>     org.apache.tapestry5.internal.transform.ParameterWorker$3$1.getState(ParameterWorker.java:206)
>        at
>     org.apache.tapestry5.internal.transform.ParameterWorker$3$1.reset(ParameterWorker.java:302)
>        at
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.work(InternalComponentResourcesImpl.java:136)
>        at
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.work(InternalComponentResourcesImpl.java:133)
>        at
>     org.apache.tapestry5.internal.util.NamedSet.eachValue(NamedSet.java:171)
>        - locked <0x00000000e3858990> (a
>     org.apache.tapestry5.internal.util.NamedSet)
>        at
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.resetParameterConduits(InternalComponentResourcesImpl.java:546)
>        - locked <0x00000000e385c038> (a
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl)
>        at
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.postRenderCleanup(InternalComponentResourcesImpl.java:522)
>        at
>     org.apache.tapestry5.corelib.components.Loop.postRenderCleanup(Loop.java)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl$1.run(ComponentPageElementImpl.java:85)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:956)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$1800(ComponentPageElementImpl.java:61)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl$PostRenderCleanupPhase.render(ComponentPageElementImpl.java:443)
>        at
>     org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:72)
>        at
>     org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:124)
>        at $PageRenderQueue_135675e1f6b934.render(Unknown Source)
>        at $PageRenderQueue_135675e1f6b933.render(Unknown Source)
>        at
>     org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37)
>     ...
>     "http-9080-499" daemon prio=10 tid=0x000000004dffb000 nid=0x3b7d waiting
>     for monitor entry [0x0000000069063000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getRenderVariables(InternalComponentResourcesImpl.java:476)
>        - waiting to lock <0x00000000e385c038> (a
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl)
>        at
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.postRenderCleanup(InternalComponentResourcesImpl.java:517)
>        at
>     org.apache.tapestry5.corelib.components.Loop.postRenderCleanup(Loop.java)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl$1.run(ComponentPageElementImpl.java:85)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:956)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$1800(ComponentPageElementImpl.java:61)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl$PostRenderCleanupPhase.render(ComponentPageElementImpl.java:443)
>        at
>     org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:72)
>        at
>     org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:124)
>        at $PageRenderQueue_135675e1f6b934.render(Unknown Source)
>        at $PageRenderQueue_135675e1f6b933.render(Unknown Source)
>        at
>     org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37)
>     ...
>     Additionally we experienced a similar issue when using a component with
>     a mixin annotation in a loop, that was rendered more than 20 times on
>     the page.
>     The contention here was on the
>     org.apache.tapestry5.internal.util.NamedSet.getValues call
>     "http-9080-79" daemon prio=10 tid=0x00000000588dc000 nid=0x3e61 waiting
>     for monitor entry [0x000000004ad98000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at
>     org.apache.tapestry5.internal.util.NamedSet.getValues(NamedSet.java:78)
>        - waiting to lock <0x00000000e2fa4d70> (a
>     org.apache.tapestry5.internal.util.NamedSet)
>        at
>     org.apache.tapestry5.internal.util.NamedSet.getValues(NamedSet.java:257)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl.mixinForClassName(ComponentPageElementImpl.java:892)
>        at
>     org.apache.tapestry5.internal.structure.ComponentPageElementImpl.getMixinByClassName(ComponentPageElementImpl.java:879)mvn
>        at
>     org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getMixinByClassName(InternalComponentResourcesImpl.java:366)
>        at
>     org.apache.tapestry5.internal.transform.MixinWorker$1$1.get(MixinWorker.java:92)
>        at
>     biz.toc.buyme.client.webapp.core.components.DHTMLTimer.conduit_get__informalElement(DHTMLTimer.java)
> Since these are areas of high contention, we can change them to use an explicit Lock
instance so that in the normal case (all readers, no writers), there is no contention or synchronization.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message