[JBoss JIRA] (JBSEAM-5075) Improve Seam2.3 performance
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-5075?page=com.atlassian.jira.plugi... ]
Marek Novotny updated JBSEAM-5075:
----------------------------------
Attachment: (was: Response time.jpeg)
> Improve Seam2.3 performance
> ---------------------------
>
> Key: JBSEAM-5075
> URL: https://issues.jboss.org/browse/JBSEAM-5075
> Project: Seam 2
> Issue Type: Enhancement
> Components: Performance and Scalability
> Affects Versions: 2.3.0.Final
> Environment: AS 7.1.3.Final (EAP 6.0.1)
> Reporter: Tomas Remes
>
> I've run several performance (especially load) tests comparing Seam2.3 to Seam2.2. I am using modified numberguess example running on AS 7.1.3.Final (EAP 6.0.1). Major difference between those two versions is that Seam2.2 uses JSF-1.2 (Mojarra-1.2_15-b01-FCS) and Seam2.3 uses JSF-2.1 (Mojarra 2.1.13-jbossorg-1). The tests shows significantly worse results of Seam2.3 release especially in response time values. Literally Seam2.3 reaches only about 50% of response time values in comparison to Seam2.2 version. In other words that is two times worse. Profiling shows following points, which can be IMHO improved:
> 1) Implementation of SeamVieHandler's restoreView method. This method currently allocates approximately 10x times more memory than related one from Seam2.2 (it uses FaceletViewHandler.restoreView). Removing (returning to Seam2.2 implementation) following lines from this method can bring performance improvement (I've already tried that):
> {noformat}
> UIViewRoot viewRoot =viewHandler.restoreView(ctx, viewId);
> if (viewRoot != null)
> {
> viewRoot.setViewId(viewHandler.deriveViewId(ctx,viewId));
> }
> {noformat}
> 2) Implementation of Contexts.isPageContextActive method. This also shows some regression when comparing memory allocation to related methods - ConversationPropagation.restoreConversationId and Manager.restoreConversation. IMHO this can be reimplemented somehow too.
> 3) Implementation of StatusMessages.instance() method. This also brings small regression in memory allocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBSEAM-5075) Improve Seam2.3 performance
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-5075?page=com.atlassian.jira.plugi... ]
Tomas Remes updated JBSEAM-5075:
--------------------------------
Attachment: Response time.jpeg
Graph attached. I'll continue on investigation of mentioned issues.
> Improve Seam2.3 performance
> ---------------------------
>
> Key: JBSEAM-5075
> URL: https://issues.jboss.org/browse/JBSEAM-5075
> Project: Seam 2
> Issue Type: Enhancement
> Components: Performance and Scalability
> Affects Versions: 2.3.0.Final
> Environment: AS 7.1.3.Final (EAP 6.0.1)
> Reporter: Tomas Remes
> Attachments: Response time, Response time.jpeg
>
>
> I've run several performance (especially load) tests comparing Seam2.3 to Seam2.2. I am using modified numberguess example running on AS 7.1.3.Final (EAP 6.0.1). Major difference between those two versions is that Seam2.2 uses JSF-1.2 (Mojarra-1.2_15-b01-FCS) and Seam2.3 uses JSF-2.1 (Mojarra 2.1.13-jbossorg-1). The tests shows significantly worse results of Seam2.3 release especially in response time values. Literally Seam2.3 reaches only about 50% of response time values in comparison to Seam2.2 version. In other words that is two times worse. Profiling shows following points, which can be IMHO improved:
> 1) Implementation of SeamVieHandler's restoreView method. This method currently allocates approximately 10x times more memory than related one from Seam2.2 (it uses FaceletViewHandler.restoreView). Removing (returning to Seam2.2 implementation) following lines from this method can bring performance improvement (I've already tried that):
> {noformat}
> UIViewRoot viewRoot =viewHandler.restoreView(ctx, viewId);
> if (viewRoot != null)
> {
> viewRoot.setViewId(viewHandler.deriveViewId(ctx,viewId));
> }
> {noformat}
> 2) Implementation of Contexts.isPageContextActive method. This also shows some regression when comparing memory allocation to related methods - ConversationPropagation.restoreConversationId and Manager.restoreConversation. IMHO this can be reimplemented somehow too.
> 3) Implementation of StatusMessages.instance() method. This also brings small regression in memory allocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBSEAM-5075) Improve Seam2.3 performance
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-5075?page=com.atlassian.jira.plugi... ]
Tomas Remes updated JBSEAM-5075:
--------------------------------
Attachment: Response time
> Improve Seam2.3 performance
> ---------------------------
>
> Key: JBSEAM-5075
> URL: https://issues.jboss.org/browse/JBSEAM-5075
> Project: Seam 2
> Issue Type: Enhancement
> Components: Performance and Scalability
> Affects Versions: 2.3.0.Final
> Environment: AS 7.1.3.Final (EAP 6.0.1)
> Reporter: Tomas Remes
> Attachments: Response time
>
>
> I've run several performance (especially load) tests comparing Seam2.3 to Seam2.2. I am using modified numberguess example running on AS 7.1.3.Final (EAP 6.0.1). Major difference between those two versions is that Seam2.2 uses JSF-1.2 (Mojarra-1.2_15-b01-FCS) and Seam2.3 uses JSF-2.1 (Mojarra 2.1.13-jbossorg-1). The tests shows significantly worse results of Seam2.3 release especially in response time values. Literally Seam2.3 reaches only about 50% of response time values in comparison to Seam2.2 version. In other words that is two times worse. Profiling shows following points, which can be IMHO improved:
> 1) Implementation of SeamVieHandler's restoreView method. This method currently allocates approximately 10x times more memory than related one from Seam2.2 (it uses FaceletViewHandler.restoreView). Removing (returning to Seam2.2 implementation) following lines from this method can bring performance improvement (I've already tried that):
> {noformat}
> UIViewRoot viewRoot =viewHandler.restoreView(ctx, viewId);
> if (viewRoot != null)
> {
> viewRoot.setViewId(viewHandler.deriveViewId(ctx,viewId));
> }
> {noformat}
> 2) Implementation of Contexts.isPageContextActive method. This also shows some regression when comparing memory allocation to related methods - ConversationPropagation.restoreConversationId and Manager.restoreConversation. IMHO this can be reimplemented somehow too.
> 3) Implementation of StatusMessages.instance() method. This also brings small regression in memory allocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBSEAM-5075) Improve Seam2.3 performance
by Tomas Remes (JIRA)
Tomas Remes created JBSEAM-5075:
-----------------------------------
Summary: Improve Seam2.3 performance
Key: JBSEAM-5075
URL: https://issues.jboss.org/browse/JBSEAM-5075
Project: Seam 2
Issue Type: Enhancement
Components: Performance and Scalability
Affects Versions: 2.3.0.Final
Environment: AS 7.1.3.Final (EAP 6.0.1)
Reporter: Tomas Remes
I've run several performance (especially load) tests comparing Seam2.3 to Seam2.2. I am using modified numberguess example running on AS 7.1.3.Final (EAP 6.0.1). Major difference between those two versions is that Seam2.2 uses JSF-1.2 (Mojarra-1.2_15-b01-FCS) and Seam2.3 uses JSF-2.1 (Mojarra 2.1.13-jbossorg-1). The tests shows significantly worse results of Seam2.3 release especially in response time values. Literally Seam2.3 reaches only about 50% of response time values in comparison to Seam2.2 version. In other words that is two times worse. Profiling shows following points, which can be IMHO improved:
1) Implementation of SeamVieHandler's restoreView method. This method currently allocates approximately 10x times more memory than related one from Seam2.2 (it uses FaceletViewHandler.restoreView). Removing (returning to Seam2.2 implementation) following lines from this method can bring performance improvement (I've already tried that):
{noformat}
UIViewRoot viewRoot =viewHandler.restoreView(ctx, viewId);
if (viewRoot != null)
{
viewRoot.setViewId(viewHandler.deriveViewId(ctx,viewId));
}
{noformat}
2) Implementation of Contexts.isPageContextActive method. This also shows some regression when comparing memory allocation to related methods - ConversationPropagation.restoreConversationId and Manager.restoreConversation. IMHO this can be reimplemented somehow too.
3) Implementation of StatusMessages.instance() method. This also brings small regression in memory allocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBSEAM-5074) Excel example SeamTest failure UnsupportedOperationException in ExternalContext.getRequestCharacterEncoding
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-5074?page=com.atlassian.jira.plugi... ]
Marek Schmidt updated JBSEAM-5074:
----------------------------------
Fix Version/s: 2.3.1.CR1
(was: 2.3.1.Final)
> Excel example SeamTest failure UnsupportedOperationException in ExternalContext.getRequestCharacterEncoding
> -----------------------------------------------------------------------------------------------------------
>
> Key: JBSEAM-5074
> URL: https://issues.jboss.org/browse/JBSEAM-5074
> Project: Seam 2
> Issue Type: Bug
> Components: Test Harness
> Affects Versions: 2.3.1.CR1
> Environment: Seam 2.3.1-SNAPSHOT, AS 7.2.0.Alpha1-SNAPSHOT (2013-02-08)
> Reporter: Marek Schmidt
> Assignee: Marek Schmidt
> Fix For: 2.3.1.CR1
>
>
> Excel SeamTest failure:
> {noformat}
> Caused by: java.lang.UnsupportedOperationException
> at javax.faces.context.ExternalContext.getRequestCharacterEncoding(ExternalContext.java:945)
> at com.sun.faces.facelets.compiler.SAXCompiler.getEncoding(SAXCompiler.java:453)
> at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:420)
> at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:401)
> at com.sun.faces.facelets.compiler.Compiler.compile(Compiler.java:124)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:304)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.access$100(DefaultFaceletFactory.java:92)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:159)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:157)
> at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:83)
> at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:78)
> at com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache.java:114)
> at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:121)
> at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:62)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:255)
> at org.jboss.seam.ui.facelet.RendererRequest.faceletForViewId(RendererRequest.java:128)
> at org.jboss.seam.ui.facelet.RendererRequest.run(RendererRequest.java:106)
> at org.jboss.seam.ui.facelet.FaceletsRenderer.render(FaceletsRenderer.java:43)
> at org.jboss.seam.example.excel.test.RenderTest$1.invokeApplication(RenderTest.java:62)
> at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:664)
> at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:613)
> at org.jboss.seam.mock.AbstractSeamTest$Request.access$100(AbstractSeamTest.java:184)
> at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:513)
> ... 127 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBSEAM-5074) Excel example SeamTest failure UnsupportedOperationException in ExternalContext.getRequestCharacterEncoding
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-5074?page=com.atlassian.jira.plugi... ]
Marek Schmidt updated JBSEAM-5074:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/seam2/jboss-seam/pull/13
> Excel example SeamTest failure UnsupportedOperationException in ExternalContext.getRequestCharacterEncoding
> -----------------------------------------------------------------------------------------------------------
>
> Key: JBSEAM-5074
> URL: https://issues.jboss.org/browse/JBSEAM-5074
> Project: Seam 2
> Issue Type: Bug
> Components: Test Harness
> Affects Versions: 2.3.1.CR1
> Environment: Seam 2.3.1-SNAPSHOT, AS 7.2.0.Alpha1-SNAPSHOT (2013-02-08)
> Reporter: Marek Schmidt
> Assignee: Marek Schmidt
> Fix For: 2.3.1.Final
>
>
> Excel SeamTest failure:
> {noformat}
> Caused by: java.lang.UnsupportedOperationException
> at javax.faces.context.ExternalContext.getRequestCharacterEncoding(ExternalContext.java:945)
> at com.sun.faces.facelets.compiler.SAXCompiler.getEncoding(SAXCompiler.java:453)
> at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:420)
> at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:401)
> at com.sun.faces.facelets.compiler.Compiler.compile(Compiler.java:124)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:304)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.access$100(DefaultFaceletFactory.java:92)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:159)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:157)
> at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:83)
> at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:78)
> at com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache.java:114)
> at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:121)
> at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:62)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:255)
> at org.jboss.seam.ui.facelet.RendererRequest.faceletForViewId(RendererRequest.java:128)
> at org.jboss.seam.ui.facelet.RendererRequest.run(RendererRequest.java:106)
> at org.jboss.seam.ui.facelet.FaceletsRenderer.render(FaceletsRenderer.java:43)
> at org.jboss.seam.example.excel.test.RenderTest$1.invokeApplication(RenderTest.java:62)
> at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:664)
> at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:613)
> at org.jboss.seam.mock.AbstractSeamTest$Request.access$100(AbstractSeamTest.java:184)
> at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:513)
> ... 127 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBSEAM-5074) Excel example SeamTest failure UnsupportedOperationException in ExternalContext.getRequestCharacterEncoding
by Marek Schmidt (JIRA)
Marek Schmidt created JBSEAM-5074:
-------------------------------------
Summary: Excel example SeamTest failure UnsupportedOperationException in ExternalContext.getRequestCharacterEncoding
Key: JBSEAM-5074
URL: https://issues.jboss.org/browse/JBSEAM-5074
Project: Seam 2
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.3.1.CR1
Environment: Seam 2.3.1-SNAPSHOT, AS 7.2.0.Alpha1-SNAPSHOT (2013-02-08)
Reporter: Marek Schmidt
Assignee: Marek Schmidt
Fix For: 2.3.1.Final
Excel SeamTest failure:
{noformat}
Caused by: java.lang.UnsupportedOperationException
at javax.faces.context.ExternalContext.getRequestCharacterEncoding(ExternalContext.java:945)
at com.sun.faces.facelets.compiler.SAXCompiler.getEncoding(SAXCompiler.java:453)
at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:420)
at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:401)
at com.sun.faces.facelets.compiler.Compiler.compile(Compiler.java:124)
at com.sun.faces.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:304)
at com.sun.faces.facelets.impl.DefaultFaceletFactory.access$100(DefaultFaceletFactory.java:92)
at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:159)
at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:157)
at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:83)
at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:78)
at com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache.java:114)
at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:121)
at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:62)
at com.sun.faces.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:255)
at org.jboss.seam.ui.facelet.RendererRequest.faceletForViewId(RendererRequest.java:128)
at org.jboss.seam.ui.facelet.RendererRequest.run(RendererRequest.java:106)
at org.jboss.seam.ui.facelet.FaceletsRenderer.render(FaceletsRenderer.java:43)
at org.jboss.seam.example.excel.test.RenderTest$1.invokeApplication(RenderTest.java:62)
at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:664)
at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:613)
at org.jboss.seam.mock.AbstractSeamTest$Request.access$100(AbstractSeamTest.java:184)
at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:513)
... 127 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBSEAM-5045) Ajax error not calling ExceptionFilter
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-5045?page=com.atlassian.jira.plugi... ]
Marek Schmidt updated JBSEAM-5045:
----------------------------------
Priority: Critical (was: Major)
> Ajax error not calling ExceptionFilter
> --------------------------------------
>
> Key: JBSEAM-5045
> URL: https://issues.jboss.org/browse/JBSEAM-5045
> Project: Seam 2
> Issue Type: Bug
> Affects Versions: 2.3.0.Final
> Reporter: Tiago Peruzzo
> Assignee: Marek Novotny
> Priority: Critical
> Fix For: 2.3.1.CR1
>
> Attachments: ErrorHandlingTest.java, MockExternalContext.java, MockExternalContext.java, MockExternalContext.java, MockExternalContext.java, patch.zip
>
>
> Now that JSF2 now has support for Ajax errors Ajax requests are being processed by the JSF and not being thrown exceptions to the Seam ExceptionFilter capture.
> {code:xml}
> <exception log="true" log-level="fatal">
> <end-conversation before-redirect="true" root="true"/>
> <redirect view-id="/error.xhtml">
> <message severity="fatal">Unexpected error, please try again.</message>
> </redirect>
> </exception>
> {code}
> {code:xml}
> <h:form>
> <h:commandButton action="#{xxxx.xxxxx}" value="Submit"/>
> <h:commandButton action="#{xxxx.xxxxx}" value="Ajax Submit">
> <f:ajax />
> </h:commandButton>
> </h:form>
> {code}
> I even did a patch that still support the redirection to the error pages in AJAX requests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months