You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Ch...@sybase.com on 2008/06/18 22:23:09 UTC
Performance issue when using Glassfish
I'm running iBatis 2.3.0.668 within Spring 2.5 inside of Glassfish.
(Actually, I was running inside of Tomcat without any issues) We are
migrating to Glassfish and the only change I've made is to utilize the
resources from Glassfish, via JNDI. This includes the TX Manager as well
as all DataSources. Should be not problem and no issues but I seem to be
hitting a performance issue down deep in iBatis. I see the initial hit on
the Dao, and I can see the Prepared Statement being generated. No issues
there. I see the values that are bound to the statement and I can see it
getting executed. (I intercept all the jTDS calls to the Sybase ASE so I
can line up invocation timestamps) But it seems from the time that iBatis
is executing the SQL to the time that it is reading the results that
something is happening that is consuming a great deal of time.
TDS interception shows:
[2008-06-18 13:06:21.145] Thread-11: Client->Server: read 400 from client.
Writing...
[2008-06-18 13:06:40.319] Thread-11: Client->Server: read 187 from client.
Writing...
As you can see over 18 seconds went somewhere.
>From the log4j logging:
2008-06-18 13:06:21,082 [httpSSLWorkerThread-8080-1 : ]
[DEBUG,PreparedStatement] {pstm-100010} Types: [java.lang.Integer,
java.lang.Integer]
2008-06-18 13:06:40,303 [httpSSLWorkerThread-8080-1 : ] [DEBUG,ResultSet ]
{rset-100011} ResultSet
Same as above, 18+ seconds went somewhere.
I can't seem to get the logging in ibatis to work. I've added it to my
log4j configuration but for some reason nothing is printed out from
iBatis. (Spring dumps well though so I can get some idea about what is
happening)
I know that this is an extremely odd issue but I was hoping that someone
may have seen something like this prior.
Thanks for the help...
Chris
Re: Performance issue when using Glassfish
Posted by Ch...@sybase.com.
Hey Clinton,
I'm not using the logging as a benchmark but rather just trying to figure
out what is going wrong. I spent some more time with this issue and I'm
using a utility that captures the TDS communication between the
application and my ASE server. One thing that I've noticed is that while
the SQL statement is being logged out to the log file it appears that the
SQL is not being sent to the server in a timely fashion. Actually, at this
point I am running the application in Tomcat and I see the statement to be
executed but no data sent via TDS. I'm wondering if there is a chance that
I have a library out of sync that is not compatible with iBatis. Is there
anything that you can think where I might look to see if this is the case?
Thanks for the help..
Chris Mathrusse
christopher.mathrusse@sybase.com
Sybase, Inc
One Sybase Drive
Dublin, CA 94568
(925) 236-5553
"Clinton Begin" <cl...@gmail.com>
06/18/2008 01:33 PM
Please respond to
user-java@ibatis.apache.org
To
user-java@ibatis.apache.org
cc
Subject
Re: Performance issue when using Glassfish
Couple of things here....
1) I belive the ResultSet line is printed after all of the results are
finished being read. Even if that's not the case line-for-line with
iBATIS, it's possible the driver is actually prefetching a group of
records upon the first access of he result set.
2) Using iBATIS logging for performance benchmarking is a bad idea. iBATIS
logging is very resource intensive and is only intended for debugging. It
should be shut off in production and during performance testing.
I recommend a proper profiling tool that will let you introspect deeper
into your application. I belive there are free profilers for both Eclipse
and NetBeans.
Clinton
On Wed, Jun 18, 2008 at 2:23 PM, <Ch...@sybase.com> wrote:
I'm running iBatis 2.3.0.668 within Spring 2.5 inside of Glassfish.
(Actually, I was running inside of Tomcat without any issues) We are
migrating to Glassfish and the only change I've made is to utilize the
resources from Glassfish, via JNDI. This includes the TX Manager as well
as all DataSources. Should be not problem and no issues but I seem to be
hitting a performance issue down deep in iBatis. I see the initial hit on
the Dao, and I can see the Prepared Statement being generated. No issues
there. I see the values that are bound to the statement and I can see it
getting executed. (I intercept all the jTDS calls to the Sybase ASE so I
can line up invocation timestamps) But it seems from the time that iBatis
is executing the SQL to the time that it is reading the results that
something is happening that is consuming a great deal of time.
TDS interception shows:
[2008-06-18 13:06:21.145] Thread-11: Client->Server: read 400 from client.
Writing...
[2008-06-18 13:06:40.319] Thread-11: Client->Server: read 187 from client.
Writing...
As you can see over 18 seconds went somewhere.
>From the log4j logging:
2008-06-18 13:06:21,082 [httpSSLWorkerThread-8080-1 : ]
[DEBUG,PreparedStatement] {pstm-100010} Types: [java.lang.Integer,
java.lang.Integer]
2008-06-18 13:06:40,303 [httpSSLWorkerThread-8080-1 : ] [DEBUG,ResultSet ]
{rset-100011} ResultSet
Same as above, 18+ seconds went somewhere.
I can't seem to get the logging in ibatis to work. I've added it to my
log4j configuration but for some reason nothing is printed out from
iBatis. (Spring dumps well though so I can get some idea about what is
happening)
I know that this is an extremely odd issue but I was hoping that someone
may have seen something like this prior.
Thanks for the help...
Chris
Re: Performance issue when using Glassfish
Posted by Clinton Begin <cl...@gmail.com>.
Couple of things here....
1) I belive the ResultSet line is printed after all of the results are
finished being read. Even if that's not the case line-for-line with iBATIS,
it's possible the driver is actually prefetching a group of records upon the
first access of he result set.
2) Using iBATIS logging for performance benchmarking is a bad idea. iBATIS
logging is very resource intensive and is only intended for debugging. It
should be shut off in production and during performance testing.
I recommend a proper profiling tool that will let you introspect deeper into
your application. I belive there are free profilers for both Eclipse and
NetBeans.
Clinton
On Wed, Jun 18, 2008 at 2:23 PM, <Ch...@sybase.com> wrote:
>
> I'm running iBatis 2.3.0.668 within Spring 2.5 inside of Glassfish.
> (Actually, I was running inside of Tomcat without any issues) We are
> migrating to Glassfish and the only change I've made is to utilize the
> resources from Glassfish, via JNDI. This includes the TX Manager as well as
> all DataSources. Should be not problem and no issues but I seem to be
> hitting a performance issue down deep in iBatis. I see the initial hit on
> the Dao, and I can see the Prepared Statement being generated. No issues
> there. I see the values that are bound to the statement and I can see it
> getting executed. (I intercept all the jTDS calls to the Sybase ASE so I can
> line up invocation timestamps) But it seems from the time that iBatis is
> executing the SQL to the time that it is reading the results that something
> is happening that is consuming a great deal of time.
>
> *TDS interception shows:*
> [2008-06-18 13:06:21.145] Thread-11: Client->Server: read 400 from client.
> Writing...
> [2008-06-18 13:06:40.319] Thread-11: Client->Server: read 187 from client.
> Writing...
>
> As you can see over 18 seconds went somewhere.
>
> *From the log4j logging:*
> 2008-06-18 13:06:21,082 [httpSSLWorkerThread-8080-1 : ]
> [DEBUG,PreparedStatement] {pstm-100010} Types: [java.lang.Integer,
> java.lang.Integer]
> 2008-06-18 13:06:40,303 [httpSSLWorkerThread-8080-1 : ] [DEBUG,ResultSet ]
> {rset-100011} ResultSet
>
> Same as above, 18+ seconds went somewhere.
> I can't seem to get the logging in ibatis to work. I've added it to my
> log4j configuration but for some reason nothing is printed out from iBatis.
> (Spring dumps well though so I can get some idea about what is happening)
>
> I know that this is an extremely odd issue but I was hoping that someone
> may have seen something like this prior.
> Thanks for the help...
>
> Chris