You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by "Joe Carter (JIRA)" <ji...@apache.org> on 2006/06/22 10:10:29 UTC

[jira] Created: (TORQUE-36) Select performance problem with Sybase

Select performance problem with Sybase
--------------------------------------

         Key: TORQUE-36
         URL: http://issues.apache.org/jira/browse/TORQUE-36
     Project: Torque
        Type: Bug

  Components: Runtime  
    Versions: 3.2    
 Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2
    Reporter: Joe Carter


Selects via Torque perform 2-3 times slower than when doing the identical statement via JDBC.

I took the SQL produced by Torque using p6spy to capture it.
I manually implemented the same SQL as a raw query and a prepared statement
obtaining a SQL connection from Torque.getConnection() to eliminate any differences in the pooling etc.
I then ran performance tests against the 3 types.
The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw and then prepared statements.
The performance hit was definately against the database as we're seeing similar performance improvements
on production systems with the database CPU usage dropping dramatically with some gains on the calling tomcat server.

The suspicion is that metadata is being retrieved on every select but p6spy unfortunately does not 
support the reporting of this so this cannot be confirmed.
Note that the tests were performed without p6spy in the loop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


[jira] Resolved: (TORQUE-36) Select performance problem with Sybase

Posted by "Thomas Vandahl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TORQUE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Vandahl resolved TORQUE-36.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 3.3.1

Well, not exactly fixed, actually. More worked around. You can preload the table metadata beforehand to cache it. The select will then use the cached information to improve performance.

> Select performance problem with Sybase
> --------------------------------------
>
>                 Key: TORQUE-36
>                 URL: https://issues.apache.org/jira/browse/TORQUE-36
>             Project: Torque
>          Issue Type: Bug
>          Components: Runtime, Village
>    Affects Versions: 3.2
>         Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2
>            Reporter: Joe Carter
>            Assignee: Thomas Vandahl
>             Fix For: 3.3.1
>
>
> Selects via Torque perform 2-3 times slower than when doing the identical statement via JDBC.
> I took the SQL produced by Torque using p6spy to capture it.
> I manually implemented the same SQL as a raw query and a prepared statement
> obtaining a SQL connection from Torque.getConnection() to eliminate any differences in the pooling etc.
> I then ran performance tests against the 3 types.
> The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw and then prepared statements.
> The performance hit was definately against the database as we're seeing similar performance improvements
> on production systems with the database CPU usage dropping dramatically with some gains on the calling tomcat server.
> The suspicion is that metadata is being retrieved on every select but p6spy unfortunately does not 
> support the reporting of this so this cannot be confirmed.
> Note that the tests were performed without p6spy in the loop.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


[jira] Assigned: (TORQUE-36) Select performance problem with Sybase

Posted by "Thomas Vandahl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TORQUE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Vandahl reassigned TORQUE-36:
------------------------------------

    Assignee: Thomas Vandahl

> Select performance problem with Sybase
> --------------------------------------
>
>                 Key: TORQUE-36
>                 URL: https://issues.apache.org/jira/browse/TORQUE-36
>             Project: Torque
>          Issue Type: Bug
>          Components: Runtime, Village
>    Affects Versions: 3.2
>         Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2
>            Reporter: Joe Carter
>            Assignee: Thomas Vandahl
>
> Selects via Torque perform 2-3 times slower than when doing the identical statement via JDBC.
> I took the SQL produced by Torque using p6spy to capture it.
> I manually implemented the same SQL as a raw query and a prepared statement
> obtaining a SQL connection from Torque.getConnection() to eliminate any differences in the pooling etc.
> I then ran performance tests against the 3 types.
> The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw and then prepared statements.
> The performance hit was definately against the database as we're seeing similar performance improvements
> on production systems with the database CPU usage dropping dramatically with some gains on the calling tomcat server.
> The suspicion is that metadata is being retrieved on every select but p6spy unfortunately does not 
> support the reporting of this so this cannot be confirmed.
> Note that the tests were performed without p6spy in the loop.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


[jira] Updated: (TORQUE-36) Select performance problem with Sybase

Posted by "Thomas Fischer (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TORQUE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Fischer updated TORQUE-36:
---------------------------------

    Component/s: Village

I have debugged the code. You are right, the metadata is used in the select.

I agree that this is bad. However, this would be difficult to change at the moment because the code is in the village library, which I do not understand enough.

The long-term plan is to replace village anyway, which will resolve this issue.

I am adding the component "village" to indicate that this is a problem of the village library.

> Select performance problem with Sybase
> --------------------------------------
>
>                 Key: TORQUE-36
>                 URL: https://issues.apache.org/jira/browse/TORQUE-36
>             Project: Torque
>          Issue Type: Bug
>          Components: Runtime, Village
>    Affects Versions: 3.2
>         Environment: Java 1.4.2 on solaris 10 against Sybase 12.5.2
>            Reporter: Joe Carter
>
> Selects via Torque perform 2-3 times slower than when doing the identical statement via JDBC.
> I took the SQL produced by Torque using p6spy to capture it.
> I manually implemented the same SQL as a raw query and a prepared statement
> obtaining a SQL connection from Torque.getConnection() to eliminate any differences in the pooling etc.
> I then ran performance tests against the 3 types.
> The ratio in performance (big is slower) was 10-4-3 for standard Torque, raw and then prepared statements.
> The performance hit was definately against the database as we're seeing similar performance improvements
> on production systems with the database CPU usage dropping dramatically with some gains on the calling tomcat server.
> The suspicion is that metadata is being retrieved on every select but p6spy unfortunately does not 
> support the reporting of this so this cannot be confirmed.
> Note that the tests were performed without p6spy in the loop.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org