Howard, thank you very much for the quick and insightful response. I haven't yet understood the code completely, why that many synchronized methods are invoked like ( private synchronized void resetParameterConduits() etc) I would be really happy to test your "shortly and crank out a 5.3.4-rc-1 snapshot" version as soon as it will be available! Let me know, if I can assist you in someway.
All the Best and Thx Robert Am 11.05.2012 18:34, schrieb Howard Lewis Ship: > In case I wasn't clear; I'm waiting for a commitment that you will > retest with updated Tapestry code before I make the changes. I'm > willing to juggle my schedule to assist, if you're ready to do your > part. > > On Fri, May 11, 2012 at 9:06 AM, Howard Lewis Ship <hls...@gmail.com> wrote: >> That's an interesting result. Why, oh why, did I ever implement >> render variables? >> >> So the conventional thinking on synchronized methods is that they >> where there is limited contention, and the method is short, >> synchronized is the best way to go. >> >> This method exists, and is synchronized, to avoid creating a >> PerThreadValue to store the render variable's Map on every component >> and mixin in the application. That adds up, given that only a tiny >> percentage of pages or components will ever use a render variable. >> >> I'd be willing to replace this code with something that uses an >> explicit per-instance Lock ... that would likely help with your high >> contention issues, as after the PerThreadValue is created, and the >> write lock is released, there would no longer be contention, as all >> threads could share the read lock. >> >> I can put that together shortly and crank out a 5.3.4-rc-1 snapshot, >> if you can then pick it up and test it. >> >> Further comments here: https://issues.apache.org/jira/browse/TAP5-1929 >> >> On Fri, May 11, 2012 at 6:07 AM, Robert Lentz <rob...@teksolv.de> wrote: >>> Hi All, >>> >>> 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) >>> >>> For the time being we removed the mixin, but on the loop issue I am >>> clueless. >>> Any suggestions or tips are very welcomed. >>> Kind Regards >>> Robert Lentz >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
