ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chema <demablo...@gmail.com>
Subject Re: SQL-Map / CDATA Performance Issue
Date Sat, 31 Jan 2009 20:53:30 GMT
About docs:

statementCachingEnabled (iBATIS versions 2.3.0 and later)
With this setting enabled, iBATIS will maintain a local cache of
prepared statements. This can lead to significant performance
improvements.
Example: statementCachingEnabled="true"
Default: true (enabled)

I asked you this question because:

- I can understand that formatted XML could be parsed slower, but in
millis terms
- I guess that iBatis builds your query as a prepared statement and,
if prepared statements cache is working fine, your query should be
cached, so
- I think that althought you execute it 10.000 times, XML is parsed
just one time. But this conclusion is only based on how I think
prepared statements caching works. But I can be wrong :-)



2009/1/31 M. Goodell <mgglist@comcast.net>:
>
> 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