[ http://jira.jboss.com/jira/browse/JBAS-1082?page=history ]
Scott M Stark updated JBAS-1082:
--------------------------------
Description:
SourceForge Submitter: genman .
I've been profiling JMS code. When a JMS message is
added to the server, the persistence manager locates an
appropriate DataSource.
Out of the time spent in
org.jboss.mq.Connection.sendToServer, about 28% of the
time is getting the database connection through
jdbc.WrapperDataSource.getConnection to do its work.
This is after the pool has been initialized, etc. (40%
is actual persistence, though most of it is the message
serialization.)
I suspect a lot of the work is calculating a hashCode
on the javax.security.auth.Subject. SubjectCriKey and
SubjectKey should have this value cached. Ideally,
when one is accessing the local DB, none of this auth
stuff should have to take place. Looking at the source
for Subject.java, the hash code is not kept.
BaseConnectionManager2.allocateConnection %CPU=27.949
%Time=27.963 calls=411
Allocations I've seen:
JBossManagedConnectionPool$SubjectActions
is created 3284 times (for 411 getConnection calls)
java.util.Properties (1642 times)
(Disclaimer: This was done through JBoss profiler,
which may or may not create real numbers. It does
look, though, that CX is pretty slow for some operations.)
was:
SourceForge Submitter: genman .
I've been profiling JMS code. When a JMS message is
added to the server, the persistence manager locates an
appropriate DataSource.
Out of the time spent in
org.jboss.mq.Connection.sendToServer, about 28% of the
time is getting the database connection through
jdbc.WrapperDataSource.getConnection to do its work.
This is after the pool has been initialized, etc. (40%
is actual persistence, though most of it is the message
serialization.)
I suspect a lot of the work is calculating a hashCode
on the javax.security.auth.Subject. SubjectCriKey and
SubjectKey should have this value cached. Ideally,
when one is accessing the local DB, none of this auth
stuff should have to take place. Looking at the source
for Subject.java, the hash code is not kept.
BaseConnectionManager2.allocateConnection %CPU=27.949
%Time=27.963 calls=411
Allocations I've seen:
JBossManagedConnectionPool$SubjectActions
is created 3284 times (for 411 getConnection calls)
java.util.Properties (1642 times)
(Disclaimer: This was done through JBoss profiler,
which may or may not create real numbers. It does
look, though, that CX is pretty slow for some operations.)
Environment:
Priority: Minor (was: Major)
> jdbc.WrapperDataSource.getConnection is slow
> --------------------------------------------
>
> Key: JBAS-1082
> URL: http://jira.jboss.com/jira/browse/JBAS-1082
> Project: JBoss Application Server
> Type: Bug
> Components: JCA service
> Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assignee: Scott M Stark
> Priority: Minor
>
>
> SourceForge Submitter: genman .
> I've been profiling JMS code. When a JMS message is
> added to the server, the persistence manager locates an
> appropriate DataSource.
> Out of the time spent in
> org.jboss.mq.Connection.sendToServer, about 28% of the
> time is getting the database connection through
> jdbc.WrapperDataSource.getConnection to do its work.
> This is after the pool has been initialized, etc. (40%
> is actual persistence, though most of it is the message
> serialization.)
> I suspect a lot of the work is calculating a hashCode
> on the javax.security.auth.Subject. SubjectCriKey and
> SubjectKey should have this value cached. Ideally,
> when one is accessing the local DB, none of this auth
> stuff should have to take place. Looking at the source
> for Subject.java, the hash code is not kept.
> BaseConnectionManager2.allocateConnection %CPU=27.949
> %Time=27.963 calls=411
> Allocations I've seen:
> JBossManagedConnectionPool$SubjectActions
> is created 3284 times (for 411 getConnection calls)
> java.util.Properties (1642 times)
> (Disclaimer: This was done through JBoss profiler,
> which may or may not create real numbers. It does
> look, though, that CX is pretty slow for some operations.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
