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 21:17:46 GMT
Yes, yours is old.

Mine is dated on November 30, 2006  (2.3.x )




2009/1/31 M. Goodell <mgglist@comcast.net>:
> Thanks for your help. I do not see a reference to statementCaching in my
> version of the docs.
>
> See:
> http://svn.apache.org/repos/asf/ibatis/trunk/java/ibatis-2/ibatis-2-docs/en/
> iBATIS-SqlMaps-2_en.pdf
>
> Is there more recent docs available other than the ones I have?
>
> -----Original Message-----
> From: Chema [mailto:demablogia@gmail.com]
> Sent: Saturday, January 31, 2009 1:54 PM
> To: user-java@ibatis.apache.org
> Subject: Re: SQL-Map / CDATA Performance Issue
>
>
> 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
>>
>>
> 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