[
https://issues.apache.org/jira/browse/DERBY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike bell updated DERBY-3106:
-----------------------------
Attachment: goo.jsp
This is a very simple very lame jsp test that
- Connects with url including secmech=8
- does a simple query
- iterate resultset
- close connection
and then the same thing without secmech=8
with simple benchmarking (system.gettimeinmillis) between each step
> 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: 10.2.2.0
> Environment: IBM JVM 1.42, SLES 10 or SLES 10 SP1
> Reporter: mike bell
> Attachments: 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.
