Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 36175 invoked from network); 2 Sep 2005 09:33:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Sep 2005 09:33:10 -0000 Received: (qmail 66262 invoked by uid 500); 2 Sep 2005 09:33:08 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 66248 invoked by uid 500); 2 Sep 2005 09:33:08 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 66232 invoked by uid 99); 2 Sep 2005 09:33:08 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2005 02:33:08 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,FROM_ENDS_IN_NUMS,HTML_60_70,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [66.163.179.164] (HELO web35710.mail.mud.yahoo.com) (66.163.179.164) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 02 Sep 2005 02:33:22 -0700 Received: (qmail 51443 invoked by uid 60001); 2 Sep 2005 09:33:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3vXQOPdal8eSYH4TcwaR3NX2cYwOlLFBAMgM0xw59mpm8j8UY9bPbqfgTUPZxRcoRlU4q6nyz5ylm0w2imOLtjK8qRzNdqWJxNvZxGjMOJHbRv36HMimQZVWpQn7Zzv2sul4Ola1tKtnNVTuotLIq/3sSNIHsk4JZzfbyTPfgEU= ; Message-ID: <20050902093305.51441.qmail@web35710.mail.mud.yahoo.com> Received: from [210.251.115.162] by web35710.mail.mud.yahoo.com via HTTP; Fri, 02 Sep 2005 02:33:05 PDT Date: Fri, 2 Sep 2005 02:33:05 -0700 (PDT) From: jaggee j Subject: RE: increase performance To: user-java@ibatis.apache.org In-Reply-To: <20050902071141.PCGY239617.HCM-MS-185@nbjeff> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1402313077-1125653585=:47368" Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --0-1402313077-1125653585=:47368 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jean-Francois, Thanks for the reply and agreed your comments. We have also identified the SQL query optimization makes the big difference in the performance,so we modifed the quries as much as possible. Moreover, 1. we have not implemented the cache model till now,so we are planning to include this also, the statements .so if we use the cache model, how to set flushOnExecute or how do flush the cache? 3.Are lazyloading and byte code enable improve the performance? i am finding difficult to decide these things , could any one help me ? Thanks. Jean-Francois Poilpret wrote: v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}st1\:*{behavior:url(#default#ieooui) } Hi, >From what I can see, this is not in iBATIS that you should look for better performance but in your SQL select statements. It is always a bad idea, in a where clause, to use a function on an indexed column like in: SUBSTRING(NewLog_T.date,1,4) = #syukeiYear_# AND This way, the index will never be used: be prepared for a full table scan. If your table has millions of rows, then you can go and take a coffee (maybe several) until the request is terminated. So my advice is really to optimize your SQL (this might also require changing table structure and adding indexes). Then when you could check its performance directly (I mean without iBATIS) you can start (only if necessary, and I don�ft believe it would be) to think about iBATIS optimizations. Cheers Jean-Francois __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1402313077-1125653585=:47368 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Jean-Francois,
 
Thanks for the reply and agreed your comments.
We have also identified the SQL query optimization makes the big difference in the performance,so we modifed the quries as much as possible.
 
Moreover,
1. we have not implemented the cache model till now,so we are planning to include this also, the <select> statements have multiple loops with diffrent parameters.
what Type of Cache Model is best suited for this case.
 
2.this application only contains <select> statements .so if we use the cache model, how to set flushOnExecute or how do flush the cache?
 
3.Are lazyloading and  byte code enable improve the performance? 
 
i am finding difficult to decide these things , could any one help me ?
 
Thanks.

Jean-Francois Poilpret <jfpoilpret@hcm.vnn.vn> wrote:

Hi,

 

From what I can see, this is not in iBATIS that you should look for better performance but in your SQL select statements.

It is always a bad idea, in a where clause, to use a function on an indexed column like in:

    SUBSTRING(NewLog_T.date,1,4) = #syukeiYear_# AND

This way, the index will never be used: be prepared for a full table scan. If your table has millions of rows, then you can go and take a coffee (maybe several) until the request is terminated.

 

So my advice is really to optimize your SQL (this might also require changing table structure and adding indexes). Then when you could check its performance directly (I mean without iBATIS) you can start (only if necessary, and I don�ft believe it would be) to think about iBATIS optimizations.

 

Cheers

 

            Jean-Francois

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1402313077-1125653585=:47368--