Re: JDBC Performance is no where near .NET performance (JDBC 1.2 against mssql2008)
- From: "JustCycling" <justcycling@xxxxxxxxx>
- Date: Wed, 18 Jun 2008 10:39:32 -0700
Thanks David. That did make somewhat of a difference but I am still seeing worse performance on JDBC. Although on larger resultsets like 5million row (a worst case) the performance approaches .NET speeds for a single thread but as I add threads the performance is linear, whereas .NET is better than linear.
On smaller resultsets, around 84,000, the difference is quite worse. .NET can return the rows subsecond (500ms) where JDBC is in the 3-3.5 second range. The JDBC driver is consistently linear as you add threads where .NET remains constant as you add threads for this size resultset.
Any ideas? Could there be a synchronized point in the jdbc code that is slowing it in multithreaded scenarios? I have not tried a multi-process test to compare the timings but I will shortly.
Thanks again.
"David Olix" <davido@xxxxxxxxxxxxxxxxxxxx> wrote in message news:6WQRXxbxIHA.3644@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi,.
If you use a server cursor then adaptive buffering is defeated except with
forward only updatable result sets. But why are you using a server cursor
here? Your code looks like it just needs a standard default forward only
read only result set. That is, it should be sufficient just to create the
statement with:
Statement stmt = c.createStatement();
In that case, you also don't need to set adaptive buffering at the
Statement level, since you already set it in the connection properties.
Hope this helps (let me know if it doesn't),
--David Olix [SQL Server]
- Follow-Ups:
- References:
- Prev by Date: Re: SQLServerException: The server failed to resume the transactio
- Next by Date: RE: SQL Server 2005, jdbc error/bug?
- Previous by thread: RE: JDBC Performance is no where near .NET performance (JDBC 1.2 against mssql2008)
- Next by thread: Re: JDBC Performance is no where near .NET performance (JDBC 1.2 against mssql2008)
- Index(es):