[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1687:
----------------------------------
Description:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
_This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
https://issues.jboss.org/browse/ELYWEB-26
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
_It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._
https://issues.jboss.org/browse/ELYWEB-27
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
was:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
_This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
https://issues.jboss.org/browse/ELYWEB-26
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
_It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
> Initial WildFly Elytron Performance Enhancments
> -----------------------------------------------
>
> Key: ELY-1687
> URL: https://issues.jboss.org/browse/ELY-1687
> Project: WildFly Elytron
> Issue Type: Task
> Affects Versions: 1.7.0.CR2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: BASIC_Auth_Load.jmx, Flight.tgz
>
>
> Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
> After that we will perform the initial metric test again and close the issue.
> A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
> The first test is to test HTTP Basic authentication backed by WildFly Elytron.
> * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
> Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
> h2. Initial Issues
> h3. WildFlyElytronProvider Locking
> Total block time 8.393s via calls to java.security.Provider.getServices();
> Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
> h3. Memory 2.42G of char[]
> e.g.
> {noformat}
> void java.nio.HeapCharBuffer.<init>(int, int) 13037
> CharBuffer java.nio.CharBuffer.allocate(int) 9148
> CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
> CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
> {noformat}
> Is there any option to re-use these as they can be cleared instead of leaving to GC.
> HeapByteBuffer and HeapCharBuffer are also quite prominent.
> h3. Memory 1.78G of Callback[]
> Using the CallbackHandler API the use of the array is inevitable.
> * Could we extend the API to avoid the array?
> * Could we re-use the array? Could consider null termination.
> {noformat}
> boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
> {noformat}
> h3. Memory 1.41G of HttpAuthenticator$Builder
> {noformat}
> HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
> boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
> {noformat}
> Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
> h3. Memory 1.3G of SecurityContextImpl
> {noformat}
> SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
> SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
> {noformat}
> Also instances of HttpAuthenticator
> {noformat}
> HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
> {noformat}
> And instances of HttpAuthenticator$AuthenticationExchange.
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
> {noformat}
> As with HttpAuthenticator$Builder is there any way to consider re-use?
> h3. Memory 1.21G of java.util.ArrayList
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
> {noformat}
> Can check the use and see if an alternative is possible.
> _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
> _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
> https://issues.jboss.org/browse/ELYWEB-26
> h3. Memory ServerAuthenticationContext States
> Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
> Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
> h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
> {noformat}
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
> {noformat}
> This test did not use forms at all, is this something that can be delayed until we know it is needed?
> _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._
> https://issues.jboss.org/browse/ELYWEB-27
> h3. Memory SecurityIdentity
> As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
> {noformat}
> SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
> ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
> {noformat}
> h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
> These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
> Could a static Base64 conversion clean up a lot of this?
> h1. Done
> h3. Method Profiling - new HttpString
> A lot of time spend creating new HttpString (Package is no3 in the top list)
> {noformat}
> void io.undertow.util.HttpString.<init>(String) 4
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
> {noformat}
> Could we re-use the HttpString for common header types?
> Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Daniele Zonca updated DROOLS-3053:
----------------------------------
Description:
Implement a warning popup when the user changes the type of a column that has been already populated.
To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
*Acceptance criteria*
- If the column contains no value, no confirmation is needed
- If old and new types are the same the user has to decide if the values should be removed or not
- If old and new types are not the same the user has to accept that old values will be removed
- All warning popups should contains also a "Cancel" command to abort the edit
- If the user try to update the column type with the same column type no warning should be raised and data should stay untouched
was:
Implement a warning popup when the user changes the type of a column that has been already populated.
To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
*Acceptance criteria*
- If the column contains no value, no confirmation is needed
- If old and new types are the same the user has to decide if the values should be removed or not
- If old and new types are not the same the user has to accept that old values will be removed
- All warning popups should contains also a "Cancel" command to abort the edit
- If the user edits a column type and try to change with *the current* column type no warning should be raised and data should stay untouched
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
> - If the user try to update the column type with the same column type no warning should be raised and data should stay untouched
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (ELYWEB-27) Cache the FormParserFactory in ElytronHttpExchange
by Darran Lofthouse (Jira)
Darran Lofthouse created ELYWEB-27:
--------------------------------------
Summary: Cache the FormParserFactory in ElytronHttpExchange
Key: ELYWEB-27
URL: https://issues.jboss.org/browse/ELYWEB-27
Project: Elytron Web
Issue Type: Bug
Components: Undertow
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.3.0.CR3
We don't need a unique factory per request as the parser itself is created on-demand and associated with the request.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1687:
----------------------------------
Description:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
_This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
https://issues.jboss.org/browse/ELYWEB-26
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
_It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
was:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
_This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
https://issues.jboss.org/browse/ELYWEB-26
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
> Initial WildFly Elytron Performance Enhancments
> -----------------------------------------------
>
> Key: ELY-1687
> URL: https://issues.jboss.org/browse/ELY-1687
> Project: WildFly Elytron
> Issue Type: Task
> Affects Versions: 1.7.0.CR2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: BASIC_Auth_Load.jmx, Flight.tgz
>
>
> Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
> After that we will perform the initial metric test again and close the issue.
> A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
> The first test is to test HTTP Basic authentication backed by WildFly Elytron.
> * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
> Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
> h2. Initial Issues
> h3. WildFlyElytronProvider Locking
> Total block time 8.393s via calls to java.security.Provider.getServices();
> Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
> h3. Memory 2.42G of char[]
> e.g.
> {noformat}
> void java.nio.HeapCharBuffer.<init>(int, int) 13037
> CharBuffer java.nio.CharBuffer.allocate(int) 9148
> CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
> CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
> {noformat}
> Is there any option to re-use these as they can be cleared instead of leaving to GC.
> HeapByteBuffer and HeapCharBuffer are also quite prominent.
> h3. Memory 1.78G of Callback[]
> Using the CallbackHandler API the use of the array is inevitable.
> * Could we extend the API to avoid the array?
> * Could we re-use the array? Could consider null termination.
> {noformat}
> boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
> {noformat}
> h3. Memory 1.41G of HttpAuthenticator$Builder
> {noformat}
> HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
> boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
> {noformat}
> Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
> h3. Memory 1.3G of SecurityContextImpl
> {noformat}
> SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
> SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
> {noformat}
> Also instances of HttpAuthenticator
> {noformat}
> HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
> {noformat}
> And instances of HttpAuthenticator$AuthenticationExchange.
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
> {noformat}
> As with HttpAuthenticator$Builder is there any way to consider re-use?
> h3. Memory 1.21G of java.util.ArrayList
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
> {noformat}
> Can check the use and see if an alternative is possible.
> _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
> _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
> https://issues.jboss.org/browse/ELYWEB-26
> h3. Memory ServerAuthenticationContext States
> Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
> Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
> h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
> {noformat}
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
> {noformat}
> This test did not use forms at all, is this something that can be delayed until we know it is needed?
> _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._
> h3. Memory SecurityIdentity
> As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
> {noformat}
> SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
> ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
> {noformat}
> h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
> These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
> Could a static Base64 conversion clean up a lot of this?
> h1. Done
> h3. Method Profiling - new HttpString
> A lot of time spend creating new HttpString (Package is no3 in the top list)
> {noformat}
> void io.undertow.util.HttpString.<init>(String) 4
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
> {noformat}
> Could we re-use the HttpString for common header types?
> Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Daniele Zonca updated DROOLS-3053:
----------------------------------
Description:
Implement a warning popup when the user changes the type of a column that has been already populated.
To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
*Acceptance criteria*
- If the column contains no value, no confirmation is needed
- If old and new types are the same the user has to decide if the values should be removed or not
- If old and new types are not the same the user has to accept that old values will be removed
- All warning popups should contains also a "Cancel" command to abort the edit
- If the user edits a column type and try to change with *the current* column type no warning should be raised and data should stay untouched
was:
Implement a warning popup when the user changes the type of a column that has been already populated.
To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
*Acceptance criteria*
- If the column contains no value, no confirmation is needed
- If old and new types are the same the user has to decide if the values should be removed or not
- If old and new types are not the same the user has to accept that old values will be removed
- All warning popups should contains also a "Cancel" command to abort the edit
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
> - If the user edits a column type and try to change with *the current* column type no warning should be raised and data should stay untouched
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-11101) Add CredentialStore documentation
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-11101:
---------------------------------------
Summary: Add CredentialStore documentation
Key: WFLY-11101
URL: https://issues.jboss.org/browse/WFLY-11101
Project: WildFly
Issue Type: Task
Components: Documentation, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 15.0.0.Alpha1
The CredentialStore is a significant component within WildFly Elytron, however it is not really covered in the documentation.
We have a couple of different approaches to creating the store, we then have referencing the store. Finally we have custom implementations.
New features are also being developed so really we need a source of documentation to add descriptions of the new features to.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (WFCORE-3452) If the legacy SecurityRealm references a non-existant alias in the CredentialStore a null password is assumed.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3452?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3452:
-------------------------------------
Priority: Minor (was: Major)
> If the legacy SecurityRealm references a non-existant alias in the CredentialStore a null password is assumed.
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3452
> URL: https://issues.jboss.org/browse/WFCORE-3452
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Affects Versions: 3.0.9.Final, 4.0.0.Alpha4
> Reporter: Darran Lofthouse
> Priority: Minor
>
> We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.
> {noformat}
> 18:41:45,072 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.UnrecoverableKeyException: Password must not be null
> at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:132)
> at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
> at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
> at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
> at java.security.KeyStore.getKey(KeyStore.java:1023)
> at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
> at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
> at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:140)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:89)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Gabriele Cardosi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3053:
-------------------------------------
Description:
Implement a warning popup when the user changes the type of a column that has been already populated.
To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
*Acceptance criteria*
- If the column contains no value, no confirmation is needed
- If old and new types are the same the user has to decide if the values should be removed or not
- If old and new types are not the same the user has to accept that old values will be removed
- All warning popups should contains also a "Cancel" command to abort the edit
was:
Implement a warning popup when the user changes the type of a column that has been already populated.
To be done *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
*Acceptance criteria*
- If the column contains no value, no confirmation is needed
- If old and new types are the same the user has to decide if the values should be removed or not
- If old and new types are not the same the user has to accept that old values will be removed
- All warning popups should contains also a "Cancel" command to abort the edit
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> To be done/merged *after* DROOLS-3051, because in that PR there will be implemented the "empty cell" semantic.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1687:
----------------------------------
Description:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
_This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
https://issues.jboss.org/browse/ELYWEB-26
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
was:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders.
This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
https://issues.jboss.org/browse/ELYWEB-26
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
> Initial WildFly Elytron Performance Enhancments
> -----------------------------------------------
>
> Key: ELY-1687
> URL: https://issues.jboss.org/browse/ELY-1687
> Project: WildFly Elytron
> Issue Type: Task
> Affects Versions: 1.7.0.CR2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.7.0.CR3
>
> Attachments: BASIC_Auth_Load.jmx, Flight.tgz
>
>
> Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
> After that we will perform the initial metric test again and close the issue.
> A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
> The first test is to test HTTP Basic authentication backed by WildFly Elytron.
> * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
> Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
> h2. Initial Issues
> h3. WildFlyElytronProvider Locking
> Total block time 8.393s via calls to java.security.Provider.getServices();
> Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
> h3. Memory 2.42G of char[]
> e.g.
> {noformat}
> void java.nio.HeapCharBuffer.<init>(int, int) 13037
> CharBuffer java.nio.CharBuffer.allocate(int) 9148
> CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
> CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
> {noformat}
> Is there any option to re-use these as they can be cleared instead of leaving to GC.
> HeapByteBuffer and HeapCharBuffer are also quite prominent.
> h3. Memory 1.78G of Callback[]
> Using the CallbackHandler API the use of the array is inevitable.
> * Could we extend the API to avoid the array?
> * Could we re-use the array? Could consider null termination.
> {noformat}
> boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
> {noformat}
> h3. Memory 1.41G of HttpAuthenticator$Builder
> {noformat}
> HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
> boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
> {noformat}
> Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
> h3. Memory 1.3G of SecurityContextImpl
> {noformat}
> SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
> SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
> {noformat}
> Also instances of HttpAuthenticator
> {noformat}
> HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
> {noformat}
> And instances of HttpAuthenticator$AuthenticationExchange.
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
> {noformat}
> As with HttpAuthenticator$Builder is there any way to consider re-use?
> h3. Memory 1.21G of java.util.ArrayList
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
> {noformat}
> Can check the use and see if an alternative is possible.
> _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
> _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
> https://issues.jboss.org/browse/ELYWEB-26
> h3. Memory ServerAuthenticationContext States
> Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
> Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
> h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
> {noformat}
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
> {noformat}
> This test did not use forms at all, is this something that can be delayed until we know it is needed?
> h3. Memory SecurityIdentity
> As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
> {noformat}
> SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
> ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
> {noformat}
> h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
> These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
> Could a static Base64 conversion clean up a lot of this?
> h1. Done
> h3. Method Profiling - new HttpString
> A lot of time spend creating new HttpString (Package is no3 in the top list)
> {noformat}
> void io.undertow.util.HttpString.<init>(String) 4
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
> {noformat}
> Could we re-use the HttpString for common header types?
> Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
- 1
- 0
[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1687:
----------------------------------
Description:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders.
This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
https://issues.jboss.org/browse/ELYWEB-26
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
was:
Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
After that we will perform the initial metric test again and close the issue.
A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
The first test is to test HTTP Basic authentication backed by WildFly Elytron.
* Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
h2. Initial Issues
h3. WildFlyElytronProvider Locking
Total block time 8.393s via calls to java.security.Provider.getServices();
Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
h3. Memory 2.42G of char[]
e.g.
{noformat}
void java.nio.HeapCharBuffer.<init>(int, int) 13037
CharBuffer java.nio.CharBuffer.allocate(int) 9148
CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
{noformat}
Is there any option to re-use these as they can be cleared instead of leaving to GC.
HeapByteBuffer and HeapCharBuffer are also quite prominent.
h3. Memory 1.78G of Callback[]
Using the CallbackHandler API the use of the array is inevitable.
* Could we extend the API to avoid the array?
* Could we re-use the array? Could consider null termination.
{noformat}
boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
{noformat}
h3. Memory 1.41G of HttpAuthenticator$Builder
{noformat}
HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
{noformat}
Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
h3. Memory 1.3G of SecurityContextImpl
{noformat}
SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
{noformat}
Also instances of HttpAuthenticator
{noformat}
HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
{noformat}
And instances of HttpAuthenticator$AuthenticationExchange.
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
{noformat}
As with HttpAuthenticator$Builder is there any way to consider re-use?
h3. Memory 1.21G of java.util.ArrayList
{noformat}
boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
{noformat}
Can check the use and see if an alternative is possible.
_If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders.
This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
h3. Memory ServerAuthenticationContext States
Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
{noformat}
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
{noformat}
This test did not use forms at all, is this something that can be delayed until we know it is needed?
h3. Memory SecurityIdentity
As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
{noformat}
SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
{noformat}
h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
Could a static Base64 conversion clean up a lot of this?
h1. Done
h3. Method Profiling - new HttpString
A lot of time spend creating new HttpString (Package is no3 in the top list)
{noformat}
void io.undertow.util.HttpString.<init>(String) 4
void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
{noformat}
Could we re-use the HttpString for common header types?
Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
> Initial WildFly Elytron Performance Enhancments
> -----------------------------------------------
>
> Key: ELY-1687
> URL: https://issues.jboss.org/browse/ELY-1687
> Project: WildFly Elytron
> Issue Type: Task
> Affects Versions: 1.7.0.CR2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.7.0.CR3
>
> Attachments: BASIC_Auth_Load.jmx, Flight.tgz
>
>
> Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
> After that we will perform the initial metric test again and close the issue.
> A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
> The first test is to test HTTP Basic authentication backed by WildFly Elytron.
> * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
> Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
> h2. Initial Issues
> h3. WildFlyElytronProvider Locking
> Total block time 8.393s via calls to java.security.Provider.getServices();
> Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
> h3. Memory 2.42G of char[]
> e.g.
> {noformat}
> void java.nio.HeapCharBuffer.<init>(int, int) 13037
> CharBuffer java.nio.CharBuffer.allocate(int) 9148
> CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
> CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
> {noformat}
> Is there any option to re-use these as they can be cleared instead of leaving to GC.
> HeapByteBuffer and HeapCharBuffer are also quite prominent.
> h3. Memory 1.78G of Callback[]
> Using the CallbackHandler API the use of the array is inevitable.
> * Could we extend the API to avoid the array?
> * Could we re-use the array? Could consider null termination.
> {noformat}
> boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
> {noformat}
> h3. Memory 1.41G of HttpAuthenticator$Builder
> {noformat}
> HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
> boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
> {noformat}
> Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
> h3. Memory 1.3G of SecurityContextImpl
> {noformat}
> SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
> SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
> {noformat}
> Also instances of HttpAuthenticator
> {noformat}
> HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
> {noformat}
> And instances of HttpAuthenticator$AuthenticationExchange.
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
> {noformat}
> As with HttpAuthenticator$Builder is there any way to consider re-use?
> h3. Memory 1.21G of java.util.ArrayList
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
> {noformat}
> Can check the use and see if an alternative is possible.
> _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders.
> This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
> https://issues.jboss.org/browse/ELYWEB-26
> h3. Memory ServerAuthenticationContext States
> Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
> Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
> h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
> {noformat}
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
> {noformat}
> This test did not use forms at all, is this something that can be delayed until we know it is needed?
> h3. Memory SecurityIdentity
> As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
> {noformat}
> SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
> ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
> {noformat}
> h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
> These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
> Could a static Base64 conversion clean up a lot of this?
> h1. Done
> h3. Method Profiling - new HttpString
> A lot of time spend creating new HttpString (Package is no3 in the top list)
> {noformat}
> void io.undertow.util.HttpString.<init>(String) 4
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
> {noformat}
> Could we re-use the HttpString for common header types?
> Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
- 1
- 0