db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3106) securityMechansim=8 causes slowdown on some JVMs?
Date Mon, 06 Jul 2009 16:49:14 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kathey Marsden updated DERBY-3106:

    Attachment: goo.java

I am attaching a java reproduction as it may be more convenient than jsp for anyone working
on this issue.  I also added an initial database creation and boot, so as not to skew the

With IBM 1.6 SR3 I saw the following measurements:
Time for first database boot=2219
Time with securityMechanism 8=4890
Time with no securityMechnism=0

With Sun 1.6 I saw:
Time for first database boot=2265
Time with securityMechanism 8=625
Time with no securityMechnism=16

It seems especially with the IBM JVM this is still an issue.  It would be interesting to throw
out the first connection and loop and take an average of a dozen connections or so.

> securityMechansim=8 causes slowdown on some JVMs?
> -------------------------------------------------
>                 Key: DERBY-3106
>                 URL: https://issues.apache.org/jira/browse/DERBY-3106
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>         Environment: IBM JVM 1.42, SLES 10 or SLES 10 SP1
>            Reporter: mike bell
>         Attachments: goo.java, goo.jsp
> 1. We have a Web App that uses Derby 10.2, doing client/server. It is a Java 1.4 app
> 2.  We run it extensively on Windows (JDK 1.4,1.5/Tomcat 4.1/5.5), SLES 9, SLES 10, OES,
and NetWare
> 3. Recently I added securityMechanism=8 to the JDBC URL to at least encrypt the password
(it's all local right now, but it was a nicety). Extensive testing on Windows proved flawless.
> 4. Immediately after releasing to Beta testers, we heard the "UI" was slow. I traced
this specifically to pages that accessed Derby Connections (or built them into a pool - there
are depressing reasons why we don't do this all the time currently).
> 5. The issue only occurs on SLES 10/10 SP1. It occurred for about 80% of users, and was
oddly intermittent. The slowdown did NOT occur on initial login, but after they added some
entries (adding some fields to some tables effectively). From then on, the slowdown was rampant
and survived restarts. Even the login (which queries some DBs) was very very slow
> 6. A test JSP page was created, which basically will be attached, but did nothing more
than create a Connection, do a simple query, iterate the result set. Then do the same thing
without the security Mechanism. Then spit out benchmark numbers.
> On my box (Windows), the numbers were typically a total of less than 10 ms for the queries.
On machines exhibiting the issue, they were 80 SECONDS!
> As soon as the securityMechanism=8 was removed, the issue disappeared.
> Now, I'm not really sure I should blame Derby. My offhand gut guess is there is something
wrong with the IBM JVM 1.42, doing the encrypted password and Derby  took a long time to timeout
and then backed down to cleartext..
> But I don't have a lot of time to test this one out. So I'm mostly posting FYI.
> (Additional: Connection logging was performed and not that interesting. Telnet to derby
server was quick - it appears it is all in the client negotiating the connection that the
slow down occurs).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message