ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. Goodell" <mggl...@comcast.net>
Subject RE: SQL-Map / CDATA Performance Issue
Date Sat, 31 Jan 2009 20:39:29 GMT

Version: ibatis-2.3.4.726

Not using statement caching as far as I know.

Could you please provide a brief example of turning on statement caching? I
have read without it there is a performance hit.

Thanks!

M. Goodell

-----Original Message-----
From: Chema [mailto:demablogia@gmail.com]
Sent: Saturday, January 31, 2009 1:12 PM
To: user-java@ibatis.apache.org
Subject: Re: SQL-Map / CDATA Performance Issue


What version are you using ?
Do you have statement caching enabled ?


2009/1/31 M. Goodell <mgglist@comcast.net>:
> Looking further into this it seems to have little to do with the CDATA tag
> but the formatting of the SQL statement. The more formatting applied to
the
> SQL statement, the slower the performance.
>
> Format A is much slower than Format A
>
> (Format A)
> INSERT INTO
>        people (
>        last_name,
>        first_name,
>        age
> ) VALUES (
>        #lastName#,
>        #firstName#,
>        #age#);
>
> (Format B)
> INSERT INTO people (last_name,first_name,age) VALUES
> (#lastName#,#firstName#,#age#);
>
> -----Original Message-----
> From: M. Goodell [mailto:mgglist@comcast.net]
> Sent: Saturday, January 31, 2009 12:52 PM
> To: Chema; user-java@ibatis.apache.org; mgglist@comcast.net
> Subject: RE: SQL-Map / CDATA Performance Issue
>
>
> Here is some more information:
>
> 1.) Using (Format A) and inserting 10,000 records this takes roughly 12-15
> seconds.
>
> (Format A)
> <![CDATA[
> INSERT INTO people (
>        last_name,
>        first_name,
>        age
> ) VALUES (
>        #lastName#,
>        #firstName#,
>        #age#
> );
> ]]>
>
> 2.) Using (Format B) and inserting 10,000 records this takes roughly 7-8
> seconds.
>
> (Format B)
> INSERT INTO people (
>        last_name,
>        first_name,
>        age
> ) VALUES (
>        #lastName#,
>        #firstName#,
>        #age#
> );
>
> 3.) Using (Format C) and inserting 10,000 records this takes roughly 3-4
> seconds.
>
> (Format C)
> INSERT INTO people (last_name, first_name, age) VALUES
> (#lastName#,#firstName#,#age#);
>
> Again, thanks for any help.
>
> -----Original Message-----
> From: Chema [mailto:demablogia@gmail.com]
> Sent: Saturday, January 31, 2009 12:24 PM
> To: user-java@ibatis.apache.org; mgglist@comcast.net
> Subject: Re: SQL-Map / CDATA Performance Issue
>
>
> And without CDATA tag ? Same performance ?
> Indeed, I don't know why you use it for that query
>
>
> 2009/1/31 MGG List Subscription <mgglist@comcast.net>:
>> When I format the SQL within my insert element like Example 1.0 and time
>> several application calls the performance is degraded *substantially*.
>> However, if I format the SQL as shown in Example 1.1 the performance
>> improves dramatically.
>>
>> It seems the larger the SQL statement and the more "pretty" formatting
> that
>> is applied to the embedded SQL statement causes the performance to
> degrade.
>> I have read the manual sections on applying the CDATA XML tag to the SQL
> but
>> it seems to not make a difference unlsess the SQL is compacted on to one
>> line.
>>
>> Thank you in advance for any help!
>>
>> Example 1.0:
>>
>> <insert id="insertPerson" parameterClass="springibatis.Person">
>>        <![CDATA[
>>        INSERT INTO people (
>>                last_name,
>>                  first_name,
>>                  age
>>                ) VALUES (
>>                  #lastName#,
>>                  #firstName#,
>>                  #age#
>>                );
>>        ]]>
>>    </insert>
>>
>>
>> Example 1.1:
>>
>> <insert id="insertPerson" parameterClass="springibatis.Person">
>>        <![CDATA[
>>        INSERT INTO people (last_name, first_name, age) VALUES
(#lastName#,
>> #firstName#, #age#);
>>        ]]>
>> </insert>
>> No virus found in this outgoing message.
>> Checked by AVG - www.avg.com
>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date:
01/30/09
>> 17:31:00
>>
>>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09
> 17:31:00
>
> No virus found in this outgoing message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09
> 17:31:00
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09
> 17:31:00
>
> No virus found in this outgoing message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09
> 17:31:00
>
>
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09
17:31:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09
17:31:00


Mime
View raw message