Reply to thread

Message: [QUOTE="JScoobyCed, post: 613709"] Thanks a lot for coming here (thank you to Lee for having brought you in :) ). Now I am not sure we should continue the Thread here as it could be better in c.l.j.d... Anyway, as we are going to discuss benchmark and some general questions, I guess it could be interesting here. We do set our selectMethod=cursor (a typical URL is: "jdbc:microsoft:sqlserver://dbsrv:1433;DatabaseName=dbV2;SelectMethod=cursor") We use JNDI connection, with connection pool provided by Tomcat DBCP. For our benchmark, we run in two versions of our software. Let's call V1 the older version with all the memory leaks, poorly designed stuff (code, query, logging, etc, really bad :) ) and V2 our newly improved version. The soft is a web-application, running on Tomcat with IIS as web server, MS SQL (for the benchmark, but we support Oracle, MySQL (!:)), WebSphere and WebLogic). We have an important set of JMeter scripts (created by proxy capture of our application). Running those scripts against our application takes 2 days (just start the servers, start the tests and let it run for 2 days to get results). This is because scripts are ran several times, and with different number of concurrent Thread (1, 5, 10, 20, 50, 70, 100, 150... in our V2, we break at 150 users where we start to see Java Exceptions. It used to be 70 with V1 :) ). It covers the whole application and generate a report per Use Case. From the first benchmark, we have found threethings: OutOfMemory errors, Java Exceptions at DB levels (some connection closed, some duplicate PKs, ...), and bad response times. We have then concentrated our profiling sessions (EclipseProfiler) on the worse Use Cases (the one with most errors and long execution time). We solved a lot of things: some excessive/useless loops, some useless Object instanciation, lots of pb in our DB layers (queries, connection pool, time consuming transactions, unsynchronized concurrent access,...), etc We have fixed a lot and now we have our V2 (candidate). The results are impressive. And we still have things to fix. Now, the reason why I came to jTDS is that somebody suggested to have a look at jTDS. So we ran our JMeter scripts, and we didn't see any significant differences (that was on V1, we didn't test on V2 yet). That is V1 with MS driver and V1 with jTDS driver gave similar results (in term of response time, we didn't look at errors for this test). In jTDS, what we are looking for is at first: speed. I am not sure that this driver is design for this purpose, and even then, I don't know if the gain will be significant. There are many factors that will achieve speed: well design DB schema, properly architectured DB access, properly designed (sequences of) query. We have already improved some of this, but to do more, maybe we should follow some pattern that will make full use of jTDS power. We are now modifying some time consuming transactions to batch queries (whenever possible). In short (finally :) ), what we'd like to know is what settings, driver configuration, mode in which jTDS is unbeatable? Thank you for your time. [/QUOTE]

Verification