ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Maves <nathan.ma...@gmail.com>
Subject Re: SQL-Map / CDATA Performance Issue
Date Sun, 01 Feb 2009 16:06:25 GMT
Please ensure you turn off all logging while running your tests.

On Sun, Feb 1, 2009 at 6:56 AM, Kai Grabfelder <nospam@kaigrabfelder.de>wrote:

> Hi,
>
> looks like the pdf in svn is outdated. Please use the open office source
> instead
> (
> http://svn.apache.org/repos/asf/ibatis/trunk/java/ibatis-2/ibatis-2-docs/en/iBATIS-SqlMaps-2_en.sxw
> ).
>
> I've opened a Jira Issue to address this:
>
> https://issues.apache.org/jira/browse/IBATIS-578
>
> btw: statementCachingEnabled is set to true by default, so if you didn't
> disable it it should be already on
>
> Regards
>
> Kai
>
>
> --- Original Nachricht ---
> Absender: M. Goodell
> Datum: 01.02.2009 01:44
> > I downloaded this documentation from the website. I am assuming since
> it's
> > the only Developers Guide available on the website that it was the latest
> > version. Am I mistaken? Where can I get the latest version of the docs?
> >
> > -----Original Message-----
> > From: Chema [mailto:demablogia@gmail.com]
> > Sent: Saturday, January 31, 2009 2:18 PM
> > To: user-java@ibatis.apache.org
> > Subject: Re: SQL-Map / CDATA Performance Issue
> >
> >
> > 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
> >>
> >>
> > 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