You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Brian Parkinson <pa...@avaning.com> on 2008/06/23 21:16:34 UTC

Performance question

Hello:

I'm using iBATIS with MySQL and Java, and all is well. Started to do
some performance testing, and discovered that things are pretty slow,
and so wondering if someone might have some insight. I apologize, as
this is not really iBATIS per se, but I can't get great help on the
MySQL forums...

I have a simple table, with a BLOB entry, and I'm seeing long (~300ms)
times for updates. The table is InnoDB. The datasource:

	<bean id="mapConfig"
class="org.springframework.core.io.ClassPathResource">
		<constructor-arg>
	
<value>com/ecobee/foundation/dao/ibatis/SqlMapConfig.xml</value>
		</constructor-arg>
	</bean>
	 
	<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
		<property name="driverClassName"
value="com.mysql.jdbc.Driver" />
		<property name="url" value="jdbc:mysql:///ecobee" />
		<property name="username" value="XXX" />
		<property name="password" value="XXX" />	
		<property name="initialSize" value="10" />
		<property name="maxActive" value="100" />	
		<property name="maxIdle" value="10" />
	</bean>

	<bean id="sqlMapClient"
class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
		<property name="dataSource" ref="dataSource" />
		<property name="configLocation" ref="mapConfig" />
	</bean>

I was using the Spring transaction manager stuff, but pulled it out for
the time being in the hopes of improving performance.

So, the DAO simple maps a number of data members to columns, and then
compresses and BLOBs the final column. There is no contention for row,
and my understanding is that InnoDB will do row level locking.

Anyone out there have any ideas that I might try to get performance
better? It seems to take a very long time to update the rows. The
overall size of the BLOB is about 2K or so (not that big).

Any hints or suggestions appreciated - I'm not a DB guy.

Regards,

Brian Parkinson
Avaning Inc.