Re: MS SQL Server 2005 JDBC Driver Performance Issue

Bill,
Welcome to the JDBC newsgroup, glad to have you.

As far as I am aware we don't loose the benefits of RPC, I have verified by
looking at the profiler trace. Can you give me a rundown of the scenario you
are looking at and why you believe we are not performant here?

As far as the original discussion, I have worked with Richard Yeo et.al to
try to understand their scenario, preliminary testing based on source code
they provided resulted in performance being on par with other drivers for a
standalone case. Unfortunately they are still seeing slowdowns when using
their entire frameworks, hopefully we will be able to hear from them if they
figure out what the possible causes for this would be.

On to the v1.1 driver! as you may know we are currently in ship mode trying
to get v1.1 out the door, there is going to be a great performance tweak
included in this driver release, specially if you are working with large
lobs. You will now be able to tweak the PacketSize (TDS buffer that you use
to communicate with the server) internal testing suggest that setting the
default packetsize to 8k instead of the 4k default gives significant
performance improvements for some scenarios. We have additionally tweaked
our driver to trade off memory for performance when using packetsize (it
will use more memory but be much faster) in these scenarios.

I am really looking forward to people trying out PacketSize when they run
into scenarios where they think that our driver is not performant, based on
customer feedback we will be able to make further performance improvements
in future driver versions.

--
Angel Saenz-Badillos [MS] Data Programmability
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging: http://blogs.msdn.com/angelsb/




"fundba" <fundba@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D84EFE7A-4BE3-4116-B782-ADE64F618E28@xxxxxxxxxxxxxxxx
Starting with the disclaimer that I'm a DBA looking for answers and not a
coder with a solution, I'll mention what sent me here and see if it meshes
with this issue...

We are also running the SQL 2005 driver against SQL 2000 (build 2187) and
we
have found that no matter WHAT you do (based on available info), straight
stored procedure calls are still packaged and delivered as prepared
statements so we 'lose' all of the benefits of RPC. I suspect we are
losing
15-30% in dearly needed throughput because of this.

Is this an oversight, a limitation, or a case where the development team
can't find the needle in the haystack?

Since this is a first visit, I can be found on yahoo mail by the given
screen name with ideas or solutions.

Bill Clark


"Richard Yeo" wrote:

With the jTDS driver, SQL Server 2005 managed inserts at the rate of:
966.88
records/sec. This is effectively twice that of the Microsoft driver

And in Sybase, the records are inserted at the rate of: 829.18
records/sec.

Shame on Microsoft and Sybase for writing such badly performing JDBC
drivers!!!

We are now going to start end to end testing with the jTDS driver. Peter
T
thanks for recommending this driver.

Only once it has completed end to end testing will i be happy.

"Robert Klemme" wrote:

Richard Yeo wrote:
Peter

If you are porting an application particularly one as hard on
performance
(calls many stored procs per page using JDBC) as ours the performance
the
application receives from the JDBC Driver and RDBMS combination is
very
important!

Our test is very valid given the ported DB needs to perform at
similar
levels. We are testing all areas of performance not just the driver.
You
can't just test one area. You have to test each link and identify the
weak
link in the chain which is clearly the JDBC driver.

Just to throw in another opinion: since you're running against
different
databases not only the driver *implementation* may be the issue but
network protocols may differ! Also, did you try out different
connection settings? There are actually settings of the JDBC driver (I
know for jTDS but I believe this is true for MS as well) that affect
performance.

Did you do the comparison test with jTDS yet?

Kind regards

robert



.

Relevant Pages

  • Re: Possible Type Conversion Defect
    ... Specifically we are breaking due to the lack of conversion from BIGINT to ... Microsoft SQL Server 2000 JDBC driver. ... I'll agree that the JDBC API specifications could be a bit more precise. ... a JDBC driver attempts to convert the underlying data to the Java ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Re: Ora10 JDBC Driver with TIMESTAMP WITH LOCAL TIME ZONE
    ... >> Robert Klemme wrote: ... >>> driver is the newest driver for Ora 10.2. ... >>> JDBC driver I suspect it's a JDBC driver issue. ... > sets the session time zone of the connection and saves the session ...
    (comp.databases.oracle.misc)
  • Re: federate several datasources
    ... >>I want to federate several physical datasources, ... >>its JDBC driver. ... >>My idea is that this aggregator could be implemented as a special JDBC ... open-source databases such as MySQL, PostGreSQL, but this is outside the ...
    (comp.lang.java.databases)
  • RE: New JDBC 1.2 driver runs slower than JDBC 1.1; my db definition
    ... New JDBC 1.2 driver runs slower than JDBC 1.1; ... [PersonGID] ... While we did not specifically target performance with the v1.2 driver beyond the Adapative Buffering changes, I am surprised that you are seeing slower ... it looks like both your SELECT and UPDATE statement are restricted to a single table. ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Re: Cause of implementation of IF(totalLength < packetSize) in DispatchReadWrite() of ISOUSB-Sam
    ... Thank you Maxim, maybe I begin to understand how the driver implements ... Afterwards the transfer and completion routine run. ... while the packetSize or Buffer is ...
    (microsoft.public.development.device.drivers)