Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Message-ID: <5249925.163491288544425773.JavaMail.jira@thor>
Date: Sun, 31 Oct 2010 13:00:25 -0400 (EDT)
From: "Thomas Vandahl (JIRA)" <jira@apache.org>
To: torque-dev@db.apache.org
Subject: [jira] Resolved: (TORQUE-36) Select performance problem with Sybase
In-Reply-To: <7436832.1150963829786.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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